Why fido, icycles, ido, icomplete

Why fido, icycles, ido, icomplete

[Ergus]

Hi:

Sorry I have a sacrilegious question, maybe too obvious for everyone,
but not for me yet.

90% of the emacs users are actually using ivy or helm... The statistics
of downloaded packages are there; but also they are provided by default
as part of the most popular customizations like spacemacs.

Apart from that we actually already have (and invest effort supporting)
ido, icomplete and maybe others provided as internal packages... in
spite they are not (with huge difference) as popular as ivy or helm in
these days. And at least I don't know how to differentiate one from the
other.

So:

1) Do we really need another confusing mode (fido-mode)? instead of
improve one of the already existing alternatives with just an option to
use flex?

2) Why we don't move all of those (the old and the new ones) to elpa as
independent packages? (this will help also to know their individual
popularity in our days and if it makes sense to invest more or less time
in each of them)

3) If ivy & helm are the most popular these days... why we don't try to
collaborate a bit more with their maintainers in order to provide them
functionalities that they are emulating now with hacks? It will be more
efficient now and beneficial for future similar packages in the future.

Re: Why fido, icycles, ido, icomplete

[Daniele Nicolodi]

Hello Ergus,

On 06-11-2019 14:20, Ergus wrote:
> 90% of the emacs users are actually using ivy or helm...
how do you come to this estimate? I don't think it is something you can
derive solely from download statistics.

Thank you.

Cheers,
Daniele

Re: Why fido, icycles, ido, icomplete

[João Távora]

Ergus <spacibba@aol.com> writes:

> 1) Do we really need another confusing mode (fido-mode)? instead of
> improve one of the already existing alternatives with just an option to
> use flex?

I'm sorry you find the name confusing.  I find it appealing (it's "fake
ido"), but we can change it (Stefan proposed icomplete-ido-mode).

Now, I wish I could just put 'flex' (and many other things) in ido-mode.
Actually the matter is much more complicated.  Ido mode is a completely
separate completion system that doesn't respect Emacs completion
interfaces (completion-in-region-functions,
completion-at-point-functions, completion-styles, etc etc etc ).  This
means it doesn't work nicely for M-x, C-h f, and many many other
completion situations.  So, believe me, I tried to change it... and gave
up immediately (but go ahead, open lisp/ido.el hehehe).

Recently, we worked together with the Helm developer to help Helm to
abide by a greater number of Emacs completion interfaces.  It should
have, among other benefits, the interesting result that you can use Helm
matching styles in icomplete.el's frontend.  Or company's.  Or Emacs's
flex in Helm.  So I don't think it's true there's no cooperation.

Maybe you can convince someone to do that for ido.el, idk.

I was a heavy Ido addict for many years because it has the best
interface, hands down, much better than Ivy, or Helm, IMO of course.  I
also know many people in my company that swear by it.  But the
implementation was impossibly hard to hack on.  Then I found
icomplete.el, with very lean implementation (around 8x less lines) and
the closest gap to ido-mode.  I improved a decent part of icomplete.el,
so Icomplete mode is now better by itself.  But that gap to ido-mode is
still annoyingly (and legitimately) there, and we can't just change
icomplete-mode's defaults like that.

So fido-mode.  It's really just icomplete with slightly different
defaults that emulate ido mode as close as possible.  Indeed the
specific contract of fido-mode is to emulate ido-mode as much as
possible, to use it as a reference, so if you find something in the
emulation that can be improved, please share.

Regarding your other points, <shrug> that's just the way Emacs is.  I
like lean implementations that play along with the rest of Emacs, so I
chose icomplete.el to use and to hack on.

João

Re: Why fido, icycles, ido, icomplete

[Ergus]

On Wed, Nov 06, 2019 at 02:30:31PM -0700, Daniele Nicolodi wrote:
>Hello Ergus,
>
>On 06-11-2019 14:20, Ergus wrote:
>> 90% of the emacs users are actually using ivy or helm...
>how do you come to this estimate? I don't think it is something you can
>derive solely from download statistics.
>
>Thank you.
>
>Cheers,
>Daniele
>

Hi Daniele:

When I started using emacs I was very confused about what to use for
completion, so I checked: download statistics and github starts (now
there is the package "paradox" to get that information in the package
manager).

But also the community size of spacemacs (with 188000 starts and 4600
forks) compared to vanilla emacs and a Spanish telegram group for emacs
(197 members now) and a reddit thread related (I can't find it now).

I actually told 90% to be conservative; because 100% of the comments I
have seen related to completion use helm or ivy exclusively. The few
people I knew were using ido 3 years ago (due to the performance issues
in helm) have moved to ivy now.

On the other hand, in my work there is a user who use emacs without any
config at all (because it is in a common server), so as I suppose there
are other people in the same situation I keep that 10% for them. But I
don't think he will be annoyed by an improvement like setting a better
completion by default.

In any case the key of my mail was more about why to maintain so many
alternatives (it is hard to maintain, confusing for the user, complex to
find information (at least in the package manager there is a description
so the user can discover packages there)) and add another one instead of
decide for the best we have and maintain and improve it as much as
possible. Or provide lower level api functionalities for the popular
packages (like ivy), move the others (like ido) to elpa and keep in
built-in emacs only the minimal.

Best,
Ergus

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

João Távora <joaotavora@gmail.com> writes:

> Now, I wish I could just put 'flex' (and many other things) in
> ido-mode.

Ido has a `flex' completion style. Maybe it is a different one?

> Actually the matter is much more complicated.  Ido mode is a completely
> separate completion system that doesn't respect Emacs completion
> interfaces (completion-in-region-functions,
> completion-at-point-functions, completion-styles, etc etc etc ).

Should it? This is like the recent discussion about implementing new
commands on VC: insisting on a common interface hampers diversity and
innovation. We must accept that different tools sometimes deserve
specific user interfaces.

> This
> means it doesn't work nicely for M-x, C-h f, and many many other
> completion situations.

Ido works nicely here for those cases with just a few lines on my .emacs
and an extra package installed (ido-hacks).

[snip]

> I was a heavy Ido addict for many years because it has the best
> interface, hands down, much better than Ivy, or Helm, IMO of course.  I
> also know many people in my company that swear by it.  But the
> implementation was impossibly hard to hack on.

Ido here has a customized look (courtesy of ido-grid-mode.el), a
customized completion scheme (flx-ido) and some more bells and whistles.
This indicates to me that ido is more hackable than your message
implies. I'm not denying that it could be much better on that regard,
though.

[snip]

Re: Why fido, icycles, ido, icomplete

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Wed, Nov 6, 2019 at 10:39 PM Óscar Fuentes <ofv@wanadoo.es> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > Now, I wish I could just put 'flex' (and many other things) in
> > ido-mode.
>
> Ido has a `flex' completion style. Maybe it is a different one?
>

Yes it is. I created the flex completion style so it could be used
across the board, in every completion frontend, not just icomplete.


> Should it? This is like the recent discussion about implementing new
> commands on VC: insisting on a common interface hampers diversity and
> innovation. We must accept that different tools sometimes deserve
> specific user interfaces.
>

Sure, but we're not talking about user-facing interfaces here, rather about
interfaces between reusable components of Emacs.


> > This
> > means it doesn't work nicely for M-x, C-h f, and many many other
> > completion situations.
>
> Ido works nicely here for those cases with just a few lines on my .emacs
> and an extra package installed (ido-hacks).
>

But it won't work with, say SLY's capf-abiding completion table.
Or Eglot's (or lsp-mode's for that matter).

I think the name of the package you use to do that also
says something about the quality of the integration. :-)


> This indicates to me that ido is more hackable than your message
> implies. I'm not denying that it could be much better on that regard,
> though.
>

But those additions only bring it farther away from integrating
into Emacs's completion facilities, and reaping those benefits.

You'll have to write a package to make ido-mode use Helm's
super-special matching styles, but you won't for icomplete.

But I didn't mean to knock ido-mode.  When I'm in a tight spot
on someone else's contorted Emacs, it's still my goto M-x.

It sounds like you're an ido-mode fan, so please try out
fido-mode and tell me what you think is missing from it. I
know a lot is, and I want to improve it.

João

