all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: Why fido, icycles, ido, icomplete
Date: Thu, 07 Nov 2019 03:20:48 +0100	[thread overview]
Message-ID: <8736f0e8an.fsf@telefonica.net> (raw)
In-Reply-To: 20191107004718.pxb3m7hzecbxz7uu@Ergus

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 :-)




  reply	other threads:[~2019-11-07  2:20 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20191106212018.cnddqzlo5rpdhi6s.ref@Ergus>
2019-11-06 21:20 ` Why fido, icycles, ido, icomplete Ergus
2019-11-06 21:30   ` Daniele Nicolodi
2019-11-06 22:27     ` Ergus
2019-11-06 22:03   ` João Távora
2019-11-06 22:39     ` Óscar Fuentes
2019-11-06 22:57       ` João Távora
2019-11-06 23:07         ` Óscar Fuentes
2019-11-07  0:36           ` João Távora
2019-11-07  1:07             ` Óscar Fuentes
2019-11-07  1:21               ` Ergus
2019-11-07  1:51                 ` Óscar Fuentes
2019-11-07 10:09               ` João Távora
2019-11-07 18:50                 ` Óscar Fuentes
2019-11-06 23:21     ` Ergus
2019-11-06 23:59       ` Óscar Fuentes
2019-11-07  0:47         ` Ergus
2019-11-07  2:20           ` Óscar Fuentes [this message]
2019-11-07  4:59             ` Ergus
2019-11-07 18:26               ` Óscar Fuentes
2019-11-07 14:09             ` Stefan Monnier
2019-11-07 20:35               ` Óscar Fuentes
2019-11-07 21:11                 ` Stefan Monnier
2019-11-07 22:18                   ` Óscar Fuentes
2019-11-07 22:30                     ` Stefan Monnier
2019-11-07 22:34                     ` João Távora
2019-11-07  0:27       ` João Távora
2019-11-07  1:09         ` Ergus
2019-11-07 10:39           ` João Távora
2019-11-07 15:00             ` Ergus
2019-11-08 17:54     ` Filipp Gunbin
2019-11-08 18:10       ` Óscar Fuentes
2019-11-08 18:45       ` Nicolas Semrau
2019-11-08 19:12       ` Eli Zaretskii
2019-11-08 21:31         ` Juanma Barranquero
2019-11-08 22:54           ` João Távora
2019-11-08 23:11             ` Ergus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8736f0e8an.fsf@telefonica.net \
    --to=ofv@wanadoo.es \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.