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 😆

[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 minad/vertico@728e52d. 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.

[1dream]

First of all thanks for this ticket and the resulting Section "Comparison of Emacs completion frameworks". Its the best comparison of Emacs completion framework I found so far and I agree that its a research project. To make this research project more manageable I suggest:

1. Close this ticket and split discussions in one ticket per framework.
2. Have one ticket "List of Emacs completion frameworks" to just add new frameworks.
3. Reference the Ticket "List of Emacs completion frameworks" on the Section "Comparison of Emacs completion frameworks"
4. Reference each Emacs completion framework specific tickets on the Section "Comparison of Emacs completion frameworks"

This will make it easier to improve the framework-specific-sections and also helps to get a better understanding how the section developed.

Another approach would be to fork the whole documentation and discussion into a dedicated git-project "Understanding, using and configuring Emacs completion Frameworks".
Setting up a new git I could do myself but would use your section as a starting point. OK?
I really believe this would be a huge value-add to the community since I know how much time I already invested in this topic and information is extremely scattered. For beginners its hard to select a Emacs completion framework.
What do you think is the better approach? Any Feedback on this idea?

[aspiers]

Agreed, it's a great resource! Both of these sound like good ideas to me. Splitting it out into an independent repo might give it a more objective, independent appearance, although I would also understand if that was not considered a high-level goal :-)

[raxod502]

I would support creating an independent, mostly neutral documentary resource which could reasonably be linked to from all the projects listed. I'm happy to create such a repository under my account, or anyone else can do the same.