[-- Attachment #2: Type: text/html, Size: 3176 bytes --]

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

João Távora <joaotavora@gmail.com> writes:

> It sounds like you're an ido-mode fan, so please try out
> fido-mode and tell me what you think is missing from it. I
> know a lot is, and I want to improve it.

Has fido-mode support for flx-ido? Can I plug it in? Any other
completion system that I know on Emacs is unbearably dumb IMAO.

Re: Why fido, icycles, ido, icomplete

[Ergus]

Hi Joao:

Thanks for the answer it is very clarifying for me now. Maybe you should
add all this information somewhere in the documentation.

On Wed, Nov 06, 2019 at 10:03:20PM +0000, Jo�o T�vora wrote:
>Ergus <spacibba@aol.com> writes:
>
>> 1) Do we really need another confusing mode (fido-mode)? instead of
>> improve one of the already existing alternatives with just an option to
>> use flex?
>
>I'm sorry you find the name confusing.  I find it appealing (it's "fake
>ido"), but we can change it (Stefan proposed icomplete-ido-mode).
>
The name is not important for me actually :p if it is documented
properly and in a logical place in the manual with links (or in the same
place) of the ido section and icomplete... so easily to find.  

>Now, I wish I could just put 'flex' (and many other things) in ido-mode.
>Actually the matter is much more complicated.  Ido mode is a completely
>separate completion system that doesn't respect Emacs completion
>interfaces (completion-in-region-functions,
>completion-at-point-functions, completion-styles, etc etc etc ).  This
>means it doesn't work nicely for M-x, C-h f, and many many other
>completion situations.  So, believe me, I tried to change it... and gave
>up immediately (but go ahead, open lisp/ido.el hehehe).
>
I actually have very strong feelings behind ido in 2019 (I know I am a
sort of apostate for this). But I think it is something that needs to be
removed/deprecated/substituted for the good of newer alternatives like
icomplete. So new users will try more maintained/ modern/ powerful/
better integrated alternatives: like icomplete/ivy/helm.

The intention is to move the users to the newer functionalities so they
can get the best possible first impression.

 From the software point of view it is "complex" to keep such a big piece
of code that nobody wants to touch anymore... specially if we already
have alternatives for it.

I think Abo-abo actually tried to modify ido to improve it and he
finally ended implementing ivy... was easier that way.

>Recently, we worked together with the Helm developer to help Helm to
>abide by a greater number of Emacs completion interfaces.  It should
>have, among other benefits, the interesting result that you can use Helm
>matching styles in icomplete.el's frontend.  Or company's.  Or Emacs's
>flex in Helm.

I will pray you to do the same for ivy... please please... Actually I
think ivy is now much better integrated than helm before, but for sure
there will be things missing you could help to improve.

>So I don't think it's true there's no cooperation.
>
Sorry, maybe I explained wrong... I know there is some cooperation
(actually some contributors here are active contributors of ivy for
example). I just think it is not enough. The argument is actually that
spacemacs is so big just because they need to hack or re-implement many
functionalities that sometimes we can provide with an extra parameter in
vanilla emacs.

>Maybe you can convince someone to do that for ido.el, idk.
>
Again, I am not an ido fan... I would try to convince someone to do the
same for avy-counsel actually.

>I was a heavy Ido addict for many years because it has the best
>interface, hands down, much better than Ivy, or Helm, IMO of course.  I
>also know many people in my company that swear by it.  But the
>implementation was impossibly hard to hack on.  Then I found
>icomplete.el, with very lean implementation (around 8x less lines) and
>the closest gap to ido-mode.  I improved a decent part of icomplete.el,
>so Icomplete mode is now better by itself.  But that gap to ido-mode is
>still annoyingly (and legitimately) there, and we can't just change
>icomplete-mode's defaults like that.
>
I have never used icomplete... so I don't know what ido provides that
icomplete can't. So where is the gap? Is a part of the gap fixed in helm
or ivy for example?

>So fido-mode.  It's really just icomplete with slightly different
>defaults that emulate ido mode as close as possible.  Indeed the
>specific contract of fido-mode is to emulate ido-mode as much as
>possible, to use it as a reference, so if you find something in the
>emulation that can be improved, please share.
>

