emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: icomplete-mode vs. iswitchb


From: Stefan Monnier
Subject: Re: icomplete-mode vs. iswitchb
Date: Wed, 11 Dec 2013 22:33:11 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>>> favor is Stefan's presumption that the package preferred by the
>>> majority of users could not be configured to behave like the package
>>> preferred by a far smaller minority.
>> WTF are you talking about?  IDO is just as available as ever.
> Are you being deliberately obtuse or do you read as selectively as you
> quote?  You have said that icomplete is to replace iswitchb.

Which has nothing to do with IDO.

> I have argued that ido would be a more suitable replacement because
> all of the available evidence strongly suggests that users prefer ido
> over icomplete by a wide margin, not to mention the fact that
> a substantial amount of library and user code is built on top of ido.

That's fine, but the reason why we've had iswitchb until now is because
apparently IDO was not a replacement, but rather another feature which
took iswtchb's and then added a host of other things.

And this situation hasn't changed, so no, AFAIK, ido is not
a replacement for iswitchb.

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?

> 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).
- it is not fully "ui compatible", in that several keybindings clash in
  very significant ways with the current completion.
I fully agree that we'd like to make some/many of the features offered
by IDO available by default, but since enabling IDO is not an option,
the second best is to slowly integrate the two, which is not
a small undertaking.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]