unofficial mirror of emacs-devel@gnu.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 19:26:30 +0100	[thread overview]
Message-ID: <87wocbczl5.fsf@telefonica.net> (raw)
In-Reply-To: 20191107045924.zmnfczw5fdzeqh5d@Ergus

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.




  reply	other threads:[~2019-11-07 18:26 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
2019-11-07  4:59             ` Ergus
2019-11-07 18:26               ` Óscar Fuentes [this message]
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=87wocbczl5.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).