Maybe this paragraph should go in the manual in the ido section
suggesting to switch to fido in order to improve fido as much as
possible and deprecate the actual ido implementation in the future... (I
have a dream, please don't burn me for this "A man can dream... a man
can dream")

>Regarding your other points, <shrug> that's just the way Emacs is.  I
>like lean implementations that play along with the rest of Emacs, so I
>chose icomplete.el to use and to hack on.
>
Me too, now I get why we need fido... 

It should say explicitly in the documentation that "Fido is a modern
icomplete emulating ido with better integration with all the emacs
infrastructure" etc etc etc... and it. 

>Jo�o
>
>
Best,
Ergus

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

> I actually have very strong feelings behind ido in 2019 (I know I am a
> sort of apostate for this). But I think it is something that needs to be
> removed/deprecated/substituted for the good of newer alternatives like
> icomplete. So new users will try more maintained/ modern/ powerful/
> better integrated alternatives: like icomplete/ivy/helm.

Ido is not used by default. What good does to remove it?

> The intention is to move the users to the newer functionalities so they
> can get the best possible first impression.

New users are not exposed to ido at all. So I don't get your point.

> From the software point of view it is "complex" to keep such a big piece
> of code that nobody wants to touch anymore... specially if we already
> have alternatives for it.

People are not forced to work on Ido. They do because they want.

> I think Abo-abo actually tried to modify ido to improve it and he
> finally ended implementing ivy... was easier that way.

I tried Ivy and decided that it is clearly inferior to my ido config.
YMMV.

Can we stop prentending there is One True Way of doing things?

Re: Why fido, icycles, ido, icomplete

[João Távora]

Ergus <spacibba@aol.com> writes:

> Thanks for the answer it is very clarifying for me now. Maybe you should
> add all this information somewhere in the documentation.

*all* this informatino is a bit much, don't you think, but there is
 already documentation.

> I actually have very strong feelings behind ido in 2019 (I know I am a
> sort of apostate for this). But I think it is something that needs to be
> removed/deprecated/substituted for the good of newer alternatives like

The idea of fido-mode is indeed to obsolete ido mode.  But it's still a
bit far away.  And removing is yet another matter: i don't think there's
any harm in having ido.  Of course, if fido-mode ever becomes a perfect
superset of ido, and removing it proves mostly harmless, OK I guess.

> The intention is to move the users to the newer functionalities so they
> can get the best possible first impression.

I agree with this.  But I don't agree with the "newer" = "best
possible".  These things take time to settle and one of the strong
points of Emacs is, paradoxically, its resistance to change.  Its like a
movie theater where there are only classics playing.  Lots of grainy
footage but all movies are superb.

> I think Abo-abo actually tried to modify ido to improve it and he
> finally ended implementing ivy... was easier that way.

And I found icomplete.el, which is already in Emacs.

> I will pray you to do the same for ivy... please please...

Well, I did very little.  The author did all the work.  I and Stefan
helped (mostly Stefan in the last part).  The evolution is registered
here https://github.com/emacs-helm/helm/issues/2165.

You can point Ivy's author to this thread.

> think ivy is now much better integrated than helm before, but for sure
> there will be things missing you could help to improve.

>>still annoyingly (and legitimately) there, and we can't just change
>>icomplete-mode's defaults like that.
>>
> I have never used icomplete... so I don't know what ido provides that
> icomplete can't. So where is the gap? Is a part of the gap fixed in helm
> or ivy for example?

You are miscommunicating: the "gap" is whatever doesn't quite work in
icomplete-mode to make it work just like ido-mode.  It's the behaviour
of RET, C-k, C-d and some other things.

> Maybe this paragraph should go in the manual in the ido section
> suggesting to switch to fido in order to improve fido as much as
> possible and deprecate the actual ido implementation in the future... (I
> have a dream, please don't burn me for this "A man can dream... a man
> can dream")

There's already a paragraph in the manual.

       An alternative to Icomplete mode is Fido mode.  This is very similar
    to Icomplete mode, but retains some functionality from a popular
    extension called Ido mode (in fact the name is derived from “Fake Ido”).
    Among other things, in Fido mode, ‘C-s’ and ‘C-r’ are also used to
    rotate the completions list, ‘C-k’ can be used to delete files and kill
    buffers in-list.  Another noteworthy aspect is that ‘flex’ is used as
    the default completion style (*note Completion Styles::).
    ‘
       To enable Fido mode, type ‘M-x fido-mode’, or customize the variable
     fido-mode’ to ‘t’ (*note Easy Customization::).

I also put something in NEWS.

You (or anyone else) can propose changes it, if you want.  I put it in
the icomplete section because it's really very closely related to
icomplete-mode.  Maybe I could add a reference to the ido-mode manual
(just discovered it exists).

Don't know how to do inter-manual references, though, this one is
emacs/buffers.texi the other is misc/ido.texi.

João

Re: Why fido, icycles, ido, icomplete

[João Távora]

Óscar Fuentes <ofv@wanadoo.es> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> It sounds like you're an ido-mode fan, so please try out
>> fido-mode and tell me what you think is missing from it. I
>> know a lot is, and I want to improve it.
>
> Has fido-mode support for flx-ido? Can I plug it in? Any other
> completion system that I know on Emacs is unbearably dumb IMAO.

I don't know flx.  According to its github page flx is a "matching
engine", what in Emacs is a "completion style", I believe.  Right?  A
way to match a pattern to a universe/set of possible strings and to
return a (possibly propertized/annotated) subset of those strings.

If so, and if flx adheres to the completion-styles API, then it's very
easy to plug in.  If it doesn't, maybe the author can find a way to
adapt it, just like Thierry did recently in Helm.

You can also try 'flex' and tell me what you think you are missing from
flx.  I don't find flex "unbearably dumb" :-)

I like to type mispelled fragments of words I vaguely remember and it
almost always pops my intended thing to the top of the list.  But it
doesn't autocorrect like google, for example, that's much harder.  (does
flx?)

João

Re: Why fido, icycles, ido, icomplete

[Ergus]

On Thu, Nov 07, 2019 at 12:59:13AM +0100, �scar Fuentes wrote:
>Ergus <spacibba@aol.com> writes:
>
>> I actually have very strong feelings behind ido in 2019 (I know I am a
>> sort of apostate for this). But I think it is something that needs to be
>> removed/deprecated/substituted for the good of newer alternatives like
>> icomplete. So new users will try more maintained/ modern/ powerful/
>> better integrated alternatives: like icomplete/ivy/helm.
>
>Ido is not used by default. What good does to remove it?
>
Who is maintaining ido these days? Who fixes the issues related with
ido?  Which sense makes to develop and improve all the completion
infrastructure and design if the users can't take advantage of it
because nobody touches ido?

Should we be stocked in 2001 because ido is hard do maintain?

>> The intention is to move the users to the newer functionalities so they
>> can get the best possible first impression.
>
>New users are not exposed to ido at all. So I don't get your point.
>

Reduce confusion, so users don't have to ask like me why are there so
many alternatives; a clearer view of what's around, what's being more
maintained, what's more functional, where the are investing more effort
the developers.

>> From the software point of view it is "complex" to keep such a big piece
>> of code that nobody wants to touch anymore... specially if we already
>> have alternatives for it.
>
>People are not forced to work on Ido. They do because they want.
>

By touch I mean maintain, integrate and update with the new features;
also fix issues.

Recommend ido today will just disappoint users and limit their view of
emacs as it is today. New users (that we should also attract) have a
very hard learning curve in front of them; we must not make it
harder. And ido is not by far the best we have to offer anymore.

We don't have either enough man power (and even with that it makes no
sense) to maintain 4 packages with exactly the same functionality.

>> I think Abo-abo actually tried to modify ido to improve it and he
>> finally ended implementing ivy... was easier that way.
>
>I tried Ivy and decided that it is clearly inferior to my ido config.
>YMMV.
>
This is a personal taste... Many more users are with helm or ivy these
days... so "clearly inferior" is a very personal opinion in your case.

My suggestion here will be to start using fido-mode and help fixing it
until it can completely replace ido in functionality as it is based on
icomplete and integrates better with the rest of the infrastructure.

In my opinion ido should be deprecated and moved as a separated project
in Elpa. And nothing limits icomplete to become more powerful and
functional.

>Can we stop prentending there is One True Way of doing things?
>
There are many approximations to The True; but true is always only
One True... and nobody knows it. That's why we need to keep searching.

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

João Távora <joaotavora@gmail.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> João Távora <joaotavora@gmail.com> writes:
>>
>>> It sounds like you're an ido-mode fan, so please try out
>>> fido-mode and tell me what you think is missing from it. I
>>> know a lot is, and I want to improve it.
>>
>> Has fido-mode support for flx-ido? Can I plug it in? Any other
>> completion system that I know on Emacs is unbearably dumb IMAO.
>
> I don't know flx.  According to its github page flx is a "matching
> engine", what in Emacs is a "completion style", I believe.  Right?  A
> way to match a pattern to a universe/set of possible strings and to
> return a (possibly propertized/annotated) subset of those strings.

It takes a set of candidates and a string as inputs. The algorithm
associates a score to each candidate based on the string and outputs a
list of matching candidates sorted by the score.

> If so, and if flx adheres to the completion-styles API, then it's very
> easy to plug in.  If it doesn't, maybe the author can find a way to
> adapt it, just like Thierry did recently in Helm.

Where can I learn about that completion-styles API?

> You can also try 'flex' and tell me what you think you are missing from
> flx.  I don't find flex "unbearably dumb" :-)

I have experience with ido's flex and can't compare. flx requires some
training but then it is extremely effective. I no longer bother to
memorize most keyboard shorcuts, because by just remembering *some* part
of the command's name it can be easily invoked through M-x, often with
less keypresses (and with much less chording). It is quite effective at
discovering new commands, once you have an idea of the naming convention
that a package uses. Last, but not least, it is the matching system used
by some of the "cool kids" that competes with Emacs (Sublime Text, to
name one).

> I like to type mispelled fragments of words I vaguely remember and it
> almost always pops my intended thing to the top of the list.  But it
> doesn't autocorrect like google, for example, that's much harder.  (does
> flx?)

If you need autocorrection with flx, you are using it wrong. For
instance, with M-x and 20000+ candidates, four letters are almost always
enough to put the target on the first 10 candidates. Said that, flx is
somewhat forgiving about typos but explaining the reason without first
explaining how the algorithm works is difficult.

The weak point of flx is that it can be a bit slow. The author put a lot
of effort on optimizations and it works reasonably well by using caching
techniques, but the first invocation takes a bit too long even on fast
machines and the cache uses lots of memory. Implementing the algorithm
in C is on my to-do list. Then it could be used even for incremental
search on a buffer.

Re: Why fido, icycles, ido, icomplete

[Ergus]

On Thu, Nov 07, 2019 at 12:27:48AM +0000, João Távora wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Thanks for the answer it is very clarifying for me now. Maybe you should
>> add all this information somewhere in the documentation.
>
>*all* this informatino is a bit much, don't you think, but there is
> already documentation.
>
>> I actually have very strong feelings behind ido in 2019 (I know I am a
>> sort of apostate for this). But I think it is something that needs to be
>> removed/deprecated/substituted for the good of newer alternatives like
>
>The idea of fido-mode is indeed to obsolete ido mode.  But it's still a
>bit far away.  And removing is yet another matter: i don't think there's
>any harm in having ido.  Of course, if fido-mode ever becomes a perfect
>superset of ido, and removing it proves mostly harmless, OK I guess.
>
Yes, I know

>> The intention is to move the users to the newer functionalities so they
>> can get the best possible first impression.
>
>I agree with this.  But I don't agree with the "newer" = "best
>possible".  These things take time to settle and one of the strong
>points of Emacs is, paradoxically, its resistance to change.  Its like a
>movie theater where there are only classics playing.  Lots of grainy
>footage but all movies are superb.
>
Yes, but nobody feels impressed by the special effects in the first Star
Wars today, in spite of they were amazing in their moment and required
much more effort than newer movies.

My point is that many new functionalities are implemented for a reason
and hide or limit them because of backward compatibility is senseless. 

>> I think Abo-abo actually tried to modify ido to improve it and he
>> finally ended implementing ivy... was easier that way.
>
>And I found icomplete.el, which is already in Emacs.
>
ivy is also based on icomplete actually.

>> I will pray you to do the same for ivy... please please...
>
>Well, I did very little.  The author did all the work.  I and Stefan
>helped (mostly Stefan in the last part).  The evolution is registered
>here https://github.com/emacs-helm/helm/issues/2165.
>
>You can point Ivy's author to this thread.
>
I done.

>> think ivy is now much better integrated than helm before, but for sure
>> there will be things missing you could help to improve.
>
>>>still annoyingly (and legitimately) there, and we can't just change
>>>icomplete-mode's defaults like that.
>>>
>> I have never used icomplete... so I don't know what ido provides that
>> icomplete can't. So where is the gap? Is a part of the gap fixed in helm
>> or ivy for example?
>
>You are miscommunicating: the "gap" is whatever doesn't quite work in
>icomplete-mode to make it work just like ido-mode.  It's the behaviour
>of RET, C-k, C-d and some other things.
>
Could you add at least the cycle with arrows as in ido?

>> Maybe this paragraph should go in the manual in the ido section
>> suggesting to switch to fido in order to improve fido as much as
>> possible and deprecate the actual ido implementation in the future... (I
>> have a dream, please don't burn me for this "A man can dream... a man
>> can dream")
>
>There's already a paragraph in the manual.
>
>       An alternative to Icomplete mode is Fido mode.  This is very similar
>    to Icomplete mode, but retains some functionality from a popular
>    extension called Ido mode (in fact the name is derived from “Fake Ido”).
>    Among other things, in Fido mode, ‘C-s’ and ‘C-r’ are also used to
>    rotate the completions list, ‘C-k’ can be used to delete files and kill
>    buffers in-list.  Another noteworthy aspect is that ‘flex’ is used as
>    the default completion style (*note Completion Styles::).
>    ‘
>       To enable Fido mode, type ‘M-x fido-mode’, or customize the variable
>     fido-mode’ to ‘t’ (*note Easy Customization::).
>
>I also put something in NEWS.
>
>You (or anyone else) can propose changes it, if you want.  I put it in
>the icomplete section because it's really very closely related to
>icomplete-mode.  Maybe I could add a reference to the ido-mode manual
>(just discovered it exists).
>
>Don't know how to do inter-manual references, though, this one is
>emacs/buffers.texi the other is misc/ido.texi.
>
I don;t know if it is possible; but it should be, otherwise at least
mention it in the other.

>João

Best,
Ergus

Re: Why fido, icycles, ido, icomplete

[Ergus]

On Thu, Nov 07, 2019 at 02:07:09AM +0100, ??scar Fuentes wrote:
>Jo??o T??vora <joaotavora@gmail.com> writes:
>
>> ??scar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Jo??o T??vora <joaotavora@gmail.com> writes:
>>>
>>>> It sounds like you're an ido-mode fan, so please try out
>>>> fido-mode and tell me what you think is missing from it. I
>>>> know a lot is, and I want to improve it.
>>>
>>> Has fido-mode support for flx-ido? Can I plug it in? Any other
>>> completion system that I know on Emacs is unbearably dumb IMAO.
>>
>> I don't know flx.  According to its github page flx is a "matching
>> engine", what in Emacs is a "completion style", I believe.  Right?  A
>> way to match a pattern to a universe/set of possible strings and to
>> return a (possibly propertized/annotated) subset of those strings.
>
>It takes a set of candidates and a string as inputs. The algorithm
>associates a score to each candidate based on the string and outputs a
>list of matching candidates sorted by the score.
>
1) Is this what amx (former smex) does? 

>> If so, and if flx adheres to the completion-styles API, then it's very
>> easy to plug in.  If it doesn't, maybe the author can find a way to
>> adapt it, just like Thierry did recently in Helm.
>
>Where can I learn about that completion-styles API?
>
>> You can also try 'flex' and tell me what you think you are missing from
>> flx.  I don't find flex "unbearably dumb" :-)
>
>I have experience with ido's flex and can't compare. flx requires some
>training but then it is extremely effective. I no longer bother to
>memorize most keyboard shorcuts, because by just remembering *some* part
>of the command's name it can be easily invoked through M-x, often with
>less keypresses (and with much less chording). It is quite effective at
>discovering new commands, once you have an idea of the naming convention
>that a package uses. Last, but not least, it is the matching system used
>by some of the "cool kids" that competes with Emacs (Sublime Text, to
>name one).
>
if 1) is it like: ivy???regex-fuzzy + amx?

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

