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

[Vitalie Spinu <spinuvit@gmail.com>]

 >> Le Wang <l26wang@gmail.com>
 >> on Tue, 7 May 2013 17:35:23 +0800 wrote:

 >> There are plenty of applications that might need same strings but with
 >> different meaning.

 > No there aren't.  Because this was completely broken in 24.3.1 until
 > the fix was checked in for 10994.

Yes, I was bearing the behavior before, as everyone else did, because it
wasn't happening too often. 

 >> For example ido for tag or imenu navigation, there
 >> might be several locations where a symbol is used/defined.

 > This is a good reason for including a line#, class, etc.  Why only
 > text-properties?

Because it does require quite a fair amount of prepossessing and also
post-processing. I think users are quite fine to see 2-3 strings and
they understand, depending on the context, what repeated string
signify. 

 > Your examples are contrived and not in the wild at all.  I say again,
 > only HEAD has the ability to handle repeated runs of strings.

 > BUT the cost of adding this functionality is breaking packages that
 > add text properties ... Packages that actually __exist__.

What are those packages? 

They can remove text properties, or even not collect them in the first
place, that is definitely easier than adding line-nums/files to
repetitive strings.

 >> Currently
 >> 
 >> (let ((t1 (propertize "aaa" 'aaa 12))
 >> (t2 (propertize "aaa" 'aaa 11)))
 >> (ido-completing-read "?: " (list t1 t2 "sfd")))
 >> 
 >> works as expected. And the above patch breaks that.

 > That would be a horrible UI.  Luckily AFAICT, it hasn't happened.

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:)

 > That's why I say there is no actual valid use-case for repeating the
 > same string in completions.

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.

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

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. 

    Vitalie