Re: Why fido, icycles, ido, icomplete

[Ergus <spacibba@aol.com>]

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.