>>It takes a set of candidates and a string as inputs. The algorithm
>>associates a score to each candidate based on the string and outputs a
>>list of matching candidates sorted by the score.
>>
> 1) Is this what amx (former smex) does?

I don't know amx/smex but AFAIK there is only one implementation of the
flx algorithm on the Emacs universe. Alos, smex predates flx.

> if 1) is it like: ivy???regex-fuzzy + amx?

No, IIRC regex-fuzzy turn abc into .*a.*b.*c but flx is much more
comples and the scoring algorithm is the key difference. flx scores
candidates depending on where each letter matches. For instance, if I
type

M-x sbke

the first candidate is save-buffers-kill-emacs, because it is the
candidate that gets the higher score by far.

Similarly, when I use my custom command for visiting a file on a git
repo that presents as initial candidates all the files obtained through
`git ls-files', typing "sxc" on the Emacs git checkout puts
source/xdisp.c as the second candidate (the first is
etc/xhtml-csismap.rnc) and if I type "lide" the fifth candidate is
lisp/ido.el.

This last example is penalized because the algorithm gives higher scores
to candidates with longer names, which is also the reason why
source/xdisp.c is not the first candidate on the previous example.

But once we understand the algorithm, we know that the "e" in "lide"
does not help because every file inside lisp/ has an ".el" suffix.
Simply typing "lid" lisp/ido.el is already the fifth candidate but
getting rid of the useless "e" and typing "lido" puts that file as the
first candidate.

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

>>Ido is not used by default. What good does to remove it?
>>
> Who is maintaining ido these days? Who fixes the issues related with
> ido?  Which sense makes to develop and improve all the completion
> infrastructure and design if the users can't take advantage of it
> because nobody touches ido?

Is Ido in such bad state and I didn't notice?

> Should we be stocked in 2001 because ido is hard do maintain?

What is the criteria for saying "this is 2001, this is 2019"?

>>> The intention is to move the users to the newer functionalities so they
>>> can get the best possible first impression.
>>
>>New users are not exposed to ido at all. So I don't get your point.
>>
>
> Reduce confusion, so users don't have to ask like me why are there so
> many alternatives; a clearer view of what's around, what's being more
> maintained, what's more functional, where the are investing more effort
> the developers.

Sorry, I don't follow you there. Ido works. Emacs is not pestering new
users with nag screens trying to lure them into using Ido. So what's
your point?

>>> From the software point of view it is "complex" to keep such a big piece
>>> of code that nobody wants to touch anymore... specially if we already
>>> have alternatives for it.
>>
>>People are not forced to work on Ido. They do because they want.
>>
>
> By touch I mean maintain, integrate and update with the new features;
> also fix issues.

Which new features? Which issues? Did you notice the part were I
mentioned that I tried Ivy and it was inferior to my Ido setup?

> Recommend ido today will just disappoint users and limit their view of
> emacs as it is today.

How? And who is recommending Ido? Would they stop recommending Ido if it
were on Elpa?

> New users (that we should also attract) have a
> very hard learning curve in front of them; we must not make it
> harder. And ido is not by far the best we have to offer anymore.
>
> We don't have either enough man power (and even with that it makes no
> sense) to maintain 4 packages with exactly the same functionality.
>
>>> I think Abo-abo actually tried to modify ido to improve it and he
>>> finally ended implementing ivy... was easier that way.
>>
>>I tried Ivy and decided that it is clearly inferior to my ido config.
>>YMMV.
>>
> This is a personal taste...

Yes, the same personal taste that made me an Emacs user.

> Many more users are with helm or ivy these
> days... so "clearly inferior" is a very personal opinion in your case.

I have serious doubts about your statistics. See, I tried Ivy+Swiper at
least twice on the recent years, simultaneously on several machines.
That counts as, let's say, 8 installs of Ivy+Swiper. But every time I
decided that they are not an improvement, so I keep using Ido, which
comes built-in with Emacs. On your statistics, that's 8 users for Ivy, 0
for Ido.

> My suggestion here will be to start using fido-mode and help fixing it
> until it can completely replace ido in functionality as it is based on
> icomplete and integrates better with the rest of the infrastructure.

I'm all for a better Ido and it is great that João is working on it. But
as long as fido-mode is not as effective as Ido, I won't use it no
matter how well integrated it is on the rest of the infrastructure.

> In my opinion ido should be deprecated and moved as a separated project
> in Elpa. And nothing limits icomplete to become more powerful and
> functional.

My opinion is that lots of Emacs packages should be moved to Elpa, but
as I'm not inconvenienced by their presence (beyond the build taking a
bit longer) I abstain from suggesting those changes and leave the
decision to those that feel the burden of dealing with those packages.

>>Can we stop prentending there is One True Way of doing things?
>>
> There are many approximations to The True; but true is always only
> One True... and nobody knows it. That's why we need to keep searching.

You are not searching, you are suggesting to remove alternatives that
other people find useful. You are proposing change for change's sake. As
long as your replacement can't improve my workflow, please let me alone
in my cave with my 2001 technology that works better than your 2019
technology :-)

Re: Why fido, icycles, ido, icomplete

[Ergus]

This is not going anywhere.. so I don't continue with this... I actually
didn't proposed anything because (as in my first mail in the thread I
said) This is always the same when talking about changes (I still
remember the C-c C-c discussion a year ago).

On Thu, Nov 07, 2019 at 03:20:48AM +0100, �scar Fuentes wrote:
>Ergus <spacibba@aol.com> writes:
>
>>>Ido is not used by default. What good does to remove it?
>>>
>> Who is maintaining ido these days? Who fixes the issues related with
>> ido?  Which sense makes to develop and improve all the completion
>> infrastructure and design if the users can't take advantage of it
>> because nobody touches ido?
>
>Is Ido in such bad state and I didn't notice?
>
Yes, actually it is. It requires fixes, patches and external workarounds
to make it work. And nobody so far is doing that. 

>> Should we be stocked in 2001 because ido is hard do maintain?
>
>What is the criteria for saying "this is 2001, this is 2019"?
>
Lets just look around and see alternative editors with new features we
don't have... or just the features we have implemented in emacs in the
latest versions...

Why do you think it is needed ido-hacks, ido-everywhere,
ido-vertical-mode, or ido-completing-read+? They are not actually
extending ido, they are just pretending ido is updated.

>>>> The intention is to move the users to the newer functionalities so they
>>>> can get the best possible first impression.
>>>
>>>New users are not exposed to ido at all. So I don't get your point.
>>>
>>
>> Reduce confusion, so users don't have to ask like me why are there so
>> many alternatives; a clearer view of what's around, what's being more
>> maintained, what's more functional, where the are investing more effort
>> the developers.
>
>Sorry, I don't follow you there. Ido works. Emacs is not pestering new
>users with nag screens trying to lure them into using Ido. So what's
>your point?
>
I have explained it 2 times. You don't get it... ok.

>>>> From the software point of view it is "complex" to keep such a big piece
>>>> of code that nobody wants to touch anymore... specially if we already
>>>> have alternatives for it.
>>>
>>>People are not forced to work on Ido. They do because they want.
>>>
>>
>> By touch I mean maintain, integrate and update with the new features;
>> also fix issues.
>
>Which new features? Which issues? Did you notice the part were I
>mentioned that I tried Ivy and it was inferior to my Ido setup?
>
I haven't find any issue with ivy... and if there are issues there is a
maintainer and active community...

If you are not allowed to configure ivy to behave like ido it is because
ivy is not ido... in any case I don't think there is something in ido
that ivy can't reproduce. flx, fuzzy and so on are integrated + recentf,
amx, avy, and many other fancy functionalities... I am not recommending
ivy for you... I just doubt that there is so much (if any) functional
difference with ido.

And if there is something crucial just report that...

>> Recommend ido today will just disappoint users and limit their view of
>> emacs as it is today.
>
>How? And who is recommending Ido? Would they stop recommending Ido if it
>were on Elpa?
>
Most of the documentation around talks more about ido than about
icomplete or icycles... 

>> New users (that we should also attract) have a
>> very hard learning curve in front of them; we must not make it
>> harder. And ido is not by far the best we have to offer anymore.
>>
>> We don't have either enough man power (and even with that it makes no
>> sense) to maintain 4 packages with exactly the same functionality.
>>
>>>> I think Abo-abo actually tried to modify ido to improve it and he
>>>> finally ended implementing ivy... was easier that way.
>>>
>>>I tried Ivy and decided that it is clearly inferior to my ido config.
>>>YMMV.
>>>
>> This is a personal taste...
>
>Yes, the same personal taste that made me an Emacs user.
>
We all use emacs

>> Many more users are with helm or ivy these
>> days... so "clearly inferior" is a very personal opinion in your case.
>
>I have serious doubts about your statistics. See, I tried Ivy+Swiper at
>least twice on the recent years, simultaneously on several machines.
>That counts as, let's say, 8 installs of Ivy+Swiper. But every time I
>decided that they are not an improvement, so I keep using Ido, which
>comes built-in with Emacs. On your statistics, that's 8 users for Ivy, 0
>for Ido.
>
But you didn't start it on github for sure, and if you did you only had
one start to give so the statistics are a bit more accurate that way.

Right now the king is still helm... And of course statistics have some
test errors (that's the sense of statistics, otherwise it is just
maths)...

In any case all spacemacs user are not using ido and that's (with
difference) the bigger community we have right now.

One of the arguments to put ido (and many of the building packages) in a
different package in Elpa to have some estimation of their use... Not
the most accurate estimation, but better than nothing for sure... in
your example it will give 8 too right?

>> My suggestion here will be to start using fido-mode and help fixing it
>> until it can completely replace ido in functionality as it is based on
>> icomplete and integrates better with the rest of the infrastructure.
>
>I'm all for a better Ido and it is great that Jo�o is working on it. But
>as long as fido-mode is not as effective as Ido, I won't use it no
>matter how well integrated it is on the rest of the infrastructure.
>
Ok... I call that human backward compatibility.

>> In my opinion ido should be deprecated and moved as a separated project
>> in Elpa. And nothing limits icomplete to become more powerful and
>> functional.
>
>My opinion is that lots of Emacs packages should be moved to Elpa, but
>as I'm not inconvenienced by their presence (beyond the build taking a
>bit longer) I abstain from suggesting those changes and leave the
>decision to those that feel the burden of dealing with those packages.
>
If we don't do that (and everybody abstain) the emacs sources and
installer will indefinitely grow and grow (as well as building times and
bug reports, and unknown portions in the code that nobody uses and
touches, and complexity trying to keep everything working more or less
in the standard way, and we will need a lot of glue code to join old
packages with the things...) 

>>>Can we stop prentending there is One True Way of doing things?
>>>
>> There are many approximations to The True; but true is always only
>> One True... and nobody knows it. That's why we need to keep searching.
>
>You are not searching, you are suggesting to remove alternatives that
>other people find useful. You are proposing change for change's sake. As
>long as your replacement can't improve my workflow, please let me alone
>in my cave with my 2001 technology that works better than your 2019
>technology :-)
>
Again I didn't propose anything. I have just seen many opinions before,
about ido maintenance and update with the new features in emacs. If
changes are bad then we shouldn't do any other emacs release anymore and
keep it as if forever... But emacs have changes too much since 25.1.

You don't know how well (or bad) my technology works... so you don't
have a comparison point to say that yours work better. I could say that
you didn't like ivy because you didn't configure it properly... those
are both just random opinions without any basement.

Best
Ergus.

Re: Why fido, icycles, ido, icomplete

[João Távora]

Óscar Fuentes <ofv@wanadoo.es> writes:

> João Távora <joaotavora@gmail.com> writes:

>> If so, and if flx adheres to the completion-styles API, then it's very
>> easy to plug in.  If it doesn't, maybe the author can find a way to
>> adapt it, just like Thierry did recently in Helm.
>
> Where can I learn about that completion-styles API?

In the emacs manual, but a lot in lisp/minibuffer.el.  Look at how the
other styles are implemented.  Also ask Stefan on this list.

>> You can also try 'flex' and tell me what you think you are missing from
>> flx.  I don't find flex "unbearably dumb" :-)
>
> I have experience with ido's flex and can't compare.

I wasn't talking about ído's flex, which is named
'ido-enable-flex-matching'.  So we don't lose ourselves, when I say
'flex' I am talking about:

    (setq completion-styles '(flex))
    (setq completion-category-defaults nil )

When I say 'flx', I am talking about "your" system (or the little I know
about it.)

> flx requires some
> training but then it is extremely effective. I no longer bother to
> memorize most keyboard shorcuts, because by just remembering *some* part
> of the command's name it can be easily invoked through M-x, often with
> less keypresses (and with much less chording). It is quite effective at
> discovering new commands, once you have an idea of the naming convention
> that a package uses. Last, but not least, it is the matching system used
> by some of the "cool kids" that competes with Emacs (Sublime Text, to
> name one).

I don't use the "cool kids" stuff, but I do use some completion boxes in
some other applications with flex matching.  I don't see any big
difference between 'flex' and those.

>> I like to type mispelled fragments of words I vaguely remember and it
>> almost always pops my intended thing to the top of the list.  But it
>> doesn't autocorrect like google, for example, that's much harder.  (does
>> flx?)
> If you need autocorrection with flx, you are using it wrong.

I don't use flx.  I gather it doesn't support autocorrection and neither
does 'flex'.  Great.  Or not.  Autocorrection is an advanced feature in
many systems, most prominently Google's.  The point there, I think, is
precisely that you CAN use it wrong, as humans frequently do.

Your description of your usage of flx matches exactly my usage of
'flex'.  However, the 'flex' scoring implementation is about 20 lines in
actual implementation, is controlled by a single variable
(flex-score-match-tightness).  'flx' seems like it's much much larger in
length, and considerably more sophisticated (I read warm-up cache,
heatmap, special-cases for certain characters, etc.).

I'm looking for your feedback in term of these kinds of statements

   "When I use 'flx' on the set X it gives me Y but 'flex' on the same
   set gives me Z"

If we find 'flx's result is more compelling, we can take steps to
approximate 'flex' to it.

> instance, with M-x and 20000+ candidates, four letters are almost always
> enough to put the target on the first 10 candidates. Said that, flx is
> somewhat forgiving about typos

Yes, but what kind of typos?  If I type "complwt", will it ever bring
"completion" as a match?  'flex' won't.

João

Re: Why fido, icycles, ido, icomplete

[João Távora]

Ergus <spacibba@aol.com> writes:

>>movie theater where there are only classics playing.  Lots of grainy
>>footage but all movies are superb.
> Yes, but nobody feels impressed by the special effects in the first Star
> Wars today, in spite of they were amazing in their moment and required
> much more effort than newer movies.

I'm glad I made the analogy, then.  I am more interested in cinema than
special effects.  Metaphoricaly, of course.  (but also literally).

>>And I found icomplete.el, which is already in Emacs.
> ivy is also based on icomplete actually.

Oh.  What do you mean "based".  Does it share some of the implementation
(i.e. does it 'require' icomplete as a library).  Or is it more of "a
derived work"?

>>You are miscommunicating: the "gap" is whatever doesn't quite work in
>>icomplete-mode to make it work just like ido-mode.  It's the behaviour
>>of RET, C-k, C-d and some other things.
> Could you add at least the cycle with arrows as in ido?

Of course, and so can you.  Have you got a FSF copyright assignment?

João

Re: Why fido, icycles, ido, icomplete

[Stefan Monnier]

Hola Óscar,

> Which new features? Which issues? Did you notice the part were I
> mentioned that I tried Ivy and it was inferior to my Ido setup?

IDO is a great package which lots of users like, so much so that we have
several extra packages trying to use it in more circumstances than just
selecting buffers and files.

It still works as well as ever, AFAIK.
But like all packages, there's pressure to make it work even better.

One of those improvements is to make it work for all completions, as is
done in ido-everywhere and ido-completing-read.  But as it turns out,
the current ido code only works with *most* completion tables, not all.
There aren't terribly many completion tables for which it doesn't work,
but it would be nice to get those few remaining percents working.

There are 2 ways to do that:
1- improve ido.el
2- write a replacement

Both approaches are valid.  Experience shows that approach number 2 has
been more popular.  Personally, I don't use IDO so I'm not particularly
interested in either approach's goal, but I do like some of IDO's
features, so I'm interested in solutions that result in a closer
integration of the "normal" completion code and IDO so I get to use some
the features I like without being forced to buy into the ones I don't.

That's why I wrote the `substring` completion style (which, together
with icomplete-mode (plus a few tweaks) made iswitchb obsolete, but more
importantly, it brought that feature to all users in the default config).

IOW, I don't see fido-mode as "obsoleting ido-mode" but as "adding IDO
features to the standard completion system", IOW spreading IDO's
gospel further.

Here as some examples of the corner cases supported by the standard
completion system and that IDO currently doesn't cover, AFAICT:
- C-x C-f by default can complete env vars, e.g. when you type C-x C-f $HOM TAB
- C-x C-f ${HOM TAB will not only complete the "E" but will also close
  the "}", at least if there's no other env var starting with "HOME".
- IDO doesn't support some completion styles such as `partial-completion`
  E.g. C-x C-f ~/e/s/r-e.c TAB to find the ~/emacs/src/regex-emacs.c file.
- By default IDO only covers minibuffer completion of files and buffers.
  ido-completing-read makes it cover all minibuffer completions, but
  there's still no support for in-buffer completion.
- the *Completions* buffer (and icomplete-mode's in-buffer list of
  completions [tho I now notice that some of the highlighting is lost in
  some cases, looks like a bug]) highlights the parts of the candidates
  that matched the pattern, as well as the place that correspond to where
  "point" is.


        Stefan

Re: Why fido, icycles, ido, icomplete

[Ergus]

On Thu, Nov 07, 2019 at 10:39:44AM +0000, Jo?o T?vora wrote:
>Ergus <spacibba@aol.com> writes:
>
>>>movie theater where there are only classics playing.  Lots of grainy
>>>footage but all movies are superb.
>> Yes, but nobody feels impressed by the special effects in the first Star
>> Wars today, in spite of they were amazing in their moment and required
>> much more effort than newer movies.
>
>I'm glad I made the analogy, then.  I am more interested in cinema than
>special effects.  Metaphoricaly, of course.  (but also literally).
>

>>>And I found icomplete.el, which is already in Emacs.
>> ivy is also based on icomplete actually.
>
>Oh.  What do you mean "based".  Does it share some of the implementation
>(i.e. does it 'require' icomplete as a library).  Or is it more of "a
>derived work"?
>
It is a derived work. Look: https://github.com/abo-abo/swiper/issues/2321

>>>You are miscommunicating: the "gap" is whatever doesn't quite work in
>>>icomplete-mode to make it work just like ido-mode.  It's the behaviour
>>>of RET, C-k, C-d and some other things.
>> Could you add at least the cycle with arrows as in ido?
>
>Of course, and so can you.  Have you got a FSF copyright assignment?
>
Yes, I have one... but I prefer to deal with the C side of emacs... ;-).

>Jo?o
>
>
Ergus

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

Ergus <spacibba@aol.com> writes:

>>Is Ido in such bad state and I didn't notice?
>>
> Yes, actually it is. It requires fixes, patches and external workarounds
> to make it work. And nobody so far is doing that. 

See below.

>>What is the criteria for saying "this is 2001, this is 2019"?
>>
> Lets just look around and see alternative editors with new features we
> don't have... or just the features we have implemented in emacs in the
> latest versions...
>
> Why do you think it is needed ido-hacks, ido-everywhere,
> ido-vertical-mode, or ido-completing-read+? They are not actually
> extending ido, they are just pretending ido is updated.

Although the Ido core mechanism works for general completion, it only
covers some cases (file and buffer completion). The "fixes, patches and
external workarounds" you refer to (actually, they are not fixes nor
patches nor workarounds) extend the functionality to other cases where
users wish to use the Ido completion mechanism.

Possibly you are under the impression that Ido is intended as a
replacement for Emacs' completion system. It is not. It's core goal is
to provide a richer find-file and switch-to-buffer. You can delete files
or kill buffers from the Ido prompt, and seamlessly switch from finding
files to switching buffers and vice versa.

Some people like Ido's completion mechanism and created extensions to
use it for other purposes, but that doesn't mean that Ido is broken and
needs fixes, patches and workarounds.

>>> By touch I mean maintain, integrate and update with the new features;
>>> also fix issues.
>>
>>Which new features? Which issues? Did you notice the part were I
>>mentioned that I tried Ivy and it was inferior to my Ido setup?
>>
> I haven't find any issue with ivy... and if there are issues there is a
> maintainer and active community...

I never said that I found issues with Ivy.

> If you are not allowed to configure ivy to behave like ido it is because
> ivy is not ido...

Great! Now, with one more step, you will understand why I'm reluctant to
switching from Ido to Ivy when the later is not a replacement for the
former.

[snip]

>>> Recommend ido today will just disappoint users and limit their view of
>>> emacs as it is today.
>>
>>How? And who is recommending Ido? Would they stop recommending Ido if it
>>were on Elpa?
>>
> Most of the documentation around talks more about ido than about
> icomplete or icycles...

What documentation? Emacs' documentation? Or text from the websphere? It
is expected that icycles is not mentioned on Emacs' documentation. If
Ido has more mentions on the websphere, that can be explained by several
possible reasons, one of them being that people like to write about Ido
:-)

>>> Many more users are with helm or ivy these
>>> days... so "clearly inferior" is a very personal opinion in your case.
>>
>>I have serious doubts about your statistics. See, I tried Ivy+Swiper at
>>least twice on the recent years, simultaneously on several machines.
>>That counts as, let's say, 8 installs of Ivy+Swiper. But every time I
>>decided that they are not an improvement, so I keep using Ido, which
>>comes built-in with Emacs. On your statistics, that's 8 users for Ivy, 0
>>for Ido.
>>
> But you didn't start it on github for sure, and if you did you only had
> one start to give so the statistics are a bit more accurate that way.

Can I give stars to Ido on Github? ;-)

It seems to me that using Github stars as a popularity contest is quite
problematic.

[snip]

> In any case all spacemacs user are not using ido and that's (with
> difference) the bigger community we have right now.

How do you know that there are no spacemacs users using Ido and why
should we care?

[snip]

> Again I didn't propose anything. I have just seen many opinions before,
> about ido maintenance and update with the new features in emacs. If
> changes are bad then we shouldn't do any other emacs release anymore and
> keep it as if forever... But emacs have changes too much since 25.1.
>
> You don't know how well (or bad) my technology works... so you don't
> have a comparison point to say that yours work better. I could say that
> you didn't like ivy because you didn't configure it properly... those
> are both just random opinions without any basement.

Sorry, but this is verging into religious flamewar. Let's stop the
discussion here.

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

João Távora <joaotavora@gmail.com> writes:

>> Where can I learn about that completion-styles API?
>
> In the emacs manual, but a lot in lisp/minibuffer.el.  Look at how the
> other styles are implemented.  Also ask Stefan on this list.

Thanks.

>>> You can also try 'flex' and tell me what you think you are missing from
>>> flx.  I don't find flex "unbearably dumb" :-)
>>
>> I have experience with ido's flex and can't compare.
>
> I wasn't talking about ído's flex, which is named
> 'ido-enable-flex-matching'.  So we don't lose ourselves, when I say
> 'flex' I am talking about:
>
>     (setq completion-styles '(flex))
>     (setq completion-category-defaults nil )

I'll try to experiment with emacs -Q and those settings as time permits.

>> flx requires some
>> training but then it is extremely effective. I no longer bother to
>> memorize most keyboard shorcuts, because by just remembering *some* part
>> of the command's name it can be easily invoked through M-x, often with
>> less keypresses (and with much less chording). It is quite effective at
>> discovering new commands, once you have an idea of the naming convention
>> that a package uses. Last, but not least, it is the matching system used
>> by some of the "cool kids" that competes with Emacs (Sublime Text, to
>> name one).
>
> I don't use the "cool kids" stuff, but I do use some completion boxes in
> some other applications with flex matching.  I don't see any big
> difference between 'flex' and those.

The likely reason is that those other applications use flex matching or
something that approximates it. On non-technical applications flx can be
problematic because using it without some knowledge about how it works
can bring puzzling results.

>> If you need autocorrection with flx, you are using it wrong.
>
> I don't use flx.  I gather it doesn't support autocorrection and neither
> does 'flex'.  Great.  Or not.  Autocorrection is an advanced feature in
> many systems, most prominently Google's.  The point there, I think, is
> precisely that you CAN use it wrong, as humans frequently do.

Autocorrection makes little sense when 1) your typical input is tiny
(less that 6 characters) and 2) effective use of the completion style
depends on *not* using words.

[snip]

> I'm looking for your feedback in term of these kinds of statements
>
>    "When I use 'flx' on the set X it gives me Y but 'flex' on the same
>    set gives me Z"
>
> If we find 'flx's result is more compelling, we can take steps to
> approximate 'flex' to it.

I don't think that's a good idea. Many users are utterly confused by flx
but are quite happy with flex. I'm more interested on adding flx as a
completion style (hence my previous question about the completion-styles
API).

>> instance, with M-x and 20000+ candidates, four letters are almost always
>> enough to put the target on the first 10 candidates. Said that, flx is
>> somewhat forgiving about typos
>
> Yes, but what kind of typos?  If I type "complwt", will it ever bring
> "completion" as a match?  'flex' won't.

Neither flx, because "completion" has no `w'. I already mentiond why flx
users do not care much about autocorrection. Now I'll add that flx is
not particularly good (read: superior to other methods) at completing
single words. It shines at completing strings made of multiple words,
tough, as your typical Elisp function/variable name, C++/Java qualified
method, pathname, etc.

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[snip text which I fully agree with]

