Re: icomplete-mode vs. iswitchb

[Josh <josh@foxtail.org>]

On Thu, Dec 12, 2013 at 4:26 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> Stephen Eglen <S.J.Eglen@damtp.cam.ac.uk> writes:
>
>> Well, I don't recall many  complaints about ido vs iswitchb -- most
>> people were happy to use one or the other.  Probably more people use
>> ido, as it offers more features.  But I have just tested this:
>>
>> (setq ido-mode 'buffer)
>> (ido-mode 1)
>
> Setting aside the fact that it doesn't do what you intended (ido-mode
> ends up set to `both', see this variable's docstring for details), if it
> did, the users would end up with less functionality than if they use
> icomplete-mode, which provides completion suggestions in all cases where
> Emacs knows how to complete - not only buffers, but files, functions,
> variables, etc.

I'm afraid I don't understand.  Is the argument that ido is too featureful
for iswitchb users, as Stefan has written[0]:

    We can't tell iswitchb users that ido makes iswitchb obsolete, since ido
    does a lot more and maybe they don't want all that extra functionality
    (and I'm not sure to what extend ido can be configured to behave like
    iswitchb does).
    I assume that if they're still using iswitchb by now, it's because they
    indeed don't want ido.

or that Stephen's configuration snippet makes ido less featureful
than icomplete, the package to which iswitchb users are being
forcibly migrated, as you wrote above?  If there is some coherent
articulable standard being applied that is consistent with both of
these arguments I don't see it.  Why is uncertainty about whether ido
could be configured to behave like iswitchb sufficient to disqualify
ido out of hand without even the pretense of investigating, whereas
given similar uncertainty about whether icomplete could be so
configured the assumption is "it should be possible to configure
icomplete-mode's behavior to be pretty close to iswitchb-mode"[1]?

[0] http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00545.html
[1] http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00529.html