Selectrum: Comparisons against more competing packages

[oantolin]

The description of selectrum makes it sound pretty similar to the built-in icomplete (except that icomplete is horizontal by default, but can easily be made vertical). If there are any advantages of selectrum over icomplete maybe a "Why not icomplete?" section is in order.

[Luis-Henriquez-Perez]

On a related note, snails is another completing framework not mentioned in the readme.

[raxod502]

Yes, seems reasonable.

[Alexander-Miller]

There's also the new fido-mode that's probably coming in Emacs 27: https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00194.html

[protesilaos]

Just to add that fido-mode is a mod for icomplete that comes with Emacs 27. It basically defines some functions and key bindings to make icomplete behave a little more like ido. The source: M-x find-library icomplete.

[clemera]

Just to complete the list there are also sallet and raven.

[raxod502]

Good lord, we really do have the whole kitchen sink, don't we? I didn't realize the situation was quite so ridiculous -- this will be a whole research project.

[clemera]

Oh and there is also the built in icomplete and someone is working on a modern look for it: https://github.com/oantolin/icomplete-vertical. And in Emacs 27 fido-mode is another upcoming contender :laughing:

[raxod502]

Ok, I did my best. Improvements welcome :)

[oantolin]

First of all, thanks for renaming the issue, once the scope broadened this name makes much more sense.

Second, I think the newly expanded section looks great! I particularly think the icomplete section is very fair (I single it out because it's the completion system I'm most familiar with). I have only a few minor suggestions:

1. Following their manuals, IDO and IComplete should be spelled Ido and Icomplete.

2. I'm not sure icomplete-vertical really merits a mention (I wrote it). It's a hack, less than a day old, and once people start using I'm sure all sorts of problems that may or may not be fixable will emerge (there are already some issues). I won't go as far as suggesting it be removed, since with people's help it might become useful, but I think it's worth pointing out I don't consider it as serious an effort as selectrum or the other reviewed packages.

3. I'd change the wording of this slightly:

   "It is worth noting the new Fido mode which will be included in Emacs 28. It is basically a combination of IDO with Icomplete, and as such does not offer solutions to the problems outlined in the above sections."

   That might make it sound like Fido is made by merging code from Icomplete and Ido. I'd describe it instead as an "Ido emulation layer on top of Icomplete", to make it clear it's mostly Icomplete with some tweaks.

4. In the Swiper section, I suggest removing the word "flawed" from "blindly porting funtionality from the flawed predecessors of Selectrum": let the reader be the judge.

[protesilaos]

Thank you @raxod502 for taking the time to review all these!

Just for you information: fido-mode is included in Emacs 27, not 28. There is a relevant heading in the NEWS entry C-h n:

*** New minor mode Fido mode.
This mode is based on Icomplete, and its name stands for "Fake Ido".
The point of this mode is to be an 'ido-mode' workalike, but provide
most of the functionality present in Icomplete that is not in
'ido-mode', while being much more compatible with all of Emacs's
completion facilities.