> There are 2 ways to do that:
> 1- improve ido.el
> 2- write a replacement
>
> Both approaches are valid. Experience shows that approach number 2 has
> been more popular.

AFAIK only Ivy was created as a replacement for Ido+extensions.

> Personally, I don't use IDO so I'm not particularly
> interested in either approach's goal, but I do like some of IDO's
> features, so I'm interested in solutions that result in a closer
> integration of the "normal" completion code and IDO so I get to use
> some the features I like without being forced to buy into the ones I
> don't.
>
> That's why I wrote the `substring` completion style (which, together
> with icomplete-mode (plus a few tweaks) made iswitchb obsolete, but more
> importantly, it brought that feature to all users in the default config).
>
> IOW, I don't see fido-mode as "obsoleting ido-mode" but as "adding IDO
> features to the standard completion system", IOW spreading IDO's
> gospel further.

I thought it was Ido who made iswitchb obsolete ;-) but I get your point
about expanding the capabilities of the default method to cater the
needs of more users.

Just to clarify, it is great to see João working on this. As for the
future of Ido, I'm not terribly afraid: supposing it is obsoleted and
the replacement does not fit my needs, the solution is obvious and not
all that painful.

> Here as some examples of the corner cases supported by the standard
> completion system and that IDO currently doesn't cover, AFAICT:
> - C-x C-f by default can complete env vars, e.g. when you type C-x C-f $HOM TAB
> - C-x C-f ${HOM TAB will not only complete the "E" but will also close
>   the "}", at least if there's no other env var starting with "HOME".
> - IDO doesn't support some completion styles such as `partial-completion`
>   E.g. C-x C-f ~/e/s/r-e.c TAB to find the ~/emacs/src/regex-emacs.c file.
> - By default IDO only covers minibuffer completion of files and buffers.
>   ido-completing-read makes it cover all minibuffer completions, but
>   there's still no support for in-buffer completion.
> - the *Completions* buffer (and icomplete-mode's in-buffer list of
>   completions [tho I now notice that some of the highlighting is lost in
>   some cases, looks like a bug]) highlights the parts of the candidates
>   that matched the pattern, as well as the place that correspond to where
>   "point" is.

Good, but keep in mind that different approaches to completion can make
some of the above moot. Take the *Completions* buffer, for example. On
my Ido config, there is visual feedback about the parts of the candidate
strings that matches the query and they are shown on a multi-column
format that is dense and readable at the same time, IMO.

As I mentioned on a previous message, there is more than one way to skin
a cat. Having a powerful and flexible (*) default completion method is
great, but other approaches perhaps require things that does not fit
with whatever framework you can provide.

* There is a tendency on modern software towards dumbing-down things,
  for a good reason, but IMAO Emacs should not do down that path.

Re: Why fido, icycles, ido, icomplete

[Stefan Monnier]

> On my Ido config, there is visual feedback about the parts of the candidate
> strings that matches the query and they are shown on a multi-column
> format that is dense and readable at the same time, IMO.

Great, I wasn't aware that it had been implemented for IDO.

> As I mentioned on a previous message, there is more than one way to skin
> a cat. Having a powerful and flexible (*) default completion method is
> great, but other approaches perhaps require things that does not fit
> with whatever framework you can provide.

Definitely.  Emacs makes it particularly easy to experiment this way and
develop solutions tuned for very specific situations.  IDO is a great
such example.  The number of "completion frameworks" out there for Emacs
is another example.

I see the task of Emacs maintainers as trying to consolidate those
"branches" of functionality so that their features can be used in
more circumstances.  Usually that only applies to some parts of the
functionality they offer, and very often it requires a complete rewrite
of those features.

The hardest part is often how to retrofit the "generic implementation"
of a feature into the package which originally first provided this
feature in an "ad-hoc" way, since as a general rule the generic
implementation isn't a perfect match.


        Stefan

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> On my Ido config, there is visual feedback about the parts of the candidate
>> strings that matches the query and they are shown on a multi-column
>> format that is dense and readable at the same time, IMO.
>
> Great, I wasn't aware that it had been implemented for IDO.

As an extension, yes.

Below is my Ido-related config. It extends Ido completion to almost all
Emacs, activates flx and changes the way candidates are displayed.

Those customizations replace Ido's candidate-handling algorithm and
dramatically alters its UI. So much for an unintelligible package :-)

