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 02:07:09 +0100	[thread overview]
Message-ID: <87bltoebpe.fsf@telefonica.net> (raw)
In-Reply-To: 87a7984j4p.fsf@gmail.com

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.




  reply	other threads:[~2019-11-07  1:07 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 [this message]
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
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=87bltoebpe.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).