In practice, Fido offers some extra functions that mimic their IDO counterparts. These are all found in M-x find-library icomplete. With the help of M-x occur fido:

    226:;;; Helpers for `fido-mode' (or `ido-mode' emulation)
    228:(defun icomplete-fido-kill ()
    265:(defun icomplete-fido-delete-char ()
    274:(defun icomplete-fido-ret ()
    287:(defun icomplete-fido-backward-updir ()
    295:(defvar icomplete-fido-mode-map
    297:    (define-key map (kbd "C-k") 'icomplete-fido-kill)
    298:    (define-key map (kbd "C-d") 'icomplete-fido-delete-char)
    299:    (define-key map (kbd "RET") 'icomplete-fido-ret)
    300:    (define-key map (kbd "C-m") 'icomplete-fido-ret)
    301:    (define-key map (kbd "DEL") 'icomplete-fido-backward-updir)
    310:  "Keymap used by `fido-mode' in the minibuffer.")
    312:(defun icomplete--fido-mode-setup ()
    313:  "Setup `fido-mode''s minibuffer."
    315:    (use-local-map (make-composed-keymap icomplete-fido-mode-map
    324:(define-minor-mode fido-mode
    331:  (remove-hook 'minibuffer-setup-hook #'icomplete--fido-mode-setup)
    332:  (when fido-mode
    336:    (add-hook 'minibuffer-setup-hook #'icomplete--fido-mode-setup)))
    359:    (fido-mode -1)
    463:                       ((and fido-mode
    466:                        ;; `fido-mode' has some extra file-sorting

[raxod502]

@oantolin @protesilaos thank you for your kind and thoughtful feedback, it has been incorporated. (I cannot honestly say I find the capitalization "Ido" very attractive, but hey -- if it's what the authors want, it's what I'll use.)

[oantolin]

Rereading now, I think maybe this part of the Ido section could be clearer:

Furthermore, Ido is still integrated with the default completing-read framework, which means it doesn't take full advantage of a new UI paradigm.

Are you referring to the fact that Ido does not override completing-read, so Ido users don't automatically get Ido everywhere? If that's what you meant, I'd suggest something more like:

Furthermore, Ido does not override completing-read so, without further configuration (such as ido-completing-read+), users don't get the Ido experience for all completion.

And if that's not what you meant, take it as a sign that I found the current wording confusing. :P

[raxod502]

What I meant was actually something else which, on reflection, didn't make any sense. I removed the sentence.

[clemera]

Ido does not integrate with the Emacs completion API by default. Without ido-completing-read+ it won't provide completion in all appropriate places and even when using this extension not all cases are supported.

[raxod502]

Updated, thanks.

[oantolin]

So it turns out that icomplete-vertical matured pretty quickly (mostly thanks to extensive testing, bug fixes and many great feature suggestions from @protesilaos ) and I would no longer be embarrassed by it being mentioned here in the icomplete section --but I also don't mind at all if it is not mentioned!

I think that icomplete-vertical is pretty usable for vertical completion now. It does of course use icomplete's cycling mechanism which the README describes as "a serious usability problem" (which made me smile since I don't mind the cycling at all), so that's still a reason not to use it.

I'd say icomplete and icomplete-vertical do have some advantages over selectrum in the sense of being better integrated with standard Emacs infrastructure: (1) they respect the resize-mini-windows setting to allow fixed or variable height minibuffers, (2) they use the built-in completion framework (icomplete does and icomplete-vertical only tweaks the UI), so it respects the user's settings for completion-styles, completion-category-overrides, read-buffer-completion-ignore-case, completion-ignore-case, etc., (3) they work with recursive minibuffers.

[raxod502]

Ok, README updated. Thanks!

I smiled when I saw

A completion framework is probably something you don’t want to defer loading

in the README of icomplete-vertical because in my configuration I actually go to considerable effort to defer loading my completion framework :)

[oantolin]

Thanks for the update to the README!

The deferred loading thing is interesting to me! Don't you find you need it right away? I think the first thing I do with Emacs is almost always either C-x C-f, M-x or C-x r b. In all three cases I want completion. Why do you defer it?

[oantolin]

Also, it's probably time to close this issue, no?

[raxod502]

Don't you find you need it right away?

Usually. But not always, for example frequently the first thing I do is trigger one of my special keybindings to visit a specific frequently used file.

Why do you defer it?

I defer _everything_ that can be deferred. That's how I get an Emacs init time that sometimes drops below 0.33s for a fully configured graphical frame, and 0.15s for a tty frame. And there's no user-experience disadvantage to deferring packages, since the autoloading system is so solid.

Also, it's probably time to close this issue, no?

Your wish is my command :)

[aspiers]

I think you also missed https://github.com/creichert/ido-vertical-mode.el

[raxod502]

The gift that keeps on giving. Added :)

[nahuel]

there is a new contender: https://github.com/minad/vertico

[clemera]

Yes, should be added to the README, PRs welcome :) CC @minad

[minad]

Right now Vertico acts as a test bed for me before proposing upstream patches. See for example https://github.com/minad/vertico/commit/728e52df777683e08dc489e88a6bd017e25434f6. It is for adventurous people ;)

I have some small comparison in the Vertico readme, but I can also contribute a better comparison to include in Selectrum if I find time.