(setq ido-save-directory-list-file nil)
(put 'tmm-menubar 'ido 'ignore)
(require 'ido-hacks)
(ido-hacks-mode)
(ido-mode 1)
(ido-everywhere)
(setq ido-enable-tramp-completion nil)
(setq ido-auto-merge-work-directories-length -1)
(setq ido-enable-flex-matching t)
(require 'flx-ido)
(flx-ido-mode 1)
;; disable ido faces to see flx highlights.
(setq ido-use-faces nil)
(setq flx-ido-threshold 20000)
(require 'ido-grid-mode)
(ido-grid-mode 1)
(setq ido-grid-mode-prefix-scrolls t)


>> As I mentioned on a previous message, there is more than one way to skin
>> a cat. Having a powerful and flexible (*) default completion method is
>> great, but other approaches perhaps require things that does not fit
>> with whatever framework you can provide.
>
> Definitely.  Emacs makes it particularly easy to experiment this way and
> develop solutions tuned for very specific situations.  IDO is a great
> such example.  The number of "completion frameworks" out there for Emacs
> is another example.
>
> I see the task of Emacs maintainers as trying to consolidate those
> "branches" of functionality so that their features can be used in
> more circumstances.  Usually that only applies to some parts of the
> functionality they offer, and very often it requires a complete rewrite
> of those features.
>
> The hardest part is often how to retrofit the "generic implementation"
> of a feature into the package which originally first provided this
> feature in an "ad-hoc" way, since as a general rule the generic
> implementation isn't a perfect match.

What you say is very reasonable but sometimes this task is not worth the
trouble (I'm not claiming that it's the case for fido-mode).

There is always a tension among specifics and generalities. Sometimes it
is irreconcilable. I don't see VC ever providing a better Magit than
Magit itself and Magit would never come to existence if Marius insisted
on implemeting it inside VC, simply because Magit has the goal of being
the best UI for git and VC has the goal of being the best generic VCS
UI. Does it make sense to expand Emacs' functions towards unifying those
packages? Not at all, because they are only related on a superficial
way.

Re: Why fido, icycles, ido, icomplete

[Stefan Monnier]

> Those customizations replace Ido's candidate-handling algorithm and
> dramatically alters its UI. So much for an unintelligible package :-)

I don't think it's unintelligible.  It's just difficult to make it
interact with the existing "standard" completion code because it's
structured fairly differently.  So it's hard to make use if ido code in
the standard UI and vice-versa.

> What you say is very reasonable but sometimes this task is not worth the
> trouble

Not sure what "this task" refers to.  If it refers to the retrofitting,
I fully agree.  If it refers to making (some of) the features more
widely available (potentially by re-implementing them), then
I generally disagree.


        Stefan

Re: Why fido, icycles, ido, icomplete

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

> So much for an unintelligible package :-)

Hey, versus 600 lines of a package that plays along with every part
of Emacs I can name, yes, it's unintelligible.

Which is not to say it isn't great.

But I can say that I had a long list of ido hacks myself (for imenu,
for completion-at-point, etc).  Even SLY in some situations falls back
to ido when it doesn't find anything else.  Don't knock me, I'm was
a fellow IDOer for a long long time. I hope you or someone can
bring all that neat stuff  to Emacs so it can be shared with other
completion frontends.

João

[-- Attachment #2: Type: text/html, Size: 835 bytes --]

Re: Why fido, icycles, ido, icomplete

[Filipp Gunbin]

On 06/11/2019 22:03 +0000, João Távora wrote:

> Ergus <spacibba@aol.com> writes:
>
>> 1) Do we really need another confusing mode (fido-mode)? instead of
>> improve one of the already existing alternatives with just an option to
>> use flex?
>
> I'm sorry you find the name confusing.  I find it appealing (it's "fake
> ido"), but we can change it (Stefan proposed icomplete-ido-mode).

+1 for the name change, because Fido was a pre-Internet-era BBS network
popular at least in Russia.  I was too young when it was operational,
but even for me the name would be confusing.

Filipp

Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> +1 for the name change, because Fido was a pre-Internet-era BBS network
> popular at least in Russia.  I was too young when it was operational,
> but even for me the name would be confusing.

Sadly, I'm not as young as you are and I was a Fido (Fidonet) user until
the Internet became pervasive. FWIW I don't think that the name is
problematic at all.

Re: Why fido, icycles, ido, icomplete

[Nicolas Semrau]

> ----------------------------------------
> From: Filipp Gunbin <fgunbin@fastmail.fm>
> Sent: Fri Nov 08 18:54:00 CET 2019
> To: João Távora <joaotavora@gmail.com>
> Cc: Ergus <spacibba@aol.com>, Drew Adams <drew.adams@oracle.com>, <emacs-devel@gnu.org>
> Subject: Re: Why fido, icycles, ido, icomplete
> 
> 
> On 06/11/2019 22:03 +0000, João Távora wrote:
> 
> > Ergus <spacibba@aol.com> writes:
> >
> >> 1) Do we really need another confusing mode (fido-mode)? instead of
> >> improve one of the already existing alternatives with just an option to
> >> use flex?
> >
> > I'm sorry you find the name confusing.  I find it appealing (it's "fake
> > ido"), but we can change it (Stefan proposed icomplete-ido-mode).
> 
> +1 for the name change, because Fido was a pre-Internet-era BBS network
> popular at least in Russia.  I was too young when it was operational,
> but even for me the name would be confusing.
> 
> Filipp
> 

I agree. Since the "FidoNet" service (often shortened to "Fido") was
popular in at least a few European countries during the 80s/90s, I was
flabbergasted for a second to read that a new fido-mode is being
added. I therefore +1 a name-change.

Greetings
Nicolas

Re: Why fido, icycles, ido, icomplete

[Eli Zaretskii]

> From: Filipp Gunbin <fgunbin@fastmail.fm>
> Date: Fri, 08 Nov 2019 20:54:00 +0300
> Cc: Ergus <spacibba@aol.com>, Drew Adams <drew.adams@oracle.com>,
>  emacs-devel@gnu.org
> 
> +1 for the name change, because Fido was a pre-Internet-era BBS network
> popular at least in Russia.  I was too young when it was operational,
> but even for me the name would be confusing.

FWIW, I know what Fido was, but I don't find the name fido-mode
problematic in any sense.

Re: Why fido, icycles, ido, icomplete

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 110 bytes --]

