Re: fix for bug 10994 breaks ido customizations in major way

[Le Wang]

On Tue, May 7, 2013 at 6:26 PM, Vitalie Spinu <address@hidden> wrote:
> What are those packages?

ido-hacks uses it:
https://github.com/scottjad/ido-hacks/blob/master/ido-hacks.el

My flx package uses it: https://github.com/lewang/flx/blob/master/flx-ido.el

> Not the best UI, but definitely not horrible, users can distinguish 2-3
> strings on very rare occasions. It makes implementation much faster and
> solves a lot of hustle for lazy programmers:)

I find presenting the same string with different properties to be horrendous.

Using your example, but with completing-read:

(let ((t1 (propertize "aaa" 'aaa 12))
      (t2 (propertize "aaa" 'aaa 11)))
  (completing-read "?: " (list t1 t2 "sfd")))

Pressing <tab> I don't see "aaa" twice.  When I select "aaa", the
properties are stripped.

Surely you can agree that ido should not blaze its own trail just to
enable lazy programmers?

> Look at imenu-anywhere. It happens to have same imenu tag in different
> files. The package never relied on text properties because IDO was
> broken and it wasn't necessary. Now the issue is solved, and relying on
> text properties is a one-line change to the package. It all depends on
> whether your patch is accepted or not.

This is a terrible idea if ido facilitated such laziness.

> Instead of proposing patch to ido, can you propose a patch to the
> "packages" that needlessly use text properties?

Because that would be much harder.

Your proposal that I should do a harder thing so horrible UI can be
easily implemented is not acceptable to me.

>
> There was an ido interface for ETAG selection floating around which I
> never used, but I doubt it was uniquifying strings by adding location.
>
> In both cases above, one would need a non trivial pre-processing step to
> sort it out.

Yes.  One should spend time to implement such pre-processing to give
the user a better UI.

--
Le