Re: icomplete-mode vs. iswitchb

[Josh <josh@foxtail.org>]

On Wed, Dec 11, 2013 at 7:33 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> To put it some other way: where were you all in the last 10 years or so
> that we've had iswitchb and ido, without complaining that we should mark
> iswitchb as obsolete and replace it with ido?

I have been happily using ido.  I already told you that I know others
who have been happily using iswitchb.  Why should I complain and
agitate to get something that my friends like obsoleted?

>> There is an ongoing discussion about features that ought to be enabled
>> by default to improve the experience of new users and this discussion
>> has largely been based on features' current popularity, about which we
>> now have good insight thanks to the efforts of those who have
>> extracted that information from bug reports and who have organized and
>> participated in the wiki poll.  In this context it seems obvious that
>> such a popular library as ido should be enabled by default, but
>> instead you have chosen the polar opposite for ido, to "slowly
>> obsolete" it for reasons unknown.  Can you seriously not see how this
>> appears irrational?
>
> I already said that enabling IDO by default is not on the table not
> because IDO doesn't provide nice features but because:
> - it's not a superset of the current completion UI features (it doesn't
>   understand all the new completion table features).

Actually enumerating the ways in which it falls short would help
interested people understand the scope of the problem and perhaps
take on adding support for those features.

> - it is not fully "ui compatible", in that several keybindings clash in
>   very significant ways with the current completion.

I suppose you're talking about C-s and C-r here; are there others?
In any case, such bindings could be trivially changed to adhere to
the current completion key binding conventions and then exposing a
simple disabled-by-default "classic ido key bindings" customization
to retain the existing UI for those of us who prefer it.

The most frequent complaint I hear about ido is the one Dmitry
mentioned about C-j for finding new files; I agree that this behavior
is non-intuitive and undesirable for new users, but it seems likely
that we could work out a more intuitive default interface and make
the current behavior opt-in for experienced ido users.

> I fully agree that we'd like to make some/many of the features offered
> by IDO available by default,

As I have pointed out, there is quite a bit of library and user code
built on top of ido, i.e. depending on its current interfaces and
behavior, so "offering the features" is not sufficient to avoid
breaking that code.

> but since enabling IDO is not an option,
> the second best is to slowly integrate the two, which is not
> a small undertaking.

Would it be an option if support were added for the current
completion UI features you mentioned and the key bindings were
harmonized with current completion key binding conventions?  If
so, will you please enumerate the missing features?  If not, what
else stands in the way?