I'm another dinosaur from the Fido Age, but I don't find fido-mode
confusing at all. Amusing is more like it.

[-- Attachment #2: Type: text/html, Size: 139 bytes --]

Re: Why fido, icycles, ido, icomplete

[João Távora]

On Fri, Nov 8, 2019 at 9:32 PM Juanma Barranquero <lekktu@gmail.com> wrote:
>
> I'm another dinosaur from the Fido Age, but I don't find fido-mode confusing at all. Amusing is more like it.

I also used BBS's and Fido (and RIME). But I wasn't thinking of them at all
forgot all about them when I made up the name.

I was thinking about the black-and-white cartoon guy from the 7up ad.

I'm also pretty sure there is some dog named Fido.

João

Re: Why fido, icycles, ido, icomplete

[Ergus]

Hi:

I am a bit younger probably (or got internet very late in my live) so
fido is fine for me. In any case I am more interested about
functionality than about a name.



On Fri, Nov 08, 2019 at 10:54:43PM +0000, Jo�o T�vora wrote:
>On Fri, Nov 8, 2019 at 9:32 PM Juanma Barranquero <lekktu@gmail.com> wrote:
>>
>> I'm another dinosaur from the Fido Age, but I don't find fido-mode confusing at all. Amusing is more like it.
>
>I also used BBS's and Fido (and RIME). But I wasn't thinking of them at all
>forgot all about them when I made up the name.
>
>I was thinking about the black-and-white cartoon guy from the 7up ad.
>
>I'm also pretty sure there is some dog named Fido.
>
>Jo�o
>