Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico

[T.V Raman]

That too:-)
As I said, I think of all of this broadly as a collection of
experiments, but we also need to harvest some long term results.
In addition to all I cited earlier, consider company and auto-complete
as added to the list.

If you broaden further, then you also have lsp and eglot as two ways
of bringing in lsp-servers as a backend, and again those help with
completion, so we have a lot of lego blocks, many of which fit
pairwise but at this point it's reaching a level of complexity that
doesn't likely fit in any one brain, and when that happens, you
usually see people creating more lego blocks  ...


Philip Kaludercic writes:
 > 
 > I guess I can bring up a point I've been meaning to raise here for a
 > while, and have discussed on other forums.
 > 
 > > 1. Where invoked -- anywhere in emacs vs minibuffer.
 > >    2.  When invoked -- as in find-file and friends vs everywhere
 > >       something prompts in the minibuffer.
 > >       3. Using what? the various backends that populate the available
 > >          choices.
 > >          4. How displayed: How the choices are displayed -- horizontal,
 > >             vertical, and perhaps 3-d in the future.
 > >             5. How completed: tab, vs prefix vs  fuzzy completion vs ...
 > 
 > I have the feeling all these completion systems are encouraging
 > confusion around how to use completing-read. That is the 0th point that
 > is missing here: Are you completing (expanding text) or selecting
 > (narrowing options).
 > 
 > Most completion frameworks I have looked at seem to limit themselves to
 > the latter. To simplify, they collect all the options of a collection
 > using all-completions and then narrow it depending on user input. Ido
 > and all it's descendents (Ivy, Helm, Selectrum and now vertico) seem to
 > be based on that approach.
 > 
 > Try-completion for partial completion seems to only be used by the
 > default completion system, which I think is a shame. I noticed this when
 > implementing a completion-style based on Peter Norvig's spell
 > checker[0], that would recognize minor typos such as M-x
 > evla-buffer. IIRC this kind of behaviour is not strictly correct for a
 > completing style, but that is another matter.
 > 
 > The issue I see here is how packages (in and outside of Emacs) use
 > completing-read. When package developers that use these newer completion
 > frameworks test their functions, they might tend to assume that
 > completing-read means "selecting-read", i.e. the user is presented a
 > list of options that they can choose from. A personal example is a
 > package I created a while back to insert eastern emoticons[1]
 > (¯\_(ツ)_/¯, ´ ▽ ` )ﾉ, Σ ◕ ◡ ◕, ...), that was convenient to use with
 > Ivy but since I have stopped using it has become inconvenient, as I
 > don't have most of the letters on my keyboard to complete such an
 > emoticon.
 > 
 > Nevertheless completing-read seems to have satisfied an existing need
 > for a simple mechanism to implement selection. There are packages in
 > Emacs that do this, but they all have to re-implement selection
 > interfaces, as there is no default way of doing it (that I know
 > of). Think of recentf's menu or more complex examples such as reftex's
 > TOC, that includes hierarchical structures.
 > 
 > It might therefore be necessary to actually implement a "selecting-read"
 > function, that could be used more or less like completing-read, but that
 > provides a better default UI not based around completing text but
 > actually selecting objects/items.
 > 
 > [0] https://norvig.com/spell-correct.html
 > [1] https://git.sr.ht/~zge/kaomoji
 > 
 > -- 
 >      Philip K.
 >  

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