From: "João Távora" <joaotavora@gmail.com>
To: Ergus <spacibba@aol.com>
Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
Subject: Re: Why fido, icycles, ido, icomplete
Date: Thu, 07 Nov 2019 00:27:48 +0000 [thread overview]
Message-ID: <87ftj04jjv.fsf@gmail.com> (raw)
In-Reply-To: <20191106232153.bb756hrf4ctwegkp@Ergus> (Ergus's message of "Thu, 7 Nov 2019 00:21:53 +0100")
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
next prev parent reply other threads:[~2019-11-07 0:27 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
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 [this message]
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=87ftj04jjv.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=spacibba@aol.com \
/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.