Re: icomplete-mode vs. iswitchb

[Josh]

On Fri, Dec 6, 2013 at 9:39 AM, Stefan Monnier <address@hidden> wrote:
SM> SE> As the author of iswitchb, I was slightly surprised to see this, but
SM> SE> only because I was expecting (or hoping) that it would be superseded by
SM> SE> ido.el!

As was I, and I pressed the point[0] until it became clear to me that
Stefan had already made up his mind.

SM> No, ido is a superset of iswitchb, but AFAICT there's no way to
SM> customize ido such that it works like iswitchb.

This seems like a decision that merits more investigation than "AFAICT".

SM> SE> Is ido.el also marked as obsolete?
SM> No.

Well... not yet; see below.  The subject of ido came up again a couple
of weeks later in the "Finding packages to enable by default" thread[1]:

SM> Tom> I did some manual filtering as a test and here are some of
the top packages
SM> Tom> which remained:
SM> Tom> (ido . 137)
    [12 features omitted]
SM> Tom> (iswitchb . 46)
    [ 2 features omitted]
SM> Tom> (icomplete . 34)
SM> Tom> (winner . 34)
    [...]
SM> Tom> Ido is at the top (iswitchb is also here) and ido/isiwtchb would really
SM> Tom> make a much better first impression for new users than the default
SM> Tom> very barebone buffer switching.
SM>
SM> Iswitchb is marked obsolete in the trunk: you can get the same
SM> functionality with icomplete-mode.  So you can increase the count of
SM> `icomplete-mode' for all users who have enabled iswitchb without
SM> enabling icomplete-mode.

Ido's count of 137 is still far greater than the combined count of 80
for icomplete and iswitchb, even leaving aside the tenuous assumption
that 100% of iswitchb users would make an informed choice in
icomplete's favor.

As mentioned, here's the bit about ido's obsolescence:

SM> The plan for "ido by default" is rather to slowly make ido obsolete by
SM> adding the corresponding functionality either in the default completion
SM> UI or in icomplete-mode.
SM> An alternative is to try and re-implement it on top of the current
SM> completion UI.  To a large extent, it boils down to the same.

There's a lot of user code and many libraries built on top of ido.  If it's
obsoleted down the line I hope there is an effort to preserve the
current interfaces and behavior to minimize breakage.  Is that the plan?

[0] http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00507.html
[1] http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00103.html

jlf