[ELPA] New package: vertico

[ELPA] New package: vertico

[Daniel Mendler]

Dear ELPA maintainers,

I want to submit the package "vertico" to ELPA. The package provides a 
minimalistic vertical interactive completion system, comparable to Ivy, 
Icomplete-vertical or Selectrum. Vertico adheres to the default 
completing-read API and is fully compliant with all Emacs completion 
tables, including dynamic completion tables.

The Vertico source and a README can be found at 
https://github.com/minad/vertico.

Thank you!

Daniel Mendler

Re: [ELPA] New package: vertico

[Manuel Uberti]

On 05/04/21 12:22, Daniel Mendler wrote:
> I want to submit the package "vertico" to ELPA. The package provides a
> minimalistic vertical interactive completion system, comparable to Ivy,
> Icomplete-vertical or Selectrum. Vertico adheres to the default completing-read
> API and is fully compliant with all Emacs completion tables, including dynamic
> completion tables.
> 
> The Vertico source and a README can be found at https://github.com/minad/vertico.

FWIW, I have been using vertico as my default completion system since last
Thursday and it has been a great experience so far. It works as expected without
adding extra features that I have no need for.

Thanks Daniel for the awesome work.

-- 
Manuel Uberti
www.manueluberti.eu

Re: [ELPA] New package: vertico

[Stefan Monnier]

> I want to submit the package "vertico" to ELPA. The package provides

Thank, added,


        Stefan

Re: [ELPA] New package: vertico

[Stefan Kangas]

Daniel Mendler <mail@daniel-mendler.de> writes:

> The Vertico source and a README can be found at
> https://github.com/minad/vertico.

I think it would be useful if you could provide, preferably in the
README, an overview of what makes this package different.  It is clear
that e.g. Selectrum is more "feature complete", which you already write
in the README.  But why would I want to use Vertico instead of Ivy,
Selectrum or Icomplete-vertical?

Re: [ELPA] New package: vertico

[Daniel Mendler]

> I think it would be useful if you could provide, preferably in the
> README, an overview of what makes this package different.  It is clear
> that e.g. Selectrum is more "feature complete", which you already write
> in the README.  But why would I want to use Vertico instead of Ivy,
> Selectrum or Icomplete-vertical?

I updated the README accordingly.

Re: [ELPA] New package: vertico

[Stefan Kangas]

Daniel Mendler <mail@daniel-mendler.de> writes:

>> I think it would be useful if you could provide, preferably in the
>> README, an overview of what makes this package different.  It is clear
>> that e.g. Selectrum is more "feature complete", which you already write
>> in the README.  But why would I want to use Vertico instead of Ivy,
>> Selectrum or Icomplete-vertical?
>
> I updated the README accordingly.

Thanks!

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

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2544 bytes --]


Water water everywhere --- not a drop to drink!

The wealth of completion systems popping up speaks to the power of emacs
as a platform for both productive editting as well as rapid
experimentation --- given the wealth of completion frameworks we now
have, perhaps we could abstract out the various high-level dimensions
along which completing systems in emacs can vary -- then put together a
higher-level framework that lets one mix and match? My concern is that
if we dont leverage the current wealth of opportunities, the various
systems will each wither on the vine in their own way; as an example,
ido which has likely been around the longest amongst the new  completion
systems is  already looking unmaintained.

So here is my attempt at identifying the dimensions of variability:

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 ...

               Thoughts?

               My own thinking in this space is colored by this blog
               article I wrote a while ago:
               https://emacspeak.blogspot.com/2018/06/

               Almost all completion activity can be expressed in terms
               of a finite automaton with nodes Select, Input, Filter
               and Target.
               
               --Raman
               
Manuel Uberti <manuel.uberti@inventati.org> writes:

> On 05/04/21 12:22, Daniel Mendler wrote:
>> I want to submit the package "vertico" to ELPA. The package provides a
>> minimalistic vertical interactive completion system, comparable to Ivy,
>> Icomplete-vertical or Selectrum. Vertico adheres to the default completing-read
>> API and is fully compliant with all Emacs completion tables, including dynamic
>> completion tables.
>> 
>> The Vertico source and a README can be found at https://github.com/minad/vertico.
>
> FWIW, I have been using vertico as my default completion system since last
> Thursday and it has been a great experience so far. It works as expected without
> adding extra features that I have no need for.
>
> Thanks Daniel for the awesome work.

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

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

[Philip Kaludercic]

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.
 

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  🦮♉

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

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:

>> 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 think point 1, 2, 4 and 5, belong rather to same "layer": presentation
and user interaction, while point 3 is rather about internals, how they
process data internally.

What I personally would like to see Emacs provide is some mean to do 3.
in terms of concurency, so tools like Helm can search in different sets
of candidates in parallel. There are threads in Emacs already, but 
maybe it is too low level of interface. A tool could maybe give Emacs a
list of sets (places)and a list of regexes to search for and Emacs would
do this concurently and return a list of candidates.

For the presentation and interaction I don't think there needs to be
done much more. It is just buffers and windows and mode maps, Emacs
already has lots of tools to work with those. A tool can take a list of
candidates and present it in different ways, let user interact with that
list in buffer, minibufer or whatever author of the tool feel is the
universe's way of perfect interaction.

> they collect all the options of a collection

Can we just say they collect "candidates" or "completion candidates"
instead of "all the options of a collection"? I hope you don't mind,
just for a bit of clarity.

Helm does auto complete when the candidate is non-ambigous. But no framework
can auto complete if the choice of possible completions is non-ambigous,
i.e. there are more than one candidates.

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

[Eric Abrahamsen]

Philip Kaludercic <philipk@posteo.net> 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).

[...]

> 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.

FWIW I've come to the same conclusion in the past: that using
`completing-read' to select from a collection is essentially a (very
gentle) hack. More than once I've implemented my own mini-versions of
`selecting-read', and have always wanted something more general.

This would also allow us to expand our idea of how a thing is chosen:
instead of insisting that a string is completed, we could provide a more
general framework for choosing a "thing", where the things don't
necessarily have a meaningful string representation.

Anyway, I don't have a great solution to this problem. Here[0] is
something I wrote once to address this. I note this not because it's a
great solution (it isn't), but just as evidence of the need.

Eric

[0]: https://github.com/girzel/gnorb/blob/master/gnorb-utils.el#L222

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

[Stefan Monnier]

> FWIW I've come to the same conclusion in the past: that using
> `completing-read' to select from a collection is essentially a (very
> gentle) hack. More than once I've implemented my own mini-versions of
> `selecting-read', and have always wanted something more general.
>
> This would also allow us to expand our idea of how a thing is chosen:
> instead of insisting that a string is completed, we could provide a more
> general framework for choosing a "thing", where the things don't
> necessarily have a meaningful string representation.

I kind of agree, yet at the same time, the difference between the two is
very small in most cases.  So I think it might be worthwhile to look at
it instead as making it possible for the caller to give a *hint* about
what kind of UI would be best.

It might deserve a completely new function to replace `completing-read`,
but I think it would be good to make this new function such that it
makes `completing-read` obsolete.


        Stefan

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

[Gregory Heytings]

>
> 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).
>

I've been thinking about this, and I'm not sure I understand what the real 
difference between "completing" and "selecting" is.  Do I understand 
correctly that the difference is between, for example, expanding command 
names (completing), and choosing an emoji in a list (selecting)?

>
> 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.
>

Given that Emacs is primarily keyboard-driven, it seems to me that the 
most efficient way to select an item is, and will always be, to use a 
textual representation of the items in the list to select them.  C-x 8 RET 
does this, you (can) select an unicode character with its name.  For 
example C-x 8 RET inf RET inserts the infinity symbol.  Or course you 
could also navigate through the ~45000 unicode characters to select the 
one you want, but that would be far less efficient.

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

[Joost Kremers]

On Wed, Apr 07 2021, Gregory Heytings wrote:
> I've been thinking about this, and I'm not sure I understand what the real
> difference between "completing" and "selecting" is.  Do I understand 
> correctly that the difference is between, for example, expanding command names
> (completing), and choosing an emoji in a list (selecting)?

Yeah, I don't get it either. If I'm completing a command name, I can also say
that I'm selecting a command name from all available command names. Or when I'm
completing a file name, I'm selecting a file from all the files on my system.

In fact, I always considered that to be the whole point of "modern" completion
mechanisms: they turn completion (traditionally: start typing *from the
beginning* of the name of the candidate you are after, occasionally hitting TAB
to complete unambiguous subparts) into selection (typing *any* characters in the
name of the candidate you want to select, augmented by motion keys to move
through the list of candidates).

-- 
Joost Kremers
Life has its moments

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

[Daniel Mendler]

> On Wed, Apr 07 2021, Gregory Heytings wrote:
>> I've been thinking about this, and I'm not sure I understand what the real
>> difference between "completing" and "selecting" is.  Do I understand
>> correctly that the difference is between, for example, expanding command names
>> (completing), and choosing an emoji in a list (selecting)?
> 
> Yeah, I don't get it either. If I'm completing a command name, I can also say
> that I'm selecting a command name from all available command names. Or when I'm
> completing a file name, I'm selecting a file from all the files on my system.

I agree with both of you. I also don't see a significant difference 
between `completing-read' and a potential `selecting-read'. However, the 
`completing-read' API could benefit from a few small improvements as I 
proposed in my other mail. Given all the experience gained one may 
consider introducing a `completing-read2' which incorporates all the 
lessons learned and offers an API, which is a bit easier to use. But 
maybe the costs would outweigh the benefits and applying incremental 
improvements is actually the better approach, see for example the 
recently added `affixation-function'.

Daniel Mendler

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

[Dmitry Gutov]

On 05.04.2021 23:49, Philip Kaludercic wrote:
> 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.

I don't think that's true.

I mean, the "plain" Ido does do that, and that limits its applicability 
to a select number of commands. ido-completing-read+, however, makes an 
effort to periodically refresh the collection obtained that way.

The rest, AFAIK, do it correctly right away, dynamically refreshing the 
matches after every user input.

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

[Yuri Khan]

On Wed, 7 Apr 2021 at 19:11, Gregory Heytings <gregory@heytings.org> wrote:

> Given that Emacs is primarily keyboard-driven, it seems to me that the
> most efficient way to select an item is, and will always be, to use a
> textual representation of the items in the list to select them.  C-x 8 RET
> does this, you (can) select an unicode character with its name.  For
> example C-x 8 RET inf RET inserts the infinity symbol.  Or course you
> could also navigate through the ~45000 unicode characters to select the
> one you want, but that would be far less efficient.

This is a narrow-minded view. For one, it does not address the use
case, “I know the character I want exists, I vaguely know which script
or block it belongs to, and I will recognize it when I see it, but at
the moment I don’t remember its name or any of its aliases”.

The UI for this case is implemented in, e.g., gucharmap(1). It
consists of a sidebar with a list of filters (mostly scripts or
blocks, choosable from the View menu, but also “All”), a grid of
characters showing the filtered subset, a panel displaying information
on the currently selected character, and a search facility (on Ctrl+F
and Ctrl+G and Ctrl+Shift+G). For convenience, filters can be switched
sequentially by pressing Ctrl+Page Up and Ctrl+Page Down without
moving keyboard focus away from the grid.

You don’t have to navigate linearly through 143859 characters (as of
Unicode 13.0). You choose one of 308 blocks or 154 scripts, and then
have an overview of relevant candidates, of which you choose visually
or spatially (“last time I needed this, it was somewhere in the lower
1/3”).


Another instance of the selection UI is the Open File scenario. In
Emacs, you probably press C-x C-f and then use completing-read for the
file name with directory and consider that the most efficient way. But
I navigate via ‘dired-jump’ (bound to Super-d) and arrow keys and
‘dired-find-file’ (bound to RET) and consider this the most efficient
way for me. Again, in my mind it’s “I know where it is located and
will recognize it on sight, but I don’t want to remember the name of
it or any of its ancestor directories”.


More generally, there is a subset of users who search, and another
subset of users who browse. The latter always get frustrated when the
only UI they are offered is a search engine or a completion-enabled
text entry box.

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

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 7 Apr 2021 20:05:51 +0700
> Cc: Philip Kaludercic <philipk@posteo.net>, "T.V Raman" <raman@google.com>,
>  Manuel Uberti <manuel.uberti@inventati.org>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, 7 Apr 2021 at 19:11, Gregory Heytings <gregory@heytings.org> wrote:
> 
> > Given that Emacs is primarily keyboard-driven, it seems to me that the
> > most efficient way to select an item is, and will always be, to use a
> > textual representation of the items in the list to select them.  C-x 8 RET
> > does this, you (can) select an unicode character with its name.  For
> > example C-x 8 RET inf RET inserts the infinity symbol.  Or course you
> > could also navigate through the ~45000 unicode characters to select the
> > one you want, but that would be far less efficient.
> 
> This is a narrow-minded view.

Please try to be kinder when you post here.  Telling someone he is
narrow-minded is not exactly friendly.

> For one, it does not address the use case, “I know the character I
> want exists, I vaguely know which script or block it belongs to, and
> I will recognize it when I see it, but at the moment I don’t
> remember its name or any of its aliases”.
> 
> The UI for this case is implemented in, e.g., gucharmap(1). It
> consists of a sidebar with a list of filters (mostly scripts or
> blocks, choosable from the View menu, but also “All”), a grid of
> characters showing the filtered subset, a panel displaying information
> on the currently selected character, and a search facility (on Ctrl+F
> and Ctrl+G and Ctrl+Shift+G). For convenience, filters can be switched
> sequentially by pressing Ctrl+Page Up and Ctrl+Page Down without
> moving keyboard focus away from the grid.

This isn't completion, this is (one type of) selection dialog.  Emacs
supports some of them, although not for selecting a character, when
the user invokes a command by some mouse gesture.  (We could add an
option to pop up these dialogs even if the command was invoked by
keyboard, if people like the idea.)  For example, we have a dialog for
selecting a file and a dialog for selecting a font.

If someone wants to add a dialog for selecting a character using its
block and other attributes, such a feature will be very welcome, of
course.

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

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

>> 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).
>>
>
> I've been thinking about this, and I'm not sure I understand what the
> real difference between "completing" and "selecting" is.  Do I
> understand correctly that the difference is between, for example,
> expanding command names (completing), and choosing an emoji in a list
> (selecting)?

I think the main difference is in the UI. The default completion UI for
Emacs will expand text in-place. M-x tdoe <TAB> becomes
toggle-debug-on-error, with the initials style. This appears to make
sense for well structured text, such as commands or files.

Selection are probably situations where you want more visual feedback,
and it would make sense to present a list/tree by default. I don't think
that this has to be strictly about text.

Generally speaking, you can complete the textual representation of
anything or select the object themselves. I don't think that either is
always better, but I think we can do better than selecting textual
representations.

>> 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.
>>
>
> Given that Emacs is primarily keyboard-driven, it seems to me that the
> most efficient way to select an item is, and will always be, to use a 
> textual representation of the items in the list to select them.  C-x 8
> RET does this, you (can) select an unicode character with its name.
> For example C-x 8 RET inf RET inserts the infinity symbol.  Or course
> you could also navigate through the ~45000 unicode characters to
> select the one you want, but that would be far less efficient.

I don't think that something like selecting-read should just present a
list of string. One might imagine using methods to allow an extensible
way to control the presentation. Currently the standard procedure is to
generate a collection and it's labels before passing it to
completing-read. That's what insert-char does using ucs-names. I could
imagine that selecting-read takes a list of characters, and uses a
method to generate the textual representation of every entry. Ideally it
could lazily only calculate those entries that are currently being
displayed.

By not limiting yourself to precomputed text, the interaction can also
be improved. Taking insert-char as an example again, you might be
interested in the kind of character data that C-u C-x = provides. That
might just be a tab away. You might also be able to filter more
effectively, by narrowing the selection based on such properties.

I think I've also mentioned that selection can be hierarchical. I think
this too would be applicable to insert-char, considering how unicode
divided into groups and subgroups.

All of these features already exist, partially or only to the degree it
is found to be necessary. Eg. ibuffer has hierarchies and the ability to
filter by some preconfigured predicates. I think that there is a general
pattern here that can be exploited to make the overall experience more
uniform.

-- 
	Philip K.

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

[T.V Raman]

I tend to agree with you.

Especially with fuzzy matching, emacs complete/select pretty much
collapse into one, exceptions are things like avy which allow you  to
pick a choice based on the position of the choice in the list of
choices.


Gregory Heytings writes:
 > 
 > >
 > > 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).
 > >
 > 
 > I've been thinking about this, and I'm not sure I understand what the real 
 > difference between "completing" and "selecting" is.  Do I understand 
 > correctly that the difference is between, for example, expanding command 
 > names (completing), and choosing an emoji in a list (selecting)?
 > 
 > >
 > > 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.
 > >
 > 
 > Given that Emacs is primarily keyboard-driven, it seems to me that the 
 > most efficient way to select an item is, and will always be, to use a 
 > textual representation of the items in the list to select them.  C-x 8 RET 
 > does this, you (can) select an unicode character with its name.  For 
 > example C-x 8 RET inf RET inserts the infinity symbol.  Or course you 
 > could also navigate through the ~45000 unicode characters to select the 
 > one you want, but that would be far less efficient.

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

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

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

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

> Note that you Cc'd "emacs-develo@gnu.org" instead of
> "emacs-devel@gnu.org".

Oh, I was wondering why my mail server kept rejecting the message. Sorry
about that.


-- 
	Philip K.

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

[Stefan Monnier]

>> 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.
> I don't think that's true.

I don't think the frequency of refreshing the list of candidates is what
he was referring to, but rather the support for "TAB completion" which
corresponds to the `(completion-)try-completion` operation which is
expected to extract the commonality between the various candidates.

Most completion frameworks minimize the importance of this operation (or
don't support it at all) and instead focus on displaying the set of
candidates, filtering them, and finally picking one of them.

Seen from the point of view of the implementation, I can understand why
it's done this way: the more sophisticated your completion style is, the
harder it gets to implement `try-completion` (and often the less useful
it gets as well.  E.g. for things like `flex` it's very common for there
to be no commonality at all to extract).

So removing the `try-completion` operation makes for a simpler API
and a simpler implementation (it also simplifies significantly the
quote/unquote handling) and users who like things like `flex` won't even
notice the difference.


        Stefan

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

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 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.
>> I don't think that's true.
>
> I don't think the frequency of refreshing the list of candidates is what
> he was referring to, but rather the support for "TAB completion" which
> corresponds to the `(completion-)try-completion` operation which is
> expected to extract the commonality between the various candidates.

Just to confirm the point, yes, this was what I was referring
to.

-- 
	Philip K.

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

[Daniel Mendler]

On 4/7/21 4:15 PM, Philip Kaludercic wrote:
> I think I've also mentioned that selection can be hierarchical. I think
> this too would be applicable to insert-char, considering how unicode
> divided into groups and subgroups.

I agree that hierarchical selection can be useful when browsing through 
a structure. However when doing a quick selection, I perceive it as 
slower. For example there is imenu, where you have to step through 
multiple layers of the hierarchy to reach the destination. A popular 
demand is for a flattened imenu which allows faster completion, see for 
example the package flimenu or counsel-imenu. But as soon as you flatten 
you certainly use the ability to browse the structure, so you have some 
point.

> All of these features already exist, partially or only to the degree it
> is found to be necessary. Eg. ibuffer has hierarchies and the ability to
> filter by some preconfigured predicates. I think that there is a general
> pattern here that can be exploited to make the overall experience more
> uniform.

I wonder how all these use cases could be unified under a common API. I 
would certainly not want to lose the current fast, flat selection 
mechanism via completion as offered by `completing-read'.

Regarding predicates, there is an idea how this could be integrated with 
completion. One can implement a completion style which support a filter 
language, depending on the completion category. The completion style can 
then execute the filter predicates on the corresponding objects. However 
such an approach certainly takes it a bit far as completion styles are 
concerned. I think Icicles offers options to filter within completion 
based on predicates?

Daniel Mendler

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

[Gregory Heytings]

>> I've been thinking about this, and I'm not sure I understand what the 
>> real difference between "completing" and "selecting" is.  Do I 
>> understand correctly that the difference is between, for example, 
>> expanding command names (completing), and choosing an emoji in a list 
>> (selecting)?
>
> I think the main difference is in the UI. The default completion UI for 
> Emacs will expand text in-place. M-x tdoe <TAB> becomes 
> toggle-debug-on-error, with the initials style. This appears to make 
> sense for well structured text, such as commands or files.
>
> Selection are probably situations where you want more visual feedback, 
> and it would make sense to present a list/tree by default. I don't think 
> that this has to be strictly about text.
>
> Generally speaking, you can complete the textual representation of 
> anything or select the object themselves. I don't think that either is 
> always better, but I think we can do better than selecting textual 
> representations.
>

Okay, I think I understand your viewpoint (a bit) better now.  But:

1. It seems to me that the UI you have in mind is closer to 'transient' 
than to 'completing-read'.

2. That UI already exists to some extent in Emacs, for example dired, 
imenu (either in the menu bar or bound to a mouse event), ibuffer, the 
speedbar, ...

3. Such a UI probably wouln't fit in the (by definition) limited space of 
a minibuffer.

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

[Eric Abrahamsen]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> 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).
>>
>
> I've been thinking about this, and I'm not sure I understand what the
> real difference between "completing" and "selecting" is.  Do I
> understand correctly that the difference is between, for example,
> expanding command names (completing), and choosing an emoji in a list
> (selecting)?

"Completing" is "help me make this string longer based on available
options" and "selecting" is "choose one of these things".

Yes, they're often collapsed into one, but they don't *have* to be, for
one thing, and for another I was thinking about this more in terms of
developer convenience than making some revolutionary change to the UI.

We've all written this a million times:

(let* ((choices (mapcar (lambda (elt)
			  (cons (make-string-from-thing elt)
				elt))
			my-list-of-things))
       (choice (completing-read "Choose: "
				choices)))
  (cdr (assoc-string choice choices)))

If we put a little work into refactoring, and make a `selecting-read'
function that accepts a few other functions for doing the actual
selections, then why _not_ allow choosing from a list by number key, or
character key? Or for small collections, simply C-f/C-b and then RET? Or
cycling through a collection of buffers, displaying one buffer per
second, and letting the user hit RET when they see the one they want?
Okay that sounds awful, but flexibility is good.

I find myself wanting/needing to tailor the actual strings I produce for
collections based on the completion framework in use (ie what works well
for Helm feels awkward in Ivy, or in vanilla completion). That seems
wrong.

Anyway, that was my take on a discussion that didn't originally have
anything to do with me!

Eric

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

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

>>> I've been thinking about this, and I'm not sure I understand what
>>> the real difference between "completing" and "selecting" is.  Do I 
>>> understand correctly that the difference is between, for example,
>>> expanding command names (completing), and choosing an emoji in a
>>> list (selecting)?
>>
>> I think the main difference is in the UI. The default completion UI
>> for Emacs will expand text in-place. M-x tdoe <TAB> becomes 
>> toggle-debug-on-error, with the initials style. This appears to make
>> sense for well structured text, such as commands or files.
>>
>> Selection are probably situations where you want more visual
>> feedback, and it would make sense to present a list/tree by
>> default. I don't think that this has to be strictly about text.
>>
>> Generally speaking, you can complete the textual representation of
>> anything or select the object themselves. I don't think that either
>> is always better, but I think we can do better than selecting
>> textual representations.
>>
>
> Okay, I think I understand your viewpoint (a bit) better now.  But:
>
> 1. It seems to me that the UI you have in mind is closer to
> 'transient' than to 'completing-read'.

Perhaps, but my understanding of transient is that it tries to be a
better C-u.

> 2. That UI already exists to some extent in Emacs, for example dired,
> imenu (either in the menu bar or bound to a mouse event), ibuffer, the 
> speedbar, ...

How is this a "but"?

> 3. Such a UI probably wouln't fit in the (by definition) limited space
> of a minibuffer.

I think so, I don't think that it should have to.

-- 
	Philip K.

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

[Stefan Monnier]

>> I think I've also mentioned that selection can be hierarchical. I think
>> this too would be applicable to insert-char, considering how unicode
>> divided into groups and subgroups.
>
> I agree that hierarchical selection can be useful when browsing through
> a structure. However when doing a quick selection, I perceive it as
> slower. For example there is imenu, where you have to step through multiple
> layers of the hierarchy to reach the destination. A popular demand is for
> a flattened imenu which allows faster completion, see for example the
> package flimenu or counsel-imenu. But as soon as you flatten you certainly
> use the ability to browse the structure, so you have some point.

[ I like `completing-read`-based selection, so the below is written
  from that point of view, but I agree with Philip that it's important
  to design the API so that other UIs can also be used.  ]

For imenu, it makes sense to be able to say "v/foo" to select that
variable "foo", but also to just say "foo" when you don't want to bother
stating the category (because presumably there's only one "foo" anyway).

It would also make sense to complete unicode char names with extra
constraints like "s=foo bar" to get the chars whose name matches "bar"
and whose script matches "foo".

> I wonder how all these use cases could be unified under a common
> API. I would certainly not want to lose the current fast, flat selection
> mechanism via completion as offered by `completing-read'.

Maybe we could add methods to completion tables that return the set of
"characteristics" that can be used to filter, others that list the set
of possible values of those characteristics, etc...


        Stefan

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

[Philip Kaludercic]

Daniel Mendler <daniel@mendler.net> writes:

> On 4/7/21 4:15 PM, Philip Kaludercic wrote:
>> I think I've also mentioned that selection can be hierarchical. I think
>> this too would be applicable to insert-char, considering how unicode
>> divided into groups and subgroups.
>
> I agree that hierarchical selection can be useful when browsing
> through a structure. However when doing a quick selection, I perceive
> it as slower. For example there is imenu, where you have to step
> through multiple layers of the hierarchy to reach the destination.

Well that is because imenu presents the options in the minibuffer, and
you have to go through the menu step-by-step. What I'm talking about is
a direct hierarchical visualisation, that should be navigable with the
intuitiveness of org-mode.

>> All of these features already exist, partially or only to the degree it
>> is found to be necessary. Eg. ibuffer has hierarchies and the ability to
>> filter by some preconfigured predicates. I think that there is a general
>> pattern here that can be exploited to make the overall experience more
>> uniform.
>
> I wonder how all these use cases could be unified under a common
> API. I would certainly not want to lose the current fast, flat
> selection mechanism via completion as offered by `completing-read'.

I don't think that selecting-read should replace completing-read. Rather
there are cases where completing-read is used like selecting-read, that
would profit from actually being selected by everyone, and not just
those who use completion frameworks that interpret completion as
selection.

> Regarding predicates, there is an idea how this could be integrated
> with completion. One can implement a completion style which support a
> filter language, depending on the completion category. The completion
> style can then execute the filter predicates on the corresponding
> objects. However such an approach certainly takes it a bit far as
> completion styles are concerned. I think Icicles offers options to
> filter within completion based on predicates?

I think there is more value in keeping completing-read simple, and focus
it on actual text expansion. Completing-read will probably never really
be overcome, just because there will always be software that continues
to use it.

In some sense the abundance of solutions around completion show that the
community wants something else than what completing-read provides by
default. I get why, as a lot of packages use completing-read. But it
might be better to start from the position we want to achieve, instead
of hacking our way towards that end.

> Daniel Mendler
>
>

-- 
	Philip K.

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

[Daniel Mendler]

On 4/7/21 6:14 PM, Stefan Monnier wrote:
>> I wonder how all these use cases could be unified under a common
>> API. I would certainly not want to lose the current fast, flat selection
>> mechanism via completion as offered by `completing-read'.
> 
> Maybe we could add methods to completion tables that return the set of
> "characteristics" that can be used to filter, others that list the set
> of possible values of those characteristics, etc...

This sounds like a good idea too.

In the context of the Orderless completion style we discussed some 
alternative, which is backward compatible but which bents the definition 
of a completion style a bit. In Orderless each token is used separately 
for filtering and the order of the tokens does not matter, e.g., 
"regexp1 regexp2 regexp3". The idea was to add some special character as 
token prefix to allow filtering by metadata/characteristics, e.g., if 
one filters buffers one could write "@elisp", where the string "elisp" 
is not matched against the candidate string but against some kind of 
metadata string. The metadata would be supplied by an extra function 
registered for the completion category. Your approach is certainly more 
direct.

What I like about the idea of registering such a metadata supplier 
separately is that it allows to enhance completion tables afterwards, 
even if you are not the author of the completion table. There exist a 
few packages enhancing existing completion tables by associating some 
functionality via the completion category:

* Marginalia (https://github.com/minad/marginalia) adds 
annotation/affixation functions
* Embark (https://github.com/oantolin/embark) adds minibuffer actions, 
similar to Ivy actions

But in the context of Emacs itself this approach is probably less 
interesting, maybe except for decoupling some concerns in the code base.

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

[Gregory Heytings]

>> 1. It seems to me that the UI you have in mind is closer to 'transient' 
>> than to 'completing-read'.
>
> Perhaps, but my understanding of transient is that it tries to be a 
> better C-u.
>

By 'transient', I meant the ELPA transient package.  My understanding is 
that it makes it possible to navigate through a tree, with a visual 
feedback in a popup buffer.

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

[Daniel Mendler]

On 4/7/21 6:20 PM, Philip Kaludercic wrote:
> Well that is because imenu presents the options in the minibuffer, and
> you have to go through the menu step-by-step. What I'm talking about is
> a direct hierarchical visualisation, that should be navigable with the
> intuitiveness of org-mode.

This is a bit vague. If we have a tree structure one can have some 
tree-like visualization (like the sidebar tree browsers) or have an 
outline like in org-mode. But how would you actually navigate quickly? 
Using Avy-like keys? What if the structure does not fit on the screen 
easily, what if there are cycles, ...?

In the case of `completing-read` the current solutions are all pretty 
simple. If we ignore the special cases of dynamic completion tables, you 
just hand it this big flat list and filter until the data set becomes 
manageable. While some use cases seem to be a bit pressed into that 
framework (like if you have a hammer...), I think it works surprisingly 
well in many scenarios with a large number of unstructured candidates.

To me it seems much harder to imagine something general which caters for 
all selection needs using an outline-like visualization.

> I don't think that selecting-read should replace completing-read. Rather
> there are cases where completing-read is used like selecting-read, that
> would profit from actually being selected by everyone, and not just
> those who use completion frameworks that interpret completion as
> selection.
> I think there is more value in keeping completing-read simple, and focus
> it on actual text expansion. 

Agree. Regarding "interpreting completion as selection" and "text 
expansion", I am unsure if there is a big difference. You always start 
with a set of possible completions and only for very few styles a prefix 
completion is possible. This has been mentioned before in this thread, I 
think.
> In some sense the abundance of solutions around completion show that the
> community wants something else than what completing-read provides by
> default. I get why, as a lot of packages use completing-read. But it
> might be better to start from the position we want to achieve, instead
> of hacking our way towards that end.

I am actually quite satisfied with the status quo given the many package 
options, where everyone seems to find a good fit. But maybe the name 
`completing-read` does not reflect anymore what it is since it is often 
used for something else than simple prefix expansion. The prefix/basic 
completion is baked pretty deeply in the completion APIs, e.g., 
`all-completions` and this got relaxed afterwards.

Daniel

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

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

>>> 1. It seems to me that the UI you have in mind is closer to
>>> 'transient' than to 'completing-read'.
>>
>> Perhaps, but my understanding of transient is that it tries to be a
>> better C-u.
>
> By 'transient', I meant the ELPA transient package.  My understanding
> is that it makes it possible to navigate through a tree, with a visual 
> feedback in a popup buffer.

But transient popups are static, right? You (usually) wouldn't compute
them on the fly. I get what you mean from the UI perspective, I don't
think that transient would be a good basis for something like
selecting-read.

-- 
	Philip K.

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

[Gregory Heytings]

>>>> 1. It seems to me that the UI you have in mind is closer to 
>>>> 'transient' than to 'completing-read'.
>>>
>>> Perhaps, but my understanding of transient is that it tries to be a 
>>> better C-u.
>>
>> By 'transient', I meant the ELPA transient package.  My understanding 
>> is that it makes it possible to navigate through a tree, with a visual 
>> feedback in a popup buffer.
>
> But transient popups are static, right? You (usually) wouldn't compute 
> them on the fly. I get what you mean from the UI perspective, I don't 
> think that transient would be a good basis for something like 
> selecting-read.
>

Yes, I meant something like the transient UI, but computed on the fly.  I 
wasn't suggesting to use transient as a basis for something else, my 
remark was only about the look of the UI.

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

[Drew Adams]

> Regarding predicates, there is an idea how this could be
> integrated with completion. One can implement a completion
> style which support a filter language, depending on the
> completion category. The completion style can then execute
> the filter predicates on the corresponding objects. However
> such an approach certainly takes it a bit far as completion
> styles are concerned.
>
> I think Icicles offers options to filter within completion
> based on predicates?

I've avoided chiming in on this discussion, which
I think, so far, is a bit reductive and simplistic.

Icicles provides (and I hope other completion
frameworks do too) lots of other, related, features
that aren't covered by the categories raised so far
(including the S.I.F.T categories in T.V. Raman's
interesting blog post:
https://emacspeak.blogspot.com/2018/06/).

But I'll speak to your last sentence.  Yes, Icicles
lets you provide predicates on the fly, to further
filter completion candidates.

(Of course, Emacs completion has always used
predicates.  This is instead about users providing
predicates interactively, on the fly, to narrow a
set of candidates.)

You can progressively provide both additional match
patterns and additional predicates.  To add another
match pattern you use `S-SPC'.  To add another
predicate you use `C-u S-SPC'.

I call this process of completion by successive
approximation, or progressively narrowing the
candidate set, "progressive completion".  (`S-SPC'
and similar have `narrow' in their command names.)

You could instead call it "incremental completion",
aka icompletion, but that term was taken long ago
by Icomplete for something much more limited.

To provide a predicate to apply on the fly, you type
its name or a lambda-expression for it.

Completion (lax) is available for this predicate input,
against known predicates for the particular kind of
candidates - e.g., buffer-name predicates for buffer-name
completion.

You can customize the predicates available for a given
completion TYPE with options `icicle-cand-preds-for-TYPE'.

If you provide a prefix arg to the underlying command
for predicate completion, then all predicates from a
different option, `icicle-cand-preds-all', are available.

Predefined `icicle-cand-preds-for-TYPE':

 icicle-cand-preds-for-bookmark
 icicle-cand-preds-for-buffer
 icicle-cand-preds-for-color
 icicle-cand-preds-for-face
 icicle-cand-preds-for-file
 icicle-cand-preds-for-frame
 icicle-cand-preds-for-misc
 icicle-cand-preds-for-package
 icicle-cand-preds-for-symbol
 icicle-cand-preds-for-variable
 icicle-cand-preds-for-window

To compose a lambda expression, you can use any keys
in `icicle-read-expression-map' that don't conflict
with completion keys.  (Since `TAB' conflicts, you can
use `C-M-i' or `ESC tab' to complete a Lisp symbol.)

You can use `C-M-&' (`icicle-save-predicate-to-variable')
during completion to save the current predicate (all
predicates composed so far) as a string-valued variable.

You can retrieve the saved string later, using `C-='
at the prompt for a predicate. You can thus build up
a complex predicate, and save it for later use.

The inconvenience of typing an Emacs-Lisp sexp is
balanced against the power of applying predicates on
the fly.  Pattern (regexp, fuzzy, whatever) matching
is purely syntactic, but a predicate can perform
semantic tests.

During search, for instance, you can look not only
for a syntax match; you can also limit candidates to
a particular class of objects (function, variable,
type...) or that satisfy some other semantic property.

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

[Drew Adams]

> cycling through a collection of buffers, displaying
> one buffer per second, and letting the user hit RET
> when they see the one they want?

This kind of thing is already available, with just
`completing-read'.  You can show anything as visual
candidates.  With Icicles, for example, you can show
image files as their thumbnails in *Completions*.
(Or show their names; or show both.)

You don't need to type input to match the file names -
you can just cycle through the (thumbnail) candidates
and hit RET to choose one (or hit `C-RET' to choose
any number of them).  You don't need to know or care
what their names are.  The same applies to choosing
Unicode chars or whatever - you don't need to match
their names.

[You could also attach sounds to candidates, so that
when you cycle to one you hear its sound.  Pretty
much anything you can sense could be used to choose.
(And pretty much anything you can input could be
used to filter.)]

But you also _CAN_ match their names.  And that's
super important.  You can filter names to narrow the
field of things you cycle through to choose from.

Cycling is _not_ the most wonderful way to choose
things.  Don't be a cycling drone!  Use pattern
matching (and maybe predicate filtering) to narrow
the set of things you then cycle among.

And, at least with Icicles, you can UN-narrow the
current narrowing level, and then narrow differently.
So you can cycle among different sets of candidates
(from the initial domain).

> Okay that sounds awful, but flexibility is good.

It's not awful, even if it might sound so.  It's
just one more tool.  And yes, flexibility is good.

But let's not underestimate the value of pattern
matching against "string" candidates.  Nothing
beats that (as someone else said in this thread).

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

[Drew Adams]

> > I agree that hierarchical selection can be useful when browsing
> > through a structure. However when doing a quick selection, I perceive
> > it as slower. For example there is imenu, where you have to step
> > through multiple layers of the hierarchy to reach the destination.
> 
> Well that is because imenu presents the options in the minibuffer, and
> you have to go through the menu step-by-step. What I'm talking about is
> a direct hierarchical visualisation, that should be navigable with the
> intuitiveness of org-mode.

The difference you're describing is like the difference
between `tmm-menubar' (which makes you navigate down a
menubar tree step by step) and La Carte, which lets you
do that or not.  Completion candidates are full paths
to menu items.

With a reasonable completion system (even just substring
matching helps) you can type a pattern that shows submenus
and menu items at any level.  You can get directly to a
given item with a single pattern, if you want.

(But it's typically better to combine simple patterns
than to try to provide an exact complex pattern to match
what you want.)

https://www.emacswiki.org/emacs/LaCarte

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

[Drew Adams]

> If we have a tree structure one can have some
> tree-like visualization (like the sidebar tree browsers) or have an
> outline like in org-mode. But how would you actually navigate quickly?
> Using Avy-like keys? What if the structure does not fit on the screen
> easily, what if there are cycles, ...?

Just pattern-match against candidates that are "full".
You can even match circular/cyclic candidates, if you
use predicates.  (An infinite candidate can't be shown
as a printed representation, but it can be matched.)

> In the case of `completing-read` the current solutions are all pretty
> simple. If we ignore the special cases of dynamic completion tables, you
> just hand it this big flat list and filter until the data set becomes
> manageable.

Yes.

> While some use cases seem to be a bit pressed into that
> framework (like if you have a hammer...), I think it works surprisingly
> well in many scenarios with a large number of unstructured candidates.

Yes.

> To me it seems much harder to imagine something general which caters for
> all selection needs using an outline-like visualization.

The visualization is separate from how things are
matched.  Your eye can match something graphic,
but your input filtering can match against its
"name" (some textual way to identify it). or its
position in the completion list.

Wrt position: You can have candidates that are
different but that have the same textual
representation, and so are matched by the same
input.  When sorted you can traverse (cycle among)
a set of candidates in a given sort order to
choose one.

An example of this is Icicles search.  Your
input might match multiple candidates exactly -
they might have exactly the same text.  But
you can navigating among them (cycling), to
choose in context.

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-04-07 15:10]:
> > 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).
> > 
> 
> I've been thinking about this, and I'm not sure I understand what the real
> difference between "completing" and "selecting" is.  Do I understand
> correctly that the difference is between, for example, expanding command
> names (completing), and choosing an emoji in a list (selecting)?

It is comselecting. It is now with new completion packages completing
and selecting in the same time. It started with completing and it
evolved into selecting. Emacs is peculiar, we need to find new words.

Let me mention that I heavily use completion usually for more than
20000 items, sometimes 50000 or more, all candidates are imported from
a PostgreSQL database. I mention this that you keep it in mind while
developing packages.

And I often use lines with ID numbers, as that way I can easier use
completions which are not Helm. Helm allows me to complete with
candidate ABC which yields with ID number 123. But if I have a simple
list, I use it this way:

(rcd-completing-read-sql-hash "Choice: " "SELECT notes_id, notes_name
FROM notes" *cf*)

Which is using standard completing read and constructs candidates
like:

Possible completions are:
 * The large majority of the CU members will be Brazilian  [19252]
 1. You would not be able to advertise, however, you  [20225]
 3. generally take within 24hrs [20226]

Then when a string is selected, the ID is obtained from within
brackets.

I hope this not to interrupt with new developments.

> > 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.

It maybe possible to improve tabulated-list-mode so that it may be
used for selection of items.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Jean Louis]

* Joost Kremers <joostkremers@fastmail.fm> [2021-04-07 15:32]:
> 
> On Wed, Apr 07 2021, Gregory Heytings wrote:
> > I've been thinking about this, and I'm not sure I understand what the real
> > difference between "completing" and "selecting" is.  Do I understand 
> > correctly that the difference is between, for example, expanding command names
> > (completing), and choosing an emoji in a list (selecting)?
> 
> Yeah, I don't get it either. If I'm completing a command name, I can also say
> that I'm selecting a command name from all available command names. Or when I'm
> completing a file name, I'm selecting a file from all the files on
> my system.

When user completes, user brings to a whole one of candidates, but in
general, does not necessary selects it. Completion of a candidate
preceds selection. Maybe some packages select or may be tuned to
select as soon as candidate is completed, I personally find that
dangerous.

Using external completion like dmenu or rofi, fzf or similar, is
useful when Emacs run on the command line.

(defun dmenu-completing-read (prompt collection)
  ;; &optional predicate require-match initial-input history def inherit-input-method)
  "Uses external `dmenu' command for Emacs completions."
  (let* ((collection (concat (string-join collection "\n") "\n"))
	 (file (string-to-file-force collection "/dev/shm/collection"))
	 (dmenu "dmenu"))
    (with-temp-buffer
      (call-process dmenu file (current-buffer) nil "-fn" "DejaVu:pixelsize=30" "-l" "10" "-i" "-b" "-p" prompt "-nb" "dark goldenrod" "-nb" "black")
      (string-trim (buffer-string)))))

(dmenu-completing-read "Hello: " '("John" "Joe" "Baby"))

In general I would like completion to work on the command line,
without frame, as well.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-04-07 17:44]:
> I don't think that something like selecting-read should just present a
> list of string. One might imagine using methods to allow an extensible
> way to control the presentation. Currently the standard procedure is to
> generate a collection and it's labels before passing it to
> completing-read. That's what insert-char does using ucs-names. I could
> imagine that selecting-read takes a list of characters, and uses a
> method to generate the textual representation of every entry. Ideally it
> could lazily only calculate those entries that are currently being
> displayed.

It is great when in the list of candidates for presentation other data
may be stored similarly like it is stored in tabuluated-list-mode
where one can get the ID and full entry of data, and similarly how it
is stored in Helm where I can select the presented string such as:

"Joe Doe" and get the ID 2

and that is where sometimes duplicates could appear and it is fine for
duplicates to appear in those cases, as user may know that second Joe
Doe is from Mexico, first one from USA, so choosing second below would
reach to right ID which ID is then hidden in the presentation.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Philip Kaludercic]

Daniel Mendler <mail@daniel-mendler.de> writes:

> On 4/7/21 6:20 PM, Philip Kaludercic wrote:
>> Well that is because imenu presents the options in the minibuffer, and
>> you have to go through the menu step-by-step. What I'm talking about is
>> a direct hierarchical visualisation, that should be navigable with the
>> intuitiveness of org-mode.
>
> This is a bit vague. If we have a tree structure one can have some
> tree-like visualization (like the sidebar tree browsers) or have an 
> outline like in org-mode. But how would you actually navigate quickly?
> Using Avy-like keys? What if the structure does not fit on the screen 
> easily, what if there are cycles, ...?

I'm still thinking about all of this, and have to find the time to
implement a prototype. It might make sense to have a similar approach to
completing-read, where a variable like completing-read-function can
change everything.

A tree-like visualisation would probably make more sense, as long as it
can be manipulated using the keyboard. I mentioned org-mode thinking of
the org-cycle command, and how it allows you to hide and show subtrees.

> In the case of `completing-read` the current solutions are all pretty
> simple. If we ignore the special cases of dynamic completion tables,
> you just hand it this big flat list and filter until the data set
> becomes manageable. While some use cases seem to be a bit pressed into
> that framework (like if you have a hammer...), I think it works
> surprisingly well in many scenarios with a large number of
> unstructured candidates.

I use the default completion system, so for me it is not about filtering
a data set but expanding a string. Just to reiterate, this is exactly
the point I am bringing this up.

> To me it seems much harder to imagine something general which caters
> for all selection needs using an outline-like visualization.

It might be that it is too far fetched, but I have a (vague) idea how
selecting-read might look like and behave. A proper analysis of the
current situation and (imo) misuse of completing-read would probably be
necessary before actually building anything. 

>> I don't think that selecting-read should replace completing-read. Rather
>> there are cases where completing-read is used like selecting-read, that
>> would profit from actually being selected by everyone, and not just
>> those who use completion frameworks that interpret completion as
>> selection.
>> I think there is more value in keeping completing-read simple, and focus
>> it on actual text expansion. 
>
> Agree. Regarding "interpreting completion as selection" and "text
> expansion", I am unsure if there is a big difference. You always start 
> with a set of possible completions and only for very few styles a
> prefix completion is possible. This has been mentioned before in this
> thread, I think.

I don't start with any set, I start with an (usually) empty prompt and
type a few letter, tab to check and then press enter. I try to avoid
unnecessary UI movement, which is why I have set
completion-cycle-threshold to t, so that I have to manually request a
"*Completions*" buffer. But even so, there are situations where
selection would be preferable. Usually when I don't know what my options
are.

>> In some sense the abundance of solutions around completion show that the
>> community wants something else than what completing-read provides by
>> default. I get why, as a lot of packages use completing-read. But it
>> might be better to start from the position we want to achieve, instead
>> of hacking our way towards that end.
>
> I am actually quite satisfied with the status quo given the many
> package options, where everyone seems to find a good fit. But maybe
> the name `completing-read` does not reflect anymore what it is since
> it is often used for something else than simple prefix expansion. The
> prefix/basic completion is baked pretty deeply in the completion APIs,
> e.g., `all-completions` and this got relaxed afterwards.

Well FWIW I'm not. I used Ivy for a long while, but ultimately gave it
up. There has been a lot of talk about {Selectrum,Embark,Orderless,...}
recently but I am not convinced that the approach these packages take
are on the right level. The only way to find out is to try something
else on the level I suspect there might be more potential for a better
solution.

> Daniel
>

-- 
	Philip K.

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

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

> Yes, I meant something like the transient UI, but computed on the fly.
> I wasn't suggesting to use transient as a basis for something else, my 
> remark was only about the look of the UI.

Maybe, but my knowledge of transient is too limited to say.

-- 
	Philip K.

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

[Jean Louis]

* Daniel Mendler <mail@daniel-mendler.de> [2021-04-07 19:57]:
> On 4/7/21 6:20 PM, Philip Kaludercic wrote:
> > Well that is because imenu presents the options in the minibuffer, and
> > you have to go through the menu step-by-step. What I'm talking about is
> > a direct hierarchical visualisation, that should be navigable with the
> > intuitiveness of org-mode.
> 
> This is a bit vague. If we have a tree structure one can have some tree-like
> visualization (like the sidebar tree browsers) or have an outline like in
> org-mode. But how would you actually navigate quickly? Using Avy-like keys?
> What if the structure does not fit on the screen easily, what if there are
> cycles, ...?

I would like to have a tree structure to be able to select items in
the tree like the outline, but generated in the dynamic way. It is
similar to selection dialog.

One package I know that has something similar, is Semantic Synchrony:

Semantic Synchrony
https://github.com/synchrony/smsn

I am now using tabulated-list-mode to browse hierarchical trees and
select items, it is shown on this video:
https://open.tube/videos/watch/392f1a79-bd5e-4516-adf5-4ce9f73973c7

Sometimes it would be good to open sub-nodes in the same buffer and
select from same buffer, similar like it is shown in Semantic
Synchrony: https://www.youtube.com/watch?v=R2vX2oZmUUM

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-04-07 22:14]:
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
> > On 4/7/21 6:20 PM, Philip Kaludercic wrote:
> >> Well that is because imenu presents the options in the minibuffer, and
> >> you have to go through the menu step-by-step. What I'm talking about is
> >> a direct hierarchical visualisation, that should be navigable with the
> >> intuitiveness of org-mode.
> >
> > This is a bit vague. If we have a tree structure one can have some
> > tree-like visualization (like the sidebar tree browsers) or have an 
> > outline like in org-mode. But how would you actually navigate quickly?
> > Using Avy-like keys? What if the structure does not fit on the screen 
> > easily, what if there are cycles, ...?
> 
> I'm still thinking about all of this, and have to find the time to
> implement a prototype. It might make sense to have a similar approach to
> completing-read, where a variable like completing-read-function can
> change everything.
> 
> A tree-like visualisation would probably make more sense, as long as it
> can be manipulated using the keyboard. I mentioned org-mode thinking of
> the org-cycle command, and how it allows you to hide and show
> subtrees.

When selecting items in tabulated-list-mode, all of them have the ID,
but some IDs have its type of being a Set or subtree. When subtree is
choosen a new frame appears with its nodes.

Similarly, completing-read could even now browse trees, it is matter
of recognizing which item belong to a tree to immediately offer
another completing-read with the nodes of the subtree. Subtrees cannot
be selected, but those nodes or candidates which are not subtrees they
can be selected.

I am using strings with IDs like "Selection candidate [123]" and that
is how I extract the ID of the item, then I can test for it if it is a
subtree or not and offer new completing read on that.

(defun string-cut-right-square-bracket-reference (s)
  "Returns the reference within square brackets on the end of S."
  (let* ((space (string-match " " (reverse s))))
    (if space
	(let* ((id (substring (reverse s) 0 space)))
	  (if (and (string-match "\\[" id)
		   (string-match "\\]" id))
	      (replace-regexp-in-string "\\[\\\|\\]" "" (reverse id))
	    nil))
      nil)))

(string-cut-right-square-bracket-reference "Selection candidate [123]") → "123"

(setq set '(10 20))
(setq collection-data '(("Candidate A" 10)
			("Candidate B" 11)
			("Candidate C" 20)
			("Candidate D" 12)
			("Candidate E" 13)
			("Candidate D" 14)))
(setq collection-verify collection-data)

(setq collection nil)

(while collection-data
  (let ((item (pop collection-data)))
    (push (format "%s [%s]" (car item) (cadr item)) collection)))

(completing-read "Choose item: " collection) → "Candidate A [10]"

Concept is here:

(defun completing-read-tree (prompt collection)
  (while (member (string-to-number
		  (string-cut-right-square-bracket-reference
		   (completing-read "Choose: " collection)))
		 set)
    (completing-read-tree prompt collection))) ;; at this point `collection'
					       ;; would be replaced
					       ;; with collection that
					       ;; belongs to
					       ;; particular set and
					       ;; browsing trees with
					       ;; completing read goes
					       ;; deeper and deeper. A
					       ;; key would be
					       ;; required to go back.


(completing-read-tree "Choose: " collection)

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Daniel Mendler]

On 4/7/21 9:13 PM, Philip Kaludercic wrote:
> I'm still thinking about all of this, and have to find the time to
> implement a prototype. It might make sense to have a similar approach to
> completing-read, where a variable like completing-read-function can
> change everything.
> 
> A tree-like visualisation would probably make more sense, as long as it
> can be manipulated using the keyboard. I mentioned org-mode thinking of
> the org-cycle command, and how it allows you to hide and show subtrees.

I am looking forward to seeing a prototype!

> I use the default completion system, so for me it is not about filtering
> a data set but expanding a string. Just to reiterate, this is exactly
> the point I am bringing this up.

Well, but what does this mean in the context of opening a file? I guess, 
you are not interested in the string (the file name) alone but in the 
end you want to select a file?

> Well FWIW I'm not. I used Ivy for a long while, but ultimately gave it
> up. There has been a lot of talk about {Selectrum,Embark,Orderless,...}
> recently but I am not convinced that the approach these packages take
> are on the right level. The only way to find out is to try something
> else on the level I suspect there might be more potential for a better
> solution.

Why? I would love to hear a more detailed criticism since I am involved 
with those packages. You are again a bit vague. These packages just try 
to work with what we have API-wise from the side of Emacs. But regarding 
the presentation of the completion results, the views of the authors of 
the respective packages you mention vary. Omar, the author of Embark and 
Orderless, has written four completion UIs which are mostly derived from 
default completion, Clemens has Selectrum, I have recently made Vertico. 
But all these packages somehow cooperate despite the different preferences.

Daniel

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

[Juri Linkov]

> It maybe possible to improve tabulated-list-mode so that it may be
> used for selection of items.

You meant to improve completing-read to support tabulated-list-mode?

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

[Dmitry Gutov]

On 07.04.2021 17:44, Stefan Monnier wrote:
>>> 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.
>> I don't think that's true.
> 
> I don't think the frequency of refreshing the list of candidates is what
> he was referring to, but rather the support for "TAB completion" which
> corresponds to the `(completion-)try-completion` operation which is
> expected to extract the commonality between the various candidates.
> 
> Most completion frameworks minimize the importance of this operation (or
> don't support it at all) and instead focus on displaying the set of
> candidates, filtering them, and finally picking one of them.

I don't know if they really do minimize it: the TAB binding in 
company-active-map, pressing TAB once in Ivy, and likely equivalent 
bindings in other systems, all complete the "common" part to let the 
user continue typing to resolve ambiguities.

That's something a pure "selection UI" wouldn't have. And I do think it's

> Seen from the point of view of the implementation, I can understand why
> it's done this way: the more sophisticated your completion style is, the
> harder it gets to implement `try-completion` (and often the less useful
> it gets as well.  E.g. for things like `flex` it's very common for there
> to be no commonality at all to extract).
> 
> So removing the `try-completion` operation makes for a simpler API
> and a simpler implementation (it also simplifies significantly the
> quote/unquote handling) and users who like things like `flex` won't even
> notice the difference.

A try-completion operation might indeed be complex to implement for some 
completion styles, but it's not like we really tried it. Perhaps it 
would be difficult to design the "externally filtering" completion 
style, together with this new operation, but I feel like we've never 
even reached the point if trying to do that, having met other 
difficulties along the way.

Perhaps we could dispense with this feature when designing a new 
completion table interface, just for simplicity's sake (though I don't 
see why we couldn't add it as an option in a later revision).

What I was disagreeing in the previous message, is whether it's worth to 
create a semantic distinction between completing-read and 
selecting-read. How would a Lisp author choose between the two? The 
former should actually be more powerful (it will retain support for TAB 
completion, and yet it could still be supported by selection-style 
frameworks such as Company or Ivy); the latter, on the other hand, would 
effectively mandate a minimum "niceness" of the UI (though not 
necessarily nicer than the former, depending on user customization), but 
would be unable to support more advanced completion tables. Such as ones 
with "fields" (which includes file name completion).

So it seems the guiding principle might be: use selecting-read for 
"simple" completion tables. But I don't see why this direction is desirable.

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

[Philip Kaludercic]

Daniel Mendler <mail@daniel-mendler.de> writes:

>> I use the default completion system, so for me it is not about filtering
>> a data set but expanding a string. Just to reiterate, this is exactly
>> the point I am bringing this up.
>
> Well, but what does this mean in the context of opening a file? I
> guess, you are not interested in the string (the file name) alone but
> in the end you want to select a file?

I'm not sure what you are asking here? I'm interested in the file, but I
designate it by it's name.

>> Well FWIW I'm not. I used Ivy for a long while, but ultimately gave it
>> up. There has been a lot of talk about {Selectrum,Embark,Orderless,...}
>> recently but I am not convinced that the approach these packages take
>> are on the right level. The only way to find out is to try something
>> else on the level I suspect there might be more potential for a better
>> solution.
>
> Why? I would love to hear a more detailed criticism since I am
> involved with those packages. You are again a bit vague.

My vagueness stems from my uncertainty. I just think that the general
idea (completion as selection) isn't what I am interested in, but I
don't want to make claims I am not sure of.

-- 
	Philip K.

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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> What I was disagreeing in the previous message, is whether it's worth
> to create a semantic distinction between completing-read and 
> selecting-read. How would a Lisp author choose between the two? The
> former should actually be more powerful (it will retain support for
> TAB completion, and yet it could still be supported by selection-style 
> frameworks such as Company or Ivy); 

completing-read can be more powerful, as it includes expanding text and
selecting items, but I if you are not interested in text-expansion you
should probably limit yourself to selection, so that everyone is ensured
to have the same presentation.

> the latter, on the other hand, would effectively mandate a minimum
> "niceness" of the UI (though not necessarily nicer than the former,
> depending on user customization), but would be unable to support more
> advanced completion tables. Such as ones with "fields" (which includes
> file name completion).

What do you mean by "niceness", and why would it not be able to support
more complex tables?

-- 
	Philip K.

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

[Drew Adams]

> > Regarding "interpreting completion as selection" and "text
> > expansion", I am unsure if there is a big difference. You always start
> > with a set of possible completions and only for very few styles a
> > prefix completion is possible. This has been mentioned before in this
> > thread, I think.
> 
> I don't start with any set, I start with an (usually)
> empty prompt and type a few letter, tab to check and
> then press enter.

You start with empty input.  But when starting the
operation (reading input with possible candidates
for completion) you are also starting with a set
of candidates that you can conveniently choose -
a domain of choices.

The set of such convenient choices is _not_ limited
to those provided to `completing-read' by way of
its COLLECTION argument.  (And that argument can be
a function, which can provide an infinite number of
candidates.)

It includes the "candidates" of the DEF list, which
you can also choose from easily, albeit in a
different way (e.g. M-p, M-r) from using TAB.

Similar considerations apply to `read-file-name',
and even other read functions, including
`read-from-minibuffer'.  Some such functions don't
even provide for "completion", and yet they let you
easily choose among a specified set of "candidates".

And those are just the candidates you can choose
_conveniently_.  Many read functions let you input
nearly any text.  Even lax completion (nil REQUIRE)
lets you do that.

You want to separate a notion of "selection" from
a notion of "completion" (the latter in the Emacs
sense).  That unnecessarily focuses not on the user
actions (input, choosing, acting on, canceling...)
but on _one kind_ of resulting action: replacing
some input string with an output string.  That's
quite limiting.

(And note that even in that case the output need
not be longer than - a real "completion" of - the
input.)

That's a narrow focus, and isn't very helpful, IMO.

Something like `completing-read' or `read-file-name'
(or even `read-from-minibuffer') has multiple moving
parts - different subsystems, providing different
functionalities.  What's important is their possible
use together - the synergy they provide.

Suppose we focus on that whole - the combination
(and probably including other functionalities not
yet included).  Do we need a new name, instead of
"completion"?  I think not, but I don't really care
(except for a maintenance burden renaming entails).

Sure, "completion" doesn't really mean all of those
things.  But it never meant all of what Emacs has
always provided for its "completion".  So what?

I like finding "le mot juste" as much as the next
person.  But at some point it just doesn't matter.
No one is getting confused by Emacs using the term
"completion" to mean such a constellation of things,
I expect.

And sometimes there _isn't_ a mot juste.  And just
inventing a new word van be more of a cop-out than
a solution to the fact that "completion" in its
usual sense doesn't cover all of what Emacs means
by that term.

> But even so, there are situations where selection
> would be preferable. Usually when I don't know
> what my options are.

Emacs "completion" is multidimensional.  That's the
point.  Don't call it "completion" if the term
bothers you.  The point is that you can make use of
it in any direction/dimension or any combination
of them.

> > I am actually quite satisfied with the status quo given the many
> > package options, where everyone seems to find a good fit. But maybe
> > the name `completing-read` does not reflect anymore what it is since
> > it is often used for something else than simple prefix expansion. The
> > prefix/basic completion is baked pretty deeply in the completion APIs,
> > e.g., `all-completions` and this got relaxed afterwards.
> 
> Well FWIW I'm not.

You already said that for you it's "not about
filtering a data set but expanding a string."

You reject a point of view that "it's about" a
bunch of things, working together, to achieve
lots of different kinds of goals.

If you limit yourself to a single, expand-a-string
purpose, then it's not surprising that you, well,
ultimately find yourself limited.  That doesn't
mean that what Emacs (already) offers is limited.

(Sounds like the classic joke about someone hitting
his head against the wall and a doctor prescribing,
as remedy, "Don't do that.")

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

[Dmitry Gutov]

On 08.04.2021 01:59, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> What I was disagreeing in the previous message, is whether it's worth
>> to create a semantic distinction between completing-read and
>> selecting-read. How would a Lisp author choose between the two? The
>> former should actually be more powerful (it will retain support for
>> TAB completion, and yet it could still be supported by selection-style
>> frameworks such as Company or Ivy);
> 
> completing-read can be more powerful, as it includes expanding text and
> selecting items, but I if you are not interested in text-expansion you
> should probably limit yourself to selection,

Am "I" in this example the user, or the author of the caller code?

 >  so that everyone is ensured
 > to have the same presentation.

If that's the goal, why don't we make sure to include a "selection" 
interface that supports text-expansion as well, like both Company and 
Ivy do?

What's the purpose of having that distinction?

>> the latter, on the other hand, would effectively mandate a minimum
>> "niceness" of the UI (though not necessarily nicer than the former,
>> depending on user customization), but would be unable to support more
>> advanced completion tables. Such as ones with "fields" (which includes
>> file name completion).
> 
> What do you mean by "niceness",

Niceness is subjective, hence the quotes, but we can probably agree that 
the UIs that do selection usually look fancier than the ones than don't. 
Or at least that's what I meant.

 > and why would it not be able to support
 > more complex tables?

If it can, that goes back to my question of why have the distinction.

If it allow selection UIs to not guarantee support for certain 
completion tables, I suppose that would allow people to create some 
specialized single-purpose UIs (perhaps mouse-driven?). Not sure if it's 
worth it, though.

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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 08.04.2021 01:59, Philip Kaludercic wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> What I was disagreeing in the previous message, is whether it's worth
>>> to create a semantic distinction between completing-read and
>>> selecting-read. How would a Lisp author choose between the two? The
>>> former should actually be more powerful (it will retain support for
>>> TAB completion, and yet it could still be supported by selection-style
>>> frameworks such as Company or Ivy);
>> completing-read can be more powerful, as it includes expanding text
>> and
>> selecting items, but I if you are not interested in text-expansion you
>> should probably limit yourself to selection,
>
> Am "I" in this example the user, or the author of the caller code?

The I was probably a typo.

>>  so that everyone is ensured
>> to have the same presentation.
>
> If that's the goal, why don't we make sure to include a "selection"
> interface that supports text-expansion as well, like both Company and 
> Ivy do?
>
> What's the purpose of having that distinction?

My hypothisis is that selection is held back by completing-read, and
that a framework that is explicitly made for selection and not
retrofitted into the existing framework could stand to improve the user
experience.

-- 
	Philip K.

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

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2273 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:


In the spirit of exerimentation I'd second what Stefan suggested,

Step 1: Create a selection oriented equivalent of completing-read

2. See how that works out --

3. Then, compare it with completing-read -- and see if we can derive a
   master composite function that handles both use-cases well.

   completing-read has been around for a long time which means: The
   good -- it has withstood the test of time -- and possibly bad: it's
   constraining  with respect to backward compatibility and trying new
   things.

   We've now experimented in Emacs with entire packages trying to offer
   alternatives;  let's now use that learning to move toward building
   the correct lower-level support functions, and the suggestion above
   is trying to be the next step in that process
   
>
>> On 08.04.2021 01:59, Philip Kaludercic wrote:
>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>> 
>>>> What I was disagreeing in the previous message, is whether it's worth
>>>> to create a semantic distinction between completing-read and
>>>> selecting-read. How would a Lisp author choose between the two? The
>>>> former should actually be more powerful (it will retain support for
>>>> TAB completion, and yet it could still be supported by selection-style
>>>> frameworks such as Company or Ivy);
>>> completing-read can be more powerful, as it includes expanding text
>>> and
>>> selecting items, but I if you are not interested in text-expansion you
>>> should probably limit yourself to selection,
>>
>> Am "I" in this example the user, or the author of the caller code?
>
> The I was probably a typo.
>
>>>  so that everyone is ensured
>>> to have the same presentation.
>>
>> If that's the goal, why don't we make sure to include a "selection"
>> interface that supports text-expansion as well, like both Company and 
>> Ivy do?
>>
>> What's the purpose of having that distinction?
>
> My hypothisis is that selection is held back by completing-read, and
> that a framework that is explicitly made for selection and not
> retrofitted into the existing framework could stand to improve the user
> experience.

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

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

[Drew Adams]

> > What's the purpose of having that distinction?
> 
> My hypothisis is that selection is held back
> by completing-read,

Why do you think so?  Held back in what way(s)?
Details, please.

> and that a framework that is explicitly made for
> selection and not retrofitted into the existing
> framework could stand to improve the user experience.

Again, why do you think so?

This is as vague as a suggestion to rewrite Emacs
so it uses Rust (or Python or Scheme or whatever)
instead of Lisp, with no attempt to say what the
need for that is or the advantages would be.

I'm not arguing that `completing-read' has no
room for improvement.  In fact, I'm the first to
say (and to have said, and shown) that there's
plenty of room.

(I've actually improved it in many ways, in my
own code and practice.  Lots of details and
experience with my own "proposed" changes to it.)

But a vague argument at the level of "selecting"
versus "completing" doesn't cut it, in my book.

Push the existing envelope first, to see where
the real limits of `completing-read' are, before
asking for an overhaul.

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

[Philip Kaludercic]

"T.V Raman" <raman@google.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>
> In the spirit of exerimentation I'd second what Stefan suggested,
>
> Step 1: Create a selection oriented equivalent of completing-read

To clarify, this already exists with Helm, Ivy, etc. I'm working on a
framework that is primarily centred around selection.

> 2. See how that works out --

Yes, and this will probably take a few attempts to get right too. I hope
there will be interest to discuss different approaches on this list.

> 3. Then, compare it with completing-read -- and see if we can derive a
>    master composite function that handles both use-cases well.

This might be possible, but I'm sceptical.

-- 
	Philip K.

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

[T.V Raman]

agreed it exists in various places, the next step is to distill
something down that can be in Emacs Core --

Philip Kaludercic writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > Philip Kaludercic <philipk@posteo.net> writes:
 > >
 > >
 > > In the spirit of exerimentation I'd second what Stefan suggested,
 > >
 > > Step 1: Create a selection oriented equivalent of completing-read
 > 
 > To clarify, this already exists with Helm, Ivy, etc. I'm working on a
 > framework that is primarily centred around selection.
 > 
 > > 2. See how that works out --
 > 
 > Yes, and this will probably take a few attempts to get right too. I hope
 > there will be interest to discuss different approaches on this list.
 > 
 > > 3. Then, compare it with completing-read -- and see if we can derive a
 > >    master composite function that handles both use-cases well.
 > 
 > This might be possible, but I'm sceptical.
 > 
 > -- 
 > 	Philip K.

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

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

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

[Philip Kaludercic]

Drew Adams <drew.adams@oracle.com> writes:

>> > What's the purpose of having that distinction?
>> 
>> My hypothisis is that selection is held back
>> by completing-read,

> Why do you think so?  Held back in what way(s)?
> Details, please.

Can completing-read offer a hierarchical overview, allow inspection into
selected items, ensure that calls return values eq to the input, lazily
compute textual representations when they are needed?  Starting from a
clean slate and intentionally designing an alternative function around
selection would seem to have the advantage that we already know that
people want, instead of having to fight what we already have.

>> and that a framework that is explicitly made for
>> selection and not retrofitted into the existing
>> framework could stand to improve the user experience.
>
> Again, why do you think so?
>
> This is as vague as a suggestion to rewrite Emacs
> so it uses Rust (or Python or Scheme or whatever)
> instead of Lisp, with no attempt to say what the
> need for that is or the advantages would be.
>
> I'm not arguing that `completing-read' has no
> room for improvement.  In fact, I'm the first to
> say (and to have said, and shown) that there's
> plenty of room.
>
> (I've actually improved it in many ways, in my
> own code and practice.  Lots of details and
> experience with my own "proposed" changes to it.)
>
> But a vague argument at the level of "selecting"
> versus "completing" doesn't cut it, in my book.
>
> Push the existing envelope first, to see where
> the real limits of `completing-read' are, before
> asking for an overhaul.

I am not proposing an overhaul, but to make the job easier for
completing-read. Instead of continuing to extend it by adding additional
special arguments and finding loopholes in the current implementations
of selection frameworks, I argue that a cleaner and more consistent
solution can be found in trying to understand when selection is wanted,
and how a solution that can be provided that directly solves the
problem.

I don't want to sound like a "Rewrite X in Y" kind of guy, because I
don't want to replace completing-read. I like it, and I like it
simple. Maybe it doesn't make sense to have both, but some
experimentation is necessary before that can be concluded.

-- 
	Philip K.

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

[Dmitry Gutov]

On 08.04.2021 17:44, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 08.04.2021 01:59, Philip Kaludercic wrote:
>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>>
>>>> What I was disagreeing in the previous message, is whether it's worth
>>>> to create a semantic distinction between completing-read and
>>>> selecting-read. How would a Lisp author choose between the two? The
>>>> former should actually be more powerful (it will retain support for
>>>> TAB completion, and yet it could still be supported by selection-style
>>>> frameworks such as Company or Ivy);
>>> completing-read can be more powerful, as it includes expanding text
>>> and
>>> selecting items, but I if you are not interested in text-expansion you
>>> should probably limit yourself to selection,
>>
>> Am "I" in this example the user, or the author of the caller code?
> 
> The I was probably a typo.

I was asking what you meant by "you", actually. Probably not important 
at this point.

>>>   so that everyone is ensured
>>> to have the same presentation.
>>
>> If that's the goal, why don't we make sure to include a "selection"
>> interface that supports text-expansion as well, like both Company and
>> Ivy do?
>>
>> What's the purpose of having that distinction?
> 
> My hypothisis is that selection is held back by completing-read, and
> that a framework that is explicitly made for selection and not
> retrofitted into the existing framework could stand to improve the user
> experience.

Ah... all right. So the idea could be to annotate the cases where 
text-expansion is not needed. I'm not sure there is a good way to make 
that determination, though. OTOH, I can imagine cases which pretty much 
*need* selection-like interface. xref-show-definitions-completing-read 
would be one example (it's relatively awkward to make the choice using 
completion, though certainly not impossible).

And I think I have a simple idea of a selection-centric completion UI: 
ones that use TAB for other things, like iteration between completions 
(without intermediate steps, like one TAB expands, next ones iterate). 
VS Code's dropdown completion kind of does that. YouCompleteMe's 
completion popup does too.

So which I personally prefer hybrid approaches, this seems like a good 
avenue to explore. But I'm not sure we can decide on criteria for when 
text-expansion is really needed (or not), aside from the user's preference.

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

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 08.04.2021 17:44, Philip Kaludercic wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> On 08.04.2021 01:59, Philip Kaludercic wrote:
>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>>>
>>>>> What I was disagreeing in the previous message, is whether it's worth
>>>>> to create a semantic distinction between completing-read and
>>>>> selecting-read. How would a Lisp author choose between the two? The
>>>>> former should actually be more powerful (it will retain support for
>>>>> TAB completion, and yet it could still be supported by selection-style
>>>>> frameworks such as Company or Ivy);
>>>> completing-read can be more powerful, as it includes expanding text
>>>> and
>>>> selecting items, but I if you are not interested in text-expansion you
>>>> should probably limit yourself to selection,
>>>
>>> Am "I" in this example the user, or the author of the caller code?
>> The I was probably a typo.
>
> I was asking what you meant by "you", actually. Probably not important
> at this point.
>
>>>>   so that everyone is ensured
>>>> to have the same presentation.
>>>
>>> If that's the goal, why don't we make sure to include a "selection"
>>> interface that supports text-expansion as well, like both Company and
>>> Ivy do?
>>>
>>> What's the purpose of having that distinction?
>> My hypothisis is that selection is held back by completing-read, and
>> that a framework that is explicitly made for selection and not
>> retrofitted into the existing framework could stand to improve the user
>> experience.
>
> Ah... all right. So the idea could be to annotate the cases where
> text-expansion is not needed. I'm not sure there is a good way to make
> that determination, though. OTOH, I can imagine cases which pretty
> much *need* selection-like interface.
> xref-show-definitions-completing-read would be one example (it's
> relatively awkward to make the choice using completion, though
> certainly not impossible).

This is exactly the sort of use-case I think selection would be perfect
for. As another data point, Gnus has `gnus-multiple-choice', yet another
approach to the problem.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 8 Apr 2021 21:59:31 +0300
> Cc: emacs-devel@gnu.org
> 
> I can imagine cases which pretty much *need* selection-like
> interface. xref-show-definitions-completing-read would be one
> example (it's relatively awkward to make the choice using
> completion, though certainly not impossible).

I don't think I understand how xref-show-definitions-completing-read
is different from, say, read-file-name.  Can you explain?

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

[Tassilo Horn]

Daniel Mendler <mail@daniel-mendler.de> writes:

>> I use the default completion system, so for me it is not about
>> filtering a data set but expanding a string. Just to reiterate, this
>> is exactly the point I am bringing this up.
>
> Well, but what does this mean in the context of opening a file? I
> guess, you are not interested in the string (the file name) alone but
> in the end you want to select a file?

I'm not sure that's what your are asking but one thing that comes to
mind is that when I want to find the file

  ~/Repos/el/emacs/lisp/doc-view.el

I can just do

  C-x C-f reeld<TAB>

and that will already expand to ~/Repos/el/emacs/l/d if
`completion-styles' contains `initials' (and
`read-file-name-completion-ignore-case' set to t).  Now depending on
what I type further, it'll also switch between lisp/ or lib/ directory.

AFAIK, that's not really supported with (most) alternative completion
UIs where the possible completions are always the files of the currently
selected directory.  Of course, you can work around that by having a
"completion source" returning all files below a directory recursively
(fzf style) but that tends to be slow if there are many.

Bye,
Tassilo

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

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]


Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> We've all written this a million times:
>
> (let* ((choices (mapcar (lambda (elt)
> 			  (cons (make-string-from-thing elt)
> 				elt))
> 			my-list-of-things))
>        (choice (completing-read "Choose: "
> 				choices)))
>   (cdr (assoc-string choice choices)))

Sorry, I didn't follow the whole thread (too long), here some Helm
features you may not be aware of:


(helm-comp-read "test: " '(("un" . 1) ("deux" . 2) ("trois" . 3)))
=> 1
(helm-comp-read "test: " '(("un" . 1) ("deux" . 2) ("trois" . 3)) :alistp nil)
=> "un"
(helm-comp-read "test: " '(("un" . 1) ("deux" . 2) ("trois" . 3)) :marked-candidates t)
=> (1)
(helm-comp-read "test: " '(("un" . 1) ("deux" . 2) ("trois" . 3)) :marked-candidates t :alistp nil)
=> ("un")

Hope that helps.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Daniel Mendler]

On 4/9/21 8:21 AM, Tassilo Horn wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
>>> I use the default completion system, so for me it is not about
>>> filtering a data set but expanding a string. Just to reiterate, this
>>> is exactly the point I am bringing this up.
>>
>> Well, but what does this mean in the context of opening a file? I
>> guess, you are not interested in the string (the file name) alone but
>> in the end you want to select a file?
> 
> I'm not sure that's what your are asking but one thing that comes to
> mind is that when I want to find the file
> 
>    ~/Repos/el/emacs/lisp/doc-view.el
> 
> I can just do
> 
>    C-x C-f reeld<TAB>
> 
> and that will already expand to ~/Repos/el/emacs/l/d if
> `completion-styles' contains `initials' (and
> `read-file-name-completion-ignore-case' set to t).  Now depending on
> what I type further, it'll also switch between lisp/ or lib/ directory.
> 
> AFAIK, that's not really supported with (most) alternative completion
> UIs where the possible completions are always the files of the currently
> selected directory.

The completion you describe works with Vertico. The candidate set is 
updated accordingly in the UI.

    (setq completion-category-overrides nil)
    (setq completion-category-defaults nil)
    (setq completion-styles '(initials))
    (vertico-mode)

However what does not work is the further narrowing in an Orderless 
fashion (your lisp/lib selection). This is what I assume you want to do? 
One could use both initials+orderless completion styles, but then one 
would also need a feature in the completion system which locks the 
current candidate set. There is the Restricto package by Omar, who is 
also the author of Orderless. Restricto essentially replaces the 
minibuffer-completion table with the current candidate subset - a bit of 
a hack if you ask me. And probably Icicles supports something like this 
out of the box?

The idea is basically to lock the candidate set and switch between 
completion styles. This feature does not seem to be available in the 
Emacs completion mechanism directly.

Daniel Mendler

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

[Jean Louis]

* Juri Linkov <juri@linkov.net> [2021-04-07 23:39]:
> > It maybe possible to improve tabulated-list-mode so that it may be
> > used for selection of items.
> 
> You meant to improve completing-read to support tabulated-list-mode?

What I mean is:

- to be able to offer either list of strings or list of lists with
  various data

- data is automatically formatted to fit into tabulated-list-mode

- user may select one or more entries in tabulated-list-mode by
  browsing or filtering

- user may press RET or something else to select, the
  tabulated-list-mode buffer is burried and selection taken.

Now if that or similar flow can be glued to completing-read even
better, it would be great.

I find default completing-read in many cases superior to various
completion packages, but this may be due to my personalized habits of
using TAB, using "-" to complete shorter or using  wildcard "*". But
those completions are interferring with the work. They are focusing on
minibuffer or other window where user is expected to do exactly that
what program wants, usually user cannot exit from there and review
other window, or do some other selection.

The concept I have explained I already use in a limited manner and it
offers me browsing from one set of data to other set of data.

But I do not have possibility (yet) to construct tabulated-list-frame
and just click to get the result.

Small example on what I would need:

(defun complete-by-tab ()
  (let ((tabulated-list-format [("ID" 10 t) ("Name" 30 t) ("Group" 30 t)])
	(tabulated-list-entries '((1 ["1" "Joe" "Friends"]) (2 ["2" "Jane" "Love"]) (3 ["3" "Jimmy" "Job"])))
	(buffer (generate-new-buffer "Tabulated List Mode")))
    (switch-to-buffer buffer)
    (tabulated-list-mode)
    (setq tabulated-list-padding 1)
    (tab-select-local-map)
    (tabulated-list-init-header)
    (tabulated-list-print)))

(defvar-local rcd-tabulated-marked-items nil
  "Collects IDs for tabulated list modes")

(defun rcd-tabulated-mark-id ()
  "To mark entries"
  (interactive)
  (let ((id (tabulated-list-get-id)))
    (when id
      (tabulated-list-put-tag "⇉" t)
      (cl-pushnew id rcd-tabulated-marked-items))))
      ;; (message "Marked ID %s (%s)" id rcd-tabulated-marked-items))))

(defun tab-select-local-map ()
  (interactive)
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map tabulated-list-mode-map)
    (define-key map "m" 'rcd-tabulated-mark-id)
    (define-key map (kbd "RET") '(lambda () (interactive)
				   (if rcd-tabulated-marked-items
				       (setq my-selection rcd-tabulated-marked-items)
				     (setq my-selection (list (tabulated-list-get-id))))
				   (quit-window)))
    (use-local-map map)))

(complete-by-tab)

Now after this I can mark entries or select one entry, that is fine, and I get result:

my-selection ⇒ (3 2 1)

Not bad...

But I would like to find the solution to return the result back to program execution.

As this below does not work how I would like it:

(progn
  (complete-by-tab)
  (message "%s" my-selection))

Result is that I cannot get the selection. Maybe if I use
with-temp-buffer and invoke tabulated-list-mode?

I would like to know how to wait without blocking for
complete-by-tab until it finishes it execution that I can read
`my-selection'.

tabulated-list-mode is great tool for menu and submenu browsing,
or tree browsing. But it is not visible tree on the page, I have
to create new frames to browse subtres, which is not bad for now.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Drew Adams]

> then one would also need a feature in the completion
> system which locks the current candidate set...
>
> probably Icicles supports something like this
> out of the box?

Yes.  `S-SPC' puts you in a recursive minibuffer,
where you can provide a new pattern, which is then
matched against the candidates that matched the
previous pattern.  This is an "AND" operation
(intersection).

As usual, whatever you type is matched on the fly:
as you change the pattern, the matching candidates
change.  But all of them match the pattern you
used for the parent minibuffer.

You can exit any minibuffer level and continue
with its parent.  So the "locking in" doesn't
lock once and for all.  It just has the effect of
exploring, in a new minibuffer, the candidates
that are current when you hit `S-SPC'.

When you end that exploration (whether or not you
acted on any candidates there) you can return to
the parent minibuffer and continue where you left off.

Or not.  You can "finally" choose a candidate in
a child minibuffer and thus end completion
altogether.  Or you can "finally" end without
choosing any candidate at any level.

So this is related to the ability to act on
(multiple) candidates without ending completion.
This is part of what makes Icicles useful for
exploration/discovery.

[You can also go in the other direction, ORing
(union) instead of ANDing, using `S-backspace'
instead of `S-SPC'.  That's more limited; it
essentially just ORs a new pattern you enter.]

> The idea is basically to lock the candidate
> set and switch between completion styles.

In Icicles it's completely decoupled from any
switch of completion styles.  You can switch
completion-style lists anytime, and you need
not switch when you use `S-SPC' to prompt for
a new, independent match pattern.

You can use multiple different patterns, and
each can be matched using any list of
completion styles.

You can make use of the completion styles of
vanilla Emacs, but you're not limited to any
styles or any set (list) of them.

Emacs's notion and use of completion styles
has this important limitation:

All completion candidates you see come from
the same style.  You have no control over
which style will actually be used for any
given input, other than ordering the list
ahead of time.

And you have no way of knowing which style
was actually used to produce a given set of
candidates.  The relation between your input
pattern and the matches is thus sometimes not
so clear.

There's no way to know, for example, that
initial matching failed and partial matching
succeeded.

Sometimes you might not care what style
matched.  If your only aim is to obtain some
candidate, in whatever way, then Emacs style
lists might suffice.

That's apparently the sole design aim: maximize
the possibility of getting a match.  In that, I
guess it's tied to the aim of completing, and
divorced from any aim of finding out whether a
given pattern (e.g. of a given kind) matches.

That difference is perhaps relevant for the
distinction of "completing" from "selecting"
introduced in this thread by the OP.

In vanilla Emacs, the current set (list) of
`completion-styles' can only be used together
- it's all or none; they're never alternatives
that you can choose among at runtime.

Besides supporting completion styles, Icicles
lets you choose (anytime) among completion
_methods_, which are alternatives.  Only one
method is used at a time.

Method `vanilla' just uses the current set of
completion styles, which, as in vanilla Emacs,
means try one style after the other until one
succeeds at matching or none do.

But even for completion styles Icicles offers
choice.  You can define multiple style sets,
with option `icicle-completion-style-sets'.
During completion you change to another set
(list).

Among other things, this means you can try to
complete using one style set and, if that fails,
switch to another.  Any of the sets can contain
any number of styles, in any order.

In particular, a set can be a singleton, which
means that you can selectively try to complete
using different individual styles.  That is,
you can use individual styles, like methods,
as alternatives.

Icicles thus gives you more flexibility than
vanilla Emacs for using completion styles.  But
completion methods are used more than styles.

> This feature does not seem to be available
> in the Emacs completion mechanism directly.

Right.

Progressive completion:

https://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion

Completion methods and styles:

https://www.emacswiki.org/emacs/Icicles_-_Completion_Methods_and_Styles

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

[Tassilo Horn]

Daniel Mendler <mail@daniel-mendler.de> writes:

Hi Daniel,

>> I'm not sure that's what your are asking but one thing that comes to
>> mind is that when I want to find the file
>>    ~/Repos/el/emacs/lisp/doc-view.el
>> I can just do
>>    C-x C-f reeld<TAB>
>> and that will already expand to ~/Repos/el/emacs/l/d if
>> `completion-styles' contains `initials' (and
>> `read-file-name-completion-ignore-case' set to t).  Now depending on
>> what I type further, it'll also switch between lisp/ or lib/ directory.
>> AFAIK, that's not really supported with (most) alternative completion
>> UIs where the possible completions are always the files of the currently
>> selected directory.
>
> The completion you describe works with Vertico.  The candidate set is
> updated accordingly in the UI.
>
>    (setq completion-category-overrides nil)
>    (setq completion-category-defaults nil)
>    (setq completion-styles '(initials))
>    (vertico-mode)

Indeed, I've just tried it out.

> However what does not work is the further narrowing in an Orderless
> fashion (your lisp/lib selection). This is what I assume you want to
> do?

Well, I've guessed that already the `initials' completion wouldn't work
at all.  So with my recipe above I've got

  ~/Repos/el/emacs/lib/deps/

as the first completion candidate.  When I TAB there, it'll expand to
just that.  In order to find ~/Repos/el/emacs/lisp/doc-view.el, it seems
I need to scroll the list of possible completions which is very long.

> One could use both initials+orderless completion styles, but then one
> would also need a feature in the completion system which locks the
> current candidate set. There is the Restricto package by Omar, who is
> also the author of Orderless. Restricto essentially replaces the
> minibuffer-completion table with the current candidate subset - a bit
> of a hack if you ask me.

Yes, probably, but it helps in the situation I sketched.

Well, but I guess the better way to find doc-view.el with vertico is to
just do

  C-x C-f reel
  Hit TAB on the ~/Repos/el/emacs/lisp/ candidate being pretty much on
      top of the list.
  do<TAB>

BTW, more a question to the list (and Stefan in particular): I actually
have several emacs worktrees

  ~/Repos/el/emacs/
  ~/Repos/el/emacs-27/
  ~/Repos/el/emacs-native-comp/

With the `completion-category-overrides'

     (file
      (styles basic partial-completion initials))

(actually, just `initials' suffices) and the input ~/Reeld<TAB> the
expansion is ~/Repos/el/emacs/l/d, and the completion help just shows
lib/d*, lisp/d*, and lwlib/d* files.  Shouldn't it also consider
{lib,lisp,lwlib}/d* in emacs-27/ and emacs-native-comp/?

When I rename the emacs-27 directory to e27, it'll include the files in
there.  So the reason seems to be that my emacs-*/ worktrees start with
emacs and TAB expands to the shortest possibility neglecting longer
ones.  It seems like the files below ~/Repos/el/emacs-27/ is completely
inaccessible in the presence of ~/Repos/el/emacs/ using the initials
style.  Of course, when I move point to ~/Repos/el/emacs|/l/d (| being
point) and hit TAB, I can complete any emacs-* worktree.

> The idea is basically to lock the candidate set and switch between
> completion styles.  This feature does not seem to be available in the
> Emacs completion mechanism directly.

I understand the idea but I'm not sure how convenient it would be to
enable/disable styles using key bindings during completion.  In general,
I prefer if it just does what I want. ;-)

Bye,
Tassilo

Re: [ELPA] New package: vertico

[Tassilo Horn]

Hi Daniel,

I've tried and liked it and I've also worked on my aggressive-completion
package to make it usable with vertico.  aggressive-completion basically
hits TAB for you during minibuffer completion in order to release stress
from your pinky.

Right now, I'm using aggressive-completion-mode together with vertico
using this configuration:

--8<---------------cut here---------------start------------->8---
;; Disable completion help since vertico shows the candidates anyhow.
(setq aggressive-completion-auto-completion-help nil)

;; A command which just expands the common part without selecting a candidate.
(defun th/vertico-complete ()
  (interactive)
  (minibuffer-complete)
  (vertico--exhibit))

;; Use that for auto-completion.
(setq aggressive-completion-auto-complete-fn #'th/vertico-complete)

(vertico-mode)
(aggressive-completion-mode)
--8<---------------cut here---------------end--------------->8---

Now I have two questions:

1. Shouldn't there be a command like `th/vertico-complete' which
   completes the common part of the candidates?

2. One annoying effect with the above command and vertico is that the
   typical completion messages such as "Next char not unique" bump point
   to the right, i.e., with stock minibuffer completion you have

     my-input| [Next char not unique]

   whereas with vertico you have

     my-input [Next char not unique]|

   where | indicates point.  Why is that?

Thanks for the nice package!

Bye,
Tassilo

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

[Dmitry Gutov]

On 09.04.2021 08:56, Eli Zaretskii wrote:
>> I can imagine cases which pretty much*need*  selection-like
>> interface. xref-show-definitions-completing-read would be one
>> example (it's relatively awkward to make the choice using
>> completion, though certainly not impossible).
> I don't think I understand how xref-show-definitions-completing-read
> is different from, say, read-file-name.  Can you explain?

We've touched on this previously in the poll/discussion about the default:

https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00029.html

The values which xref-show-definitions-completing-read asks you to 
choose from are relatively complex, and hard to type out.

Further, there's often only 2-3 values to choose from (in the Elisp's 
case, at least), so choosing the first one should be a frequent enough 
occasion.

With a selection-based menu you look at all options and make a choice: 
often just press RET; maybe press TAB, or C-n, or <down> a few times 
before that.

With completing-read, you have to press TAB first, to see the choices, 
and then type some of your choice's contents, keeping in mind perhaps 
its distinguishing characteristics. That's simply more effort than the 
other approach.

File name completion is different because you're not as likely to simply 
choose the first option, there can be a *lot* of files in the dir, and 
typing an average file name is much easier.

Mind you, I generally prefer completion UIs that show the options before 
you start typing, but xref-show-definitions-completing-read makes a 
really strong case for it. Which is unfortunate, because otherwise it's 
my #1 choice for xref-show-definitions-function's default value, and 
changing Emacs's completion UI is not in the cards in any near future.

So I would only be happy if you disagree with this assessment.

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

[Dmitry Gutov]

On 09.04.2021 07:21, Eric Abrahamsen wrote:
> As another data point, Gnus has `gnus-multiple-choice', yet another
> approach to the problem.

It's now in the core as read-multiple-choice.

Good option to have, though I haven't found many occasions to use it for.

project-switch-project uses a similar menu, but its choices ended up 
being more complex than single chars.

Re: [ELPA] New package: vertico

[Daniel Mendler]

Hi Tassilo!

> I've tried and liked it and I've also worked on my aggressive-completion
> package to make it usable with vertico.  aggressive-completion basically
> hits TAB for you during minibuffer completion in order to release stress
> from your pinky.

That's an interesting idea. I've seen your package before, but didn't 
read through the whole thread.

> Right now, I'm using aggressive-completion-mode together with vertico
> using this configuration:
I will give this a try!

> Now I have two questions:
> 
> 1. Shouldn't there be a command like `th/vertico-complete' which
>     completes the common part of the candidates?

Vertico follows the design where you put less importance on the 
prefix/TAB completion but instead excepts the user to enter more text 
for narrowing, which works well with the orderless completion style.

But note that Vertico is fully compatible with default completion, so as 
you observed you can just use `minibuffer-complete`. If you bind 
`minibuffer-complete` to the `vertico-map` it will work. See 
https://github.com/minad/vertico#keymap.

Is that good enough or do you have something else in mind?

> 2. One annoying effect with the above command and vertico is that the
>     typical completion messages such as "Next char not unique" bump point
>     to the right, i.e., with stock minibuffer completion you have
> 
>       my-input| [Next char not unique]
> 
>     whereas with vertico you have
> 
>       my-input [Next char not unique]|
> 
>     where | indicates point.  Why is that?

Yes, I've also observed issues with minibuffer messages appearing at the 
wrong place. Vertico uses overlays to display the candidate count and 
the candidate list, similar to Icomplete. Icomplete however removes the 
overlay in the pre-command-hook and puts the overlay back in the 
post-command-hook. I am not doing that. I just move the overlay to the 
end but it seems this solution is not good enough. Since I have not yet 
understood fully what the problem is I haven't done anything yet to fix 
the issue.

Besides, my recommendation would be to deactivate those messages. I 
think they are pretty annoying. I suspect even more so in combination 
with aggressive-completion.

(advice-add #'vertico--setup :after
             (lambda (&rest _)
               (setq-local completion-auto-help nil
                           completion-show-inline-help nil)))

> Thanks for the nice package!

Thank you!

Daniel Mendler

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

[Stefan Monnier]

> Mind you, I generally prefer completion UIs that show the options before you
> start typing, but xref-show-definitions-completing-read makes a really
> strong case for it. Which is unfortunate, because otherwise it's my #1
> choice for xref-show-definitions-function's default value, and changing
> Emacs's completion UI is not in the cards in any near future.
>
> So I would only be happy if you disagree with this assessment.

I think it would be desirable to change the default UI just enough so
that a code like Xref can make `completing-read` display the
completions eagerly.

One thing we can already do is to make Xref use a completion category
with an entry in `completion-category-defaults` which specifies a value
of t for `completion-cycle-threshold`.  This way a simple TAB should
select the first entry.


        Stefan

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

[Dmitry Gutov]

On 10.04.2021 02:48, Stefan Monnier wrote:
>> Mind you, I generally prefer completion UIs that show the options before you
>> start typing, but xref-show-definitions-completing-read makes a really
>> strong case for it. Which is unfortunate, because otherwise it's my #1
>> choice for xref-show-definitions-function's default value, and changing
>> Emacs's completion UI is not in the cards in any near future.
>>
>> So I would only be happy if you disagree with this assessment.
> 
> I think it would be desirable to change the default UI just enough so
> that a code like Xref can make `completing-read` display the
> completions eagerly.

The *Completions* window, you mean? It would still miss the ability to 
quickly accept one of them with RET.

> One thing we can already do is to make Xref use a completion category
> with an entry in `completion-category-defaults` which specifies a value
> of t for `completion-cycle-threshold`.  This way a simple TAB should
> select the first entry.

The result is... interesting. Not my first choice of the UI, but it does 
improve on the issue I mentioned above (while missing the ability to 
look at all options at once, which is particularly useful for the 
function is question).

Does anybody feel like it's an improvement enough to make 
xref-show-definitions-completing-read a viable default?

Here's the patch to try (though we might want to replace t with a number 
like 4):

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5f594679ca..0ba55916c9 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -957,7 +957,8 @@ completion-category-defaults
      ;; A new style that combines substring and pcm might be better,
      ;; e.g. one that does not anchor to bos.
      (project-file (styles . (substring)))
-    (xref-location (styles . (substring)))
+    (xref-location . ((styles . (substring))
+                      (cycle . t)))
      (info-menu (styles . (basic substring))))
    "Default settings for specific completion categories.
  Each entry has the shape (CATEGORY . ALIST) where ALIST is

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

[Stefan Monnier]

>> I think it would be desirable to change the default UI just enough so
>> that a code like Xref can make `completing-read` display the
>> completions eagerly.
> The *Completions* window, you mean?

I was thinking of a somewhat generic way to tell the UI that the list
should be shown eagerly.  Presumably the default UI would react to it by
displaying the *Completions* window, yes.

> It would still miss the ability to quickly accept one of them
> with RET.

Right, but the cycle-threshold helps with that, no?


        Stefan

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

[Eric Abrahamsen]

Thierry Volpiatto <thievol@posteo.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> We've all written this a million times:
>>
>> (let* ((choices (mapcar (lambda (elt)
>> 			  (cons (make-string-from-thing elt)
>> 				elt))
>> 			my-list-of-things))
>>        (choice (completing-read "Choose: "
>> 				choices)))
>>   (cdr (assoc-string choice choices)))
>
> Sorry, I didn't follow the whole thread (too long), here some Helm
> features you may not be aware of:
>
>
> (helm-comp-read "test: " '(("un" . 1) ("deux" . 2) ("trois" . 3)))
> => 1
> (helm-comp-read "test: " '(("un" . 1) ("deux" . 2) ("trois" . 3)) :alistp nil)
> => "un"
> (helm-comp-read "test: " '(("un" . 1) ("deux" . 2) ("trois" . 3)) :marked-candidates t)
> => (1)
> (helm-comp-read "test: " '(("un" . 1) ("deux" . 2) ("trois" . 3))
> :marked-candidates t :alistp nil)
> => ("un")
>
> Hope that helps.

Thanks! I think this is mostly about improvements/additions to vanilla
Emacs, though...

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

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09.04.2021 07:21, Eric Abrahamsen wrote:
>> As another data point, Gnus has `gnus-multiple-choice', yet another
>> approach to the problem.
>
> It's now in the core as read-multiple-choice.

Thanks! I didn't know that.

> Good option to have, though I haven't found many occasions to use it for.
>
> project-switch-project uses a similar menu, but its choices ended up
> being more complex than single chars.

My desire for "selection" over "completion" is confined almost
completely to situations with <10 or so completion items, so maybe a
menu is actually what I'm after... things to think about.

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

[Eli Zaretskii]

> Cc: philipk@posteo.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 10 Apr 2021 02:12:51 +0300
> 
> > I don't think I understand how xref-show-definitions-completing-read
> > is different from, say, read-file-name.  Can you explain?
> 
> We've touched on this previously in the poll/discussion about the default:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00029.html
> 
> The values which xref-show-definitions-completing-read asks you to 
> choose from are relatively complex, and hard to type out.
> 
> Further, there's often only 2-3 values to choose from (in the Elisp's 
> case, at least), so choosing the first one should be a frequent enough 
> occasion.
> 
> With a selection-based menu you look at all options and make a choice: 
> often just press RET; maybe press TAB, or C-n, or <down> a few times 
> before that.
> 
> With completing-read, you have to press TAB first, to see the choices, 
> and then type some of your choice's contents, keeping in mind perhaps 
> its distinguishing characteristics. That's simply more effort than the 
> other approach.
> 
> File name completion is different because you're not as likely to simply 
> choose the first option, there can be a *lot* of files in the dir, and 
> typing an average file name is much easier.
> 
> Mind you, I generally prefer completion UIs that show the options before 
> you start typing, but xref-show-definitions-completing-read makes a 
> really strong case for it. Which is unfortunate, because otherwise it's 
> my #1 choice for xref-show-definitions-function's default value, and 
> changing Emacs's completion UI is not in the cards in any near future.
> 
> So I would only be happy if you disagree with this assessment.

I think our interpretation of "completion vs selection" are different,
at least to some extent.  For me, completion is for when you (almost)
know what you want to type, and type enough of it to have a single TAB
more or less do the rest of the job.  IOW, it's a typing-saving tool.
Selection is for when you don't know what to type, and need the full
list to choose from.  IOW, it's a discovery tool.

With that in mind, completion for symbols in invoking M-. and
completion for file names in invoking some file-related command have
the same traits, at least for me.  Where selection is needed, we pop
up the XREF buffer at the end.  This default operation makes sense to
me.  By contrast, using xref-show-definitions-completing-read, I'm
asked to choose twice: first in a "normal" completion context, then
again in a strange way (it says "Choose" without showing me anything
to choose from, and I need to type TAB to see a *Completions* buffer).
I guess to each their own, but the latter method strikes me as weird
and inconvenient.  IMO, its place is in Company-style "completion"
when writing code -- there one would like to see the list of
pertinents alternatives to select from without typing anything, not
when the user invokes a command and needs help in typing as few
characters as possible.

Re: [ELPA] New package: vertico

[Tassilo Horn]

Hi Daniel,

>> Now I have two questions:
>> 1. Shouldn't there be a command like `th/vertico-complete' which
>>     completes the common part of the candidates?
>
> Vertico follows the design where you put less importance on the
> prefix/TAB completion but instead excepts the user to enter more text
> for narrowing, which works well with the orderless completion style.
>
> But note that Vertico is fully compatible with default completion, so
> as you observed you can just use `minibuffer-complete`.  If you bind
> `minibuffer-complete` to the `vertico-map` it will work.  See
> https://github.com/minad/vertico#keymap.
>
> Is that good enough or do you have something else in mind?

It's just almost good enough.  It completes correctly but the candidates
are not refreshed.  For example, with find-file, it might complete
uniquely to a directory but still display the siblings of that directory
rather than its contents.  That's why I've sneaked in a call to
`vertico--exhibit' in my `th/vertico--complete' command.

>> 2. One annoying effect with the above command and vertico is that the
>>     typical completion messages such as "Next char not unique" bump point
>>     to the right, i.e., with stock minibuffer completion you have
>>       my-input| [Next char not unique]
>>     whereas with vertico you have
>>       my-input [Next char not unique]|
>>     where | indicates point.  Why is that?
>
> Yes, I've also observed issues with minibuffer messages appearing at
> the wrong place. Vertico uses overlays to display the candidate count
> and the candidate list, similar to Icomplete. Icomplete however
> removes the overlay in the pre-command-hook and puts the overlay back
> in the post-command-hook. I am not doing that. I just move the overlay
> to the end but it seems this solution is not good enough. Since I have
> not yet understood fully what the problem is I haven't done anything
> yet to fix the issue.
>
> Besides, my recommendation would be to deactivate those messages. I
> think they are pretty annoying. I suspect even more so in combination
> with aggressive-completion.

Yes, `completion-auto-help' makes absolutely no sense with vertico (and
can be disabled with aggressive-completion using
`aggressive-completion-auto-completion-help').  Probably the same is
true for `completion-show-inline-help'.

Bye,
Tassilo

Re: [ELPA] New package: vertico

[Eli Zaretskii]

> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 10 Apr 2021 01:23:04 +0200
> Cc: emacs-devel@gnu.org
> 
> > 2. One annoying effect with the above command and vertico is that the
> >     typical completion messages such as "Next char not unique" bump point
> >     to the right, i.e., with stock minibuffer completion you have
> > 
> >       my-input| [Next char not unique]
> > 
> >     whereas with vertico you have
> > 
> >       my-input [Next char not unique]|
> > 
> >     where | indicates point.  Why is that?
> 
> Yes, I've also observed issues with minibuffer messages appearing at the 
> wrong place. Vertico uses overlays to display the candidate count and 
> the candidate list, similar to Icomplete. Icomplete however removes the 
> overlay in the pre-command-hook and puts the overlay back in the 
> post-command-hook. I am not doing that. I just move the overlay to the 
> end but it seems this solution is not good enough. Since I have not yet 
> understood fully what the problem is I haven't done anything yet to fix 
> the issue.

The solution is likely the 'cursor' property.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  philipk@posteo.net,  emacs-devel@gnu.org
> Date: Fri, 09 Apr 2021 19:48:25 -0400
> 
> I think it would be desirable to change the default UI just enough so
> that a code like Xref can make `completing-read` display the
> completions eagerly.

Right away, i.e. even without the user typing anything? that'd produce
a huge list of candidates, which would be impractical to display.

Or what do you mean by "eagerly"?

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

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, philipk@posteo.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 10 Apr 2021 04:56:52 +0300
> 
> Does anybody feel like it's an improvement enough to make 
> xref-show-definitions-completing-read a viable default?

Default for what?  If for M-., then I object: the result is a weird
paradigm unlike any other completion I ever saw in Emacs.

Re: [ELPA] New package: vertico

[Daniel Mendler]

On 4/10/21 9:18 AM, Eli Zaretskii wrote:
>> Yes, I've also observed issues with minibuffer messages appearing at the
>> wrong place. Vertico uses overlays to display the candidate count and
>> the candidate list, similar to Icomplete. Icomplete however removes the
>> overlay in the pre-command-hook and puts the overlay back in the
>> post-command-hook. I am not doing that. I just move the overlay to the
>> end but it seems this solution is not good enough. Since I have not yet
>> understood fully what the problem is I haven't done anything yet to fix
>> the issue.
> 
> The solution is likely the 'cursor' property.

I am already putting the 'cursor property on the first character of the 
candidates string. This string is shown with 'after-string in the 
overlay at the end of the minibuffer. Maybe I missed something else.

Re: [ELPA] New package: vertico

[Eli Zaretskii]

> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 10 Apr 2021 11:21:45 +0200
> 
> > The solution is likely the 'cursor' property.
> 
> I am already putting the 'cursor property on the first character of the 
> candidates string. This string is shown with 'after-string in the 
> overlay at the end of the minibuffer. Maybe I missed something else.

I'm talking about the "Next char not unique" message, not about the
candidate strings.  That is what Tassilo complained about, right?

Re: [ELPA] New package: vertico

[Daniel Mendler]

On 4/10/21 9:17 AM, Tassilo Horn wrote:
>> But note that Vertico is fully compatible with default completion, so
>> as you observed you can just use `minibuffer-complete`.  If you bind
>> `minibuffer-complete` to the `vertico-map` it will work.  See
>> https://github.com/minad/vertico#keymap.
>>
>> Is that good enough or do you have something else in mind?
> 
> It's just almost good enough.  It completes correctly but the candidates
> are not refreshed.  For example, with find-file, it might complete
> uniquely to a directory but still display the siblings of that directory
> rather than its contents.  That's why I've sneaked in a call to
> `vertico--exhibit' in my `th/vertico--complete' command.

If you bind `minibuffer-complete` to a keybinding in `vertico-map` it 
will automatically update the UI via the `post-command-hook`, which 
calls `vertico--exhibit`.

I have checked your aggressive-completion package and there you are 
using a timer. I wonder why you are doing that (Performance issues?). 
Wouldn't it be better to use an `after-change-function` or a 
`post-command-hook`? If you use a `post-command-hook`, it will work 
automatically with Vertico as long as your `post-command-hook` which 
aggressively calls `minibuffer-complete` runs before my 
`vertico--exhibit` hook.

If you continue to use a timer, you necessarily have to inform the 
Vertico UI that something has changed. As I said, Vertico only updates 
itself via the `post-command-hook` and does not detect other changes. So 
as things stand, there is no other way than calling `vertico--exhibit` 
manually. With Icomplete the situation should be the same, see 
`icomplete-exhibit`. If your package works well with Icomplete it should 
also work well with Vertico and vice versa.

Daniel Mendler

Re: [ELPA] New package: vertico

[Daniel Mendler]

On 4/10/21 11:30 AM, Eli Zaretskii wrote:
>> I am already putting the 'cursor property on the first character of the
>> candidates string. This string is shown with 'after-string in the
>> overlay at the end of the minibuffer. Maybe I missed something else.
> 
> I'm talking about the "Next char not unique" message, not about the
> candidate strings.  That is what Tassilo complained about, right?

Okay, thanks for clarifying. In Vertico I try hard to avoid modifying 
existing functions. I am sure this issue could be fixed by adjusting the 
`minibuffer-message` function with an advice such that it adds a cursor 
property. Note that Icomplete also does not make these adjustments, so 
maybe there is something else.

I think both Tassilo and I agreed that in the context we are discussing 
(vertico+aggressive-completion), the messages are less important and can 
be happily disabled, making this a non-issue/low-priority issue.

Daniel Mendler

Re: [ELPA] New package: vertico

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > The solution is likely the 'cursor' property.
>> 
>> I am already putting the 'cursor property on the first character of
>> the candidates string. This string is shown with 'after-string in the
>> overlay at the end of the minibuffer. Maybe I missed something else.
>
> I'm talking about the "Next char not unique" message, not about the
> candidate strings.  That is what Tassilo complained about, right?

Yes, right.  So are you saying that the inline help messages itself
should have a non-nil 'cursor property at the first character, i.e., on
the N in "Next char not unique"?

Bye,
Tassilo

Re: [ELPA] New package: vertico

[Tassilo Horn]

Daniel Mendler <mail@daniel-mendler.de> writes:

>> It's just almost good enough.  It completes correctly but the
>> candidates are not refreshed.  For example, with find-file, it might
>> complete uniquely to a directory but still display the siblings of
>> that directory rather than its contents.  That's why I've sneaked in
>> a call to `vertico--exhibit' in my `th/vertico--complete' command.
>
> If you bind `minibuffer-complete` to a keybinding in `vertico-map` it
> will automatically update the UI via the `post-command-hook`, which
> calls `vertico--exhibit`.
>
> I have checked your aggressive-completion package and there you are
> using a timer. I wonder why you are doing that (Performance
> issues?).

Because otherwise you wouldn't be able to type more than one character
or correct a mistyped char before aggressive completion would kick in.

Bye,
Tassilo

Re: [ELPA] New package: vertico

[Eli Zaretskii]

> Cc: Tassilo Horn <tsdh@gnu.org>, emacs-devel@gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 10 Apr 2021 11:38:52 +0200
> 
> > I'm talking about the "Next char not unique" message, not about the
> > candidate strings.  That is what Tassilo complained about, right?
> 
> Okay, thanks for clarifying. In Vertico I try hard to avoid modifying 
> existing functions. I am sure this issue could be fixed by adjusting the 
> `minibuffer-message` function with an advice such that it adds a cursor 
> property. Note that Icomplete also does not make these adjustments, so 
> maybe there is something else.

minibuffer-message already does what I described, so I wonder why this
doesn't work in your case.  I suggest to step through the code and
compare with the default use in "emacs -Q".  If you cannot figure it
out, submit a bug report with a reproduction recipe in "emacs -Q", and
someone will look into it.

> I think both Tassilo and I agreed that in the context we are discussing 
> (vertico+aggressive-completion), the messages are less important and can 
> be happily disabled, making this a non-issue/low-priority issue.

It's up to you; I just wanted to try helping where I can.

Re: [ELPA] New package: vertico

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Daniel Mendler <mail@daniel-mendler.de>, emacs-devel@gnu.org
> Date: Sat, 10 Apr 2021 11:38:57 +0200
> 
> > I'm talking about the "Next char not unique" message, not about the
> > candidate strings.  That is what Tassilo complained about, right?
> 
> Yes, right.  So are you saying that the inline help messages itself
> should have a non-nil 'cursor property at the first character, i.e., on
> the N in "Next char not unique"?

Yes.  But since the code uses minibuffer-message, and that function
already puts the 'cursor' property on the first character of the
message string, I wonder why this doesn't "just work".

Re: [ELPA] New package: vertico

[Daniel Mendler]

On 4/10/21 11:44 AM, Tassilo Horn wrote:
> Because otherwise you wouldn't be able to type more than one character
> or correct a mistyped char before aggressive completion would kick in.

Thanks, makes sense! The behavior I described would be overly aggressive 
and would fit better into an annoying-completion package, which goes 
together with the annoying-correction package, commonly found on phones.

I wonder if it would be possible to to show the `minibuffer-complete` 
result as some kind of grayed out overlay as found in other UIs, such 
that one knows when pressing TAB is advised.

I hope the solution you have then for aggressive-completion+vertico is 
satisfactory. If you have other issues or feedback regarding Vertico, 
please let me know.

Daniel Mendler

Re: [ELPA] New package: vertico

[Daniel Mendler]

On 4/10/21 12:00 PM, Eli Zaretskii wrote:
>> Okay, thanks for clarifying. In Vertico I try hard to avoid modifying
>> existing functions. I am sure this issue could be fixed by adjusting the
>> `minibuffer-message` function with an advice such that it adds a cursor
>> property. Note that Icomplete also does not make these adjustments, so
>> maybe there is something else.
> 
> minibuffer-message already does what I described, so I wonder why this
> doesn't work in your case.  I suggest to step through the code and
> compare with the default use in "emacs -Q".  If you cannot figure it
> out, submit a bug report with a reproduction recipe in "emacs -Q", and
> someone will look into it.

Ah okay, I see. Then it makes sense to investigate this more thoroughly.

>> I think both Tassilo and I agreed that in the context we are discussing
>> (vertico+aggressive-completion), the messages are less important and can
>> be happily disabled, making this a non-issue/low-priority issue.
> 
> It's up to you; I just wanted to try helping where I can.

Sure, I appreciate it. Thank you!

I don't know if Icomplete has similar problems with the 
minibuffer-messages, so maybe it has already been figured out there. 
Icomplete uses a single overlay for all minibuffers, which does not seem 
like a good idea given recursive minibuffers (In Vertico I try to 
isolate the state of every minibuffer session). But there is something 
else I wonder about - Icomplete installs a pre-command-hook, which 
removes the overlay and a post-command-hook which puts it back.

Daniel Mendler

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

[Dmitry Gutov]

On 10.04.2021 10:20, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  philipk@posteo.net,  emacs-devel@gnu.org
>> Date: Fri, 09 Apr 2021 19:48:25 -0400
>>
>> I think it would be desirable to change the default UI just enough so
>> that a code like Xref can make `completing-read` display the
>> completions eagerly.
> 
> Right away, i.e. even without the user typing anything? that'd produce
> a huge list of candidates, which would be impractical to display.

I guess it depends on the usage/language/project, whether the list is 
"huge" often enough, or not.

But *Completions* can display large lists, it will just get cut off.

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

[Dmitry Gutov]

On 10.04.2021 10:27, Eli Zaretskii wrote:
>> Does anybody feel like it's an improvement enough to make
>> xref-show-definitions-completing-read a viable default?
> Default for what?  If for M-., then I object: the result is a weird
> paradigm unlike any other completion I ever saw in Emacs.

By "paradigm", do you mean the way how those completions look?

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  philipk@posteo.net,  emacs-devel@gnu.org
>> Date: Fri, 09 Apr 2021 19:48:25 -0400
>>
>> I think it would be desirable to change the default UI just enough so
>> that a code like Xref can make `completing-read` display the
>> completions eagerly.
>
> Right away, i.e. even without the user typing anything? that'd produce
> a huge list of candidates, which would be impractical to display.

This is what e.g. ivy does on M-x, and it works well in practice.

I find it much better to display candidates this way, and I think it
would be a step forward if Emacs dit this itself OOTB.

(It's also a popular choice elsewhere, try for example entering
something into the search bar on Google or DuckDuckGo.  The same
paradigm you see there is used in a lot of desktop software.)

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

[Eli Zaretskii]

> Cc: philipk@posteo.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 10 Apr 2021 13:52:58 +0300
> 
> >> I think it would be desirable to change the default UI just enough so
> >> that a code like Xref can make `completing-read` display the
> >> completions eagerly.
> > 
> > Right away, i.e. even without the user typing anything? that'd produce
> > a huge list of candidates, which would be impractical to display.
> 
> I guess it depends on the usage/language/project, whether the list is 
> "huge" often enough, or not.

Maybe I've lost the context here, but if we are talking about the list
of candidates after just "C-u M-.", it's bound to be huge for any
non-trivial project.

> But *Completions* can display large lists, it will just get cut off.

The completions buffer can display any length of candidates, sure.
But too long lists are generally an annoyance, cf. the "C-x 8 RET"
case.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, philipk@posteo.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 10 Apr 2021 13:53:47 +0300
> 
> On 10.04.2021 10:27, Eli Zaretskii wrote:
> >> Does anybody feel like it's an improvement enough to make
> >> xref-show-definitions-completing-read a viable default?
> > Default for what?  If for M-., then I object: the result is a weird
> > paradigm unlike any other completion I ever saw in Emacs.
> 
> By "paradigm", do you mean the way how those completions look?

No, I mean the use paradigm: it's from my POV "backwards".

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

[Gregory Heytings]

>
> I think it would be desirable to change the default UI just enough so 
> that a code like Xref can make `completing-read` display the completions 
> eagerly.
>

I did not follow all the details of the earlier discussion, and I'm not 
sure I understand what you mean, but is this not already possible?  IIUC 
Icomplete for example does this when icomplete-show-matches-on-no-input is 
non-nil, and RET selects the first entry.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 10 Apr 2021 05:56:39 -0500
> Cc: philipk@posteo.net, emacs-devel@gnu.org, dgutov@yandex.ru
> 
> > Right away, i.e. even without the user typing anything? that'd produce
> > a huge list of candidates, which would be impractical to display.
> 
> This is what e.g. ivy does on M-x, and it works well in practice.
> 
> I find it much better to display candidates this way, and I think it
> would be a step forward if Emacs dit this itself OOTB.

For me, it would be a step back.  I never use completion for
discovery, I always have a pretty good idea what I'm about to type
when I do.

> (It's also a popular choice elsewhere, try for example entering
> something into the search bar on Google or DuckDuckGo.  The same
> paradigm you see there is used in a lot of desktop software.)

Those are for selection, not for completion.  I thought we'd already
established that the two are quite different.  We should not conflate
them, nor force users use only one of them where both could make
sense, IMO.

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

[Dmitry Gutov]

On 10.04.2021 14:08, Eli Zaretskii wrote:
>> Cc: philipk@posteo.net, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 10 Apr 2021 13:52:58 +0300
>>
>>>> I think it would be desirable to change the default UI just enough so
>>>> that a code like Xref can make `completing-read` display the
>>>> completions eagerly.
>>>
>>> Right away, i.e. even without the user typing anything? that'd produce
>>> a huge list of candidates, which would be impractical to display.
>>
>> I guess it depends on the usage/language/project, whether the list is
>> "huge" often enough, or not.
> 
> Maybe I've lost the context here, but if we are talking about the list
> of candidates after just "C-u M-.", it's bound to be huge for any
> non-trivial project.

No, no.

We're talking about the second completion prompt, when you have picked 
an identifier to navigate to, but there are multiple matching locations 
to jump to.

Right now you see an *xref* buffer in such situation, but 
xref-show-definitions-completing-read uses completing-read (a second 
time) instead.

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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, philipk@posteo.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 10 Apr 2021 15:43:16 +0300
> 
> We're talking about the second completion prompt, when you have picked 
> an identifier to navigate to, but there are multiple matching locations 
> to jump to.
> 
> Right now you see an *xref* buffer in such situation, but 
> xref-show-definitions-completing-read uses completing-read (a second 
> time) instead.

That could also be a large list, e.g. if I typed the name of a large
class.

What is worse, the completion candidates are displayed in a format
very different from the one I saw before typing RET.  It's almost as
if the completion method was switched under my feet.  Very confusing.

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

[Dmitry Gutov]

On 10.04.2021 07:04, Stefan Monnier wrote:
>>> I think it would be desirable to change the default UI just enough so
>>> that a code like Xref can make `completing-read` display the
>>> completions eagerly.
>> The *Completions* window, you mean?
> 
> I was thinking of a somewhat generic way to tell the UI that the list
> should be shown eagerly.  Presumably the default UI would react to it by
> displaying the *Completions* window, yes.

This basically sounds like icomplete or Ivy, and might get the same 
pushback as the suggestion to use one of them by default.

In any case, I'd be happy to see experiments in that direction.

>> It would still miss the ability to quickly accept one of them
>> with RET.
> 
> Right, but the cycle-threshold helps with that, no?

At the moment, IIUC, the UI either lets you cycle, or shows the 
*Completions* buffer, but not both at the same time.

Perhaps you're suggesting to remove that limitation (what would happen 
if I dismiss *Completions* and then press TAB again?).

Maybe the optimal UI which is close enough to the default behavior would 
look more like icomplete-vertical: the items closer to the prompt, and 
there is a visible selection which you can accept with RET.

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

[Stefan Monnier]

>> I think it would be desirable to change the default UI just enough so
>> that a code like Xref can make `completing-read` display the
>> completions eagerly.
> Right away, i.e. even without the user typing anything?

Yes.

> that'd produce a huge list of candidates, which would be impractical
> to display.

The assumption here is that Xref's completion list is small.


        Stefan

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

[Stefan Monnier]

>> I think it would be desirable to change the default UI just enough so that
>> a code like Xref can make `completing-read` display the
>> completions eagerly.
> I did not follow all the details of the earlier discussion, and I'm not sure
> I understand what you mean, but is this not already possible?
> IIUC Icomplete for example does this when icomplete-show-matches-on-no-input
> is non-nil, and RET selects the first entry.

Icomplete is a completion UI, so of course it can do what it wishes.
The question is how can Xref tell the completion UI (whichever the user
has chosen to use) that it's a good idea to do it.


        Stefan

Re: [ELPA] New package: vertico

[Stefan Monnier]

> If you bind `minibuffer-complete` to a keybinding in `vertico-map` it will
> automatically update the UI via the `post-command-hook`, which calls
> `vertico--exhibit`.
>
> I have checked your aggressive-completion package and there you are using
> a timer. I wonder why you are doing that (Performance issues?). Wouldn't it
> be better to use an `after-change-function` or a `post-command-hook`? If you

Maybe a way to handle it "right" is for vertico to register an
`after-change-function` so as to detect also when the buffer's content is
modified outside of the normal commands (i.e. from a timer or process
filter).  It'd probably be a bit messy, tho: it wouldn't want to refresh
the completion list right away, but there's no "obvious" later hook to
use (like `post-command-hook`) so it would need to detect when there's
not going to be a subsequent post-command-hook (i.e. when we're in
a timer or similar) and then probably fire its own timer to update the
completion list when the current processing is done.

Or maybe it should use `after-change-function` to detect changes and
`pre-redisplay-functions` to update the list of completion.


        Stefan

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

[Gregory Heytings]

>>> I think it would be desirable to change the default UI just enough so 
>>> that a code like Xref can make `completing-read` display the 
>>> completions eagerly.
>>
>> I did not follow all the details of the earlier discussion, and I'm not 
>> sure I understand what you mean, but is this not already possible? IIUC 
>> Icomplete for example does this when icomplete-show-matches-on-no-input 
>> is non-nil, and RET selects the first entry.
>
> Icomplete is a completion UI, so of course it can do what it wishes. The 
> question is how can Xref tell the completion UI (whichever the user has 
> chosen to use) that it's a good idea to do it.
>

IIUC, a variable "completing-read-show-matches-on-no-input" that would be 
setq-local'd by Xref and read by completion UI's would do the job.  Or am 
I missing something?

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 10 Apr 2021 09:13:09 -0400
> Cc: philipk@posteo.net, emacs-devel@gnu.org, dgutov@yandex.ru
> 
> > that'd produce a huge list of candidates, which would be impractical
> > to display.
> 
> The assumption here is that Xref's completion list is small.

And if it isn't?

Re: [ELPA] New package: vertico

[Daniel Mendler]

On 4/10/21 3:34 PM, Stefan Monnier wrote:
> Maybe a way to handle it "right" is for vertico to register an
> `after-change-function` so as to detect also when the buffer's content is
> modified outside of the normal commands (i.e. from a timer or process
> filter).  It'd probably be a bit messy, tho: it wouldn't want to refresh
> the completion list right away, but there's no "obvious" later hook to
> use (like `post-command-hook`) so it would need to detect when there's
> not going to be a subsequent post-command-hook (i.e. when we're in
> a timer or similar) and then probably fire its own timer to update the
> completion list when the current processing is done.
> 
> Or maybe it should use `after-change-function` to detect changes and
> `pre-redisplay-functions` to update the list of completion.

Yes, there are other hooks that could be used. I like to keep it simple 
as is and introduce nothing messy. I follow the design taken by 
Icomplete which works well.

Daniel

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

[Drew Adams]

> > Right away, i.e. even without the user typing anything? that'd produce
> > a huge list of candidates, which would be impractical to display.
> 
> This is what e.g. ivy does on M-x, and it works well in practice.
> 
> I find it much better to display candidates this way, and I think it
> would be a step forward if Emacs dit this itself OOTB.
> 
> (It's also a popular choice elsewhere, try for example entering
> something into the search bar on Google or DuckDuckGo.  The same
> paradigm you see there is used in a lot of desktop software.)

(AFAIK, Ido also immediately shows completions, FWIW,
and it always has.) 

However, IMO it makes no sense to either do this or
not do it _systematically_.

Different users, different contexts, different commands,
and so on, can call for different such behaviors.  One
size just does not fit all.

Icicles has had both (automatic and on-demand) behaviors
since 2006, changeable at any time during completion.

And there are other such behaviors, such as showing
candidates not initially but only when you start typing
input (after a settable delay, if more than a settable
number of candidates), but not before that (and not if
there's only one candidate).

The same one-size-does-not-fit-all and
give-the-user-control guideline applies to many other
UI things, such as whether, when there's only one
matching candidate, it should automatically be chosen
and the minibuffer exited.  There are a bunch of such
things.

They should, in general, be handled by user options.
And in many/most cases there should also be the
ability to toggle them during completion (or cycle
them, if more than 2 possibilities).

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

[Dmitry Gutov]

On 10.04.2021 16:10, Eli Zaretskii wrote:
>> Cc: monnier@iro.umontreal.ca, philipk@posteo.net, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 10 Apr 2021 15:43:16 +0300
>>
>> We're talking about the second completion prompt, when you have picked
>> an identifier to navigate to, but there are multiple matching locations
>> to jump to.
>>
>> Right now you see an *xref* buffer in such situation, but
>> xref-show-definitions-completing-read uses completing-read (a second
>> time) instead.
> 
> That could also be a large list, e.g. if I typed the name of a large
> class.

True. It's not so critical an issue (the list will be truncated), you 
just won't get the most benefit from the streamlined workflow in this case.

> What is worse, the completion candidates are displayed in a format
> very different from the one I saw before typing RET.  It's almost as
> if the completion method was switched under my feet.  Very confusing.

Perhaps if the completion method (text-expansion vs selection) was also 
switched, as is the case in my Emacs, it will be much less confusing.

And the latter method showed all options right away.

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

[Dmitry Gutov]

On 10.04.2021 10:09, Eli Zaretskii wrote:

> I think our interpretation of "completion vs selection" are different,
> at least to some extent.  For me, completion is for when you (almost)
> know what you want to type, and type enough of it to have a single TAB
> more or less do the rest of the job.  IOW, it's a typing-saving tool.
> Selection is for when you don't know what to type, and need the full
> list to choose from.  IOW, it's a discovery tool.

I don't think we disagree too much, it's just there are cases where 
"completion" (as defined by you) is really inconvenient: you both don't 
know what you want to type, and the options are hard to type as well.

But there are also cases (IME) when you don't necessarily know what to 
type, but you want to continue typing. That is the scenario of an 
average (or, perhaps, a beginner) Java developer typing in a IDE: when 
you don't remember the method name, you try to guess by typing a 
relevant word, see what names match, and often enough get it right.

> With that in mind, completion for symbols in invoking M-. and
> completion for file names in invoking some file-related command have
> the same traits, at least for me.

I don't always know what file name I want to type either, and either 
guess by typing a part of the word and pressing TAB. Or type multiple 
relevant words at once, if the completion UI allows it (that's very 
helpful for choosing a project-relative file name in project-find-file).

> Where selection is needed, we pop
> up the XREF buffer at the end.  This default operation makes sense to
> me.

The problem with it is the user can end up in two different states: 
either having jumped to the target location (if there is just one), or 
having a list of all matching locations displayed. And then do extra 
work to get where they wanted to go.

Whereas we want (I think) the process to always end up at the location 
which the user intended to get to.

> By contrast, using xref-show-definitions-completing-read, I'm
> asked to choose twice: first in a "normal" completion context, then
> again in a strange way (it says "Choose" without showing me anything
> to choose from, and I need to type TAB to see a *Completions* buffer).
                       ^
                       this is the most puzzling aspect of it indeed,
                       as we've mentioned here.

> I guess to each their own, but the latter method strikes me as weird
> and inconvenient.

What I'm saying is the process is handicapped by the limitations of the 
default completion UI.

With Ivy (which I use only for 3 commands), the process becomes much 
more obvious and faster. Wish you could try it.

And it's not something I invented: a user contributed the first version 
of xref-show-definitions-completing-read, which we then tweaked for 
efficiency, and it turned out to result in a very sensible workflow. Not 
with the default completing-read, though.

> IMO, its place is in Company-style "completion"
> when writing code -- there one would like to see the list of
> pertinents alternatives to select from without typing anything, not
> when the user invokes a command and needs help in typing as few
> characters as possible.

Not 100% sure I understand, but if you meant the second step could use 
Company-style completion (which can also work as selection-type UI), 
then we're in agreement.

But Company is just as useful in "needs help in typing as few characters 
as possible" kind of scenarios.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> 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.

I attached a primitive version of selecting-read to this message. The UI
is horridly primitive, but the basic idea should be understandable.

Using generic functions, methods can be defined determining how an
object is handled. In this iteration, three generic functions are used:

- (selecting-read-represent object)

  Return a string representing the object. This is the only necessary
  method.

- (selecting-read-properties object)

  Return a plist denoting properties of the object

- (selecting-read-children object)

  Return a list of children of this object

It seems that these three functions are enough, and that adding more
would risk becoming too complicated.

When evaluating a nonsensical query like

        (selecting-read '((node "one" "one.1" "one.2" "one.3")
                          (node ("two" :property "propertied" :key "value")
                                "two.1" "two.2")
                          "three"))

a child window appears and the user can select an object, that
selecting-read returns directly (eq).

Additional arguments are passed as keywords. A simple example is
:multiple that lets selecting-read give me a list of items that were
marked

        (selecting-read '((node "one" "one.1\n" "one.2" "one.3")
                          (node ("two" :property "propertied" :key "value")
                                "two.1" "two.2")
                          "three")
                        :multiple t)

Because I'm not just now primarily concerned with what completing-read
might look like, it doesn't do "automatic narrowing" like Helm or
Ivy. The framework I sketched here should be flexible enough to support
something like that, if preferred.

-- 
	Philip K.


[-- Attachment #2: selecting-read.el --]
[-- Type: application/emacs-lisp, Size: 6753 bytes --]

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

[Eli Zaretskii]

> Cc: philipk@posteo.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 10 Apr 2021 17:40:05 +0300
> 
> On 10.04.2021 10:09, Eli Zaretskii wrote:
> 
> > I think our interpretation of "completion vs selection" are different,
> > at least to some extent.  For me, completion is for when you (almost)
> > know what you want to type, and type enough of it to have a single TAB
> > more or less do the rest of the job.  IOW, it's a typing-saving tool.
> > Selection is for when you don't know what to type, and need the full
> > list to choose from.  IOW, it's a discovery tool.
> 
> I don't think we disagree too much, it's just there are cases where 
> "completion" (as defined by you) is really inconvenient: you both don't 
> know what you want to type, and the options are hard to type as well.
> 
> But there are also cases (IME) when you don't necessarily know what to 
> type, but you want to continue typing. That is the scenario of an 
> average (or, perhaps, a beginner) Java developer typing in a IDE: when 
> you don't remember the method name, you try to guess by typing a 
> relevant word, see what names match, and often enough get it right.

I agree that similar features are used for both purposes.  But they
are still different purposes, and the discussion will become
inefficient (and for me lose its purpose) if we try to ignore that
difference or blur it.

> > With that in mind, completion for symbols in invoking M-. and
> > completion for file names in invoking some file-related command have
> > the same traits, at least for me.
> 
> I don't always know what file name I want to type either, and either 
> guess by typing a part of the word and pressing TAB. Or type multiple 
> relevant words at once, if the completion UI allows it (that's very 
> helpful for choosing a project-relative file name in project-find-file).

Never happens to me, and probably never will.  If I don't know what to
type, I first find out (by "other means").

> But Company is just as useful in "needs help in typing as few characters 
> as possible" kind of scenarios.

But its goal is still different, and doesn't make much sense in my
completion use cases.  In fact, whenever I need to use programs that
only provide the "selection" type, I frequently am annoyed and many
times need to repeatedly type the same input until I get it right.

Re: [ELPA] New package: vertico

[Stefan Monnier]

>> Maybe a way to handle it "right" is for vertico to register an
>> `after-change-function` so as to detect also when the buffer's content is
>> modified outside of the normal commands (i.e. from a timer or process
>> filter).  It'd probably be a bit messy, tho: it wouldn't want to refresh
>> the completion list right away, but there's no "obvious" later hook to
>> use (like `post-command-hook`) so it would need to detect when there's
>> not going to be a subsequent post-command-hook (i.e. when we're in
>> a timer or similar) and then probably fire its own timer to update the
>> completion list when the current processing is done.
>> Or maybe it should use `after-change-function` to detect changes and
>> `pre-redisplay-functions` to update the list of completion.
>
> Yes, there are other hooks that could be used. I like to keep it simple as
> is and introduce nothing messy. I follow the design taken by Icomplete which
> works well.

FWIW, I'm not convinced either that the extra complexity of what
I propose is worth the trouble.


        Stefan

Re: [ELPA] New package: vertico

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Maybe a way to handle it "right" is for vertico to register an
>>> `after-change-function` so as to detect also when the buffer's
>>> content is modified outside of the normal commands (i.e. from a
>>> timer or process filter).  It'd probably be a bit messy, tho: it
>>> wouldn't want to refresh the completion list right away, but there's
>>> no "obvious" later hook to use (like `post-command-hook`) so it
>>> would need to detect when there's not going to be a subsequent
>>> post-command-hook (i.e. when we're in a timer or similar) and then
>>> probably fire its own timer to update the completion list when the
>>> current processing is done.  Or maybe it should use
>>> `after-change-function` to detect changes and
>>> `pre-redisplay-functions` to update the list of completion.
>>
>> Yes, there are other hooks that could be used. I like to keep it
>> simple as is and introduce nothing messy. I follow the design taken
>> by Icomplete which works well.
>
> FWIW, I'm not convinced either that the extra complexity of what
> I propose is worth the trouble.

FWIW, it's absolutely no big deal for me to call `vertico--exhibit'
after `minibuffer-complete' and it also doesn't seem to be costly as the
former already checks if the input changed before re-computing
completions. :-)

Bye,
Tassilo

Re: [ELPA] New package: vertico

[Juri Linkov]

>> Or maybe it should use `after-change-function` to detect changes and
>> `pre-redisplay-functions` to update the list of completion.
>
> Yes, there are other hooks that could be used. I like to keep it simple as
> is and introduce nothing messy. I follow the design taken by Icomplete
> which works well.

I wonder how easy would be to improve Icomplete to display completions
in the standard buffer *Completions* instead of the minibuffer?
Then both use cases will be covered:

1. icomplete-vertical-mode for users who prefer vertical completions
   in the minibuffer;

2. vertical completions in *Completions* for users who don't like
   when the mode-line jumps up and down when completing.
   In this case the same icomplete keys could be used to navigate
   completions in the *Completions* buffer from the minibuffer
   with icomplete-forward-completions and icomplete-backward-completions,
   and icomplete-force-complete-and-exit to accept the selected completion.

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

[Dmitry Gutov]

On 10.04.2021 18:02, Eli Zaretskii wrote:
>> I don't think we disagree too much, it's just there are cases where
>> "completion" (as defined by you) is really inconvenient: you both don't
>> know what you want to type, and the options are hard to type as well.
>>
>> But there are also cases (IME) when you don't necessarily know what to
>> type, but you want to continue typing. That is the scenario of an
>> average (or, perhaps, a beginner) Java developer typing in a IDE: when
>> you don't remember the method name, you try to guess by typing a
>> relevant word, see what names match, and often enough get it right.
> 
> I agree that similar features are used for both purposes.  But they
> are still different purposes, and the discussion will become
> inefficient (and for me lose its purpose) if we try to ignore that
> difference or blur it.

I was saying that there are different ways to decide which UI a 
situation calls for, and most of the popular UIs are hybrid anyway.

So there's a lot of grey area.

But there are situations that really call for "selection" like 
interface, and Emacs doesn't have any comparably good ones in the 
default config, that universal code could really rely on.

>>> With that in mind, completion for symbols in invoking M-. and
>>> completion for file names in invoking some file-related command have
>>> the same traits, at least for me.
>>
>> I don't always know what file name I want to type either, and either
>> guess by typing a part of the word and pressing TAB. Or type multiple
>> relevant words at once, if the completion UI allows it (that's very
>> helpful for choosing a project-relative file name in project-find-file).
> 
> Never happens to me, and probably never will.  If I don't know what to
> type, I first find out (by "other means").

Let me expand on one of the previous examples. There is this command, 
project-find-file, which expects you to choose among a number 
(thousands?) of long-ish file names relative to the project root.

Do you also always precisely know the file name you want to visit in 
advance? And so never really make use of the discoverability side-effect 
of the completion buffer?

>> But Company is just as useful in "needs help in typing as few characters
>> as possible" kind of scenarios.
> 
> But its goal is still different, and doesn't make much sense in my
> completion use cases.  In fact, whenever I need to use programs that
> only provide the "selection" type, I frequently am annoyed and many
> times need to repeatedly type the same input until I get it right.

I would hope that "Emacs with company-mode enabled" is not among such 
programs.

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

[Dmitry Gutov]

On 10.04.2021 17:40, Philip Kaludercic wrote:
>> 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.
> I attached a primitive version of selecting-read to this message. The UI
> is horridly primitive, but the basic idea should be understandable.

Hi Philip,

I've tried this new code, and it seems to work: the function pops a 
buffer which responds to RET, which in turn returns the appropriate item 
to the caller.

I'm not sure how to discuss or critique it. Some thoughts:

- It uses data structures quite different from what completing-read 
uses. That's pretty inconvenient, and requires a mental switch. I'd 
rather the two functions (or some future versions of them) were more 
similar in shape, yet (obviously) different in behavior.

- It's not pretty/comfortable to use (yet?). A lot of discussion and 
decisions might come from trying reaching the state where people like it.

Speaking of what I see in selecting-read-mode-map, in particular

   (define-key map (kbd "/")		#'selecting-read-narrow)

, it invokes the image of a more ponderous, explicit interaction than 
the snappy selection UIs I've used and liked in the past.

 > Because I'm not just now primarily concerned with what completing-read
might look like, it doesn't do "automatic narrowing" like Helm or
Ivy.

It doesn't do quick cycling with TAB either, though.

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

[Eli Zaretskii]

> Cc: philipk@posteo.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 11 Apr 2021 03:04:09 +0300
> 
> >> I don't always know what file name I want to type either, and either
> >> guess by typing a part of the word and pressing TAB. Or type multiple
> >> relevant words at once, if the completion UI allows it (that's very
> >> helpful for choosing a project-relative file name in project-find-file).
> > 
> > Never happens to me, and probably never will.  If I don't know what to
> > type, I first find out (by "other means").
> 
> Let me expand on one of the previous examples. There is this command, 
> project-find-file, which expects you to choose among a number 
> (thousands?) of long-ish file names relative to the project root.
> 
> Do you also always precisely know the file name you want to visit in 
> advance?

Yes, pretty much.  Although I must qualify that: I don't (yet) use
project.el features except for testing.

> And so never really make use of the discoverability side-effect of
> the completion buffer?

Never.  As I said: for me, completion is not a discoverability tool,
it's a type-saving tool.  I use other features for discovering stuff.

> >> But Company is just as useful in "needs help in typing as few characters
> >> as possible" kind of scenarios.
> > 
> > But its goal is still different, and doesn't make much sense in my
> > completion use cases.  In fact, whenever I need to use programs that
> > only provide the "selection" type, I frequently am annoyed and many
> > times need to repeatedly type the same input until I get it right.
> 
> I would hope that "Emacs with company-mode enabled" is not among such 
> programs.

Emacs cannot be one such program, because it doesn't provide _only_
the selection type: there's always the usual completion.

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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> - It uses data structures quite different from what completing-read
>   uses. That's pretty inconvenient, and requires a mental switch. I'd 
> rather the two functions (or some future versions of them) were more
> similar in shape, yet (obviously) different in behavior.

I think it would be possible to also support alists, hash tables,
vectors but I'm not sure if it is necessary. Functions might be
interesting to consider.

But this raises a more general question, of whether selecting-read and
completing-read should be drop-in replacements of one another. I would
hesitate, as completing-read isn't the cleanest interface. Instead it
might be cleaner to also provide a compatibility function with the same
interface as completing-read to translate into selecting-read.

> - It's not pretty/comfortable to use (yet?). A lot of discussion and
>   decisions might come from trying reaching the state where people
>  like it.
>
> Speaking of what I see in selecting-read-mode-map, in particular
>
>   (define-key map (kbd "/")		#'selecting-read-narrow)
>
> , it invokes the image of a more ponderous, explicit interaction than
> the snappy selection UIs I've used and liked in the past.

Of course, this was the product of maybe 1-2 hours of programming. I
don't have much experience with designing Emacs UIs, so I didn't get
much done. Ideally the UI should either be configurable or multiple UIs
should be provided to please every taste.

>> Because I'm not just now primarily concerned with what completing-read
> might look like, it doesn't do "automatic narrowing" like Helm or
> Ivy.
>
> It doesn't do quick cycling with TAB either, though.

Yes, I'd like to have that too, but I first wanted to get some comments
on the internal architecture, before I spend more time with the UI.

-- 
	Philip K.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Right away, i.e. even without the user typing anything? that'd produce
>> > a huge list of candidates, which would be impractical to display.
>> This is what e.g. ivy does on M-x, and it works well in practice.
>>
>> I find it much better to display candidates this way, and I think it
>> would be a step forward if Emacs dit this itself OOTB.
>
> For me, it would be a step back.  I never use completion for
> discovery, I always have a pretty good idea what I'm about to type
> when I do.

The fact that this UI paradigm is so ubiquitous suggests that you might
be in the minority here.

>> (It's also a popular choice elsewhere, try for example entering
>> something into the search bar on Google or DuckDuckGo.  The same
>> paradigm you see there is used in a lot of desktop software.)
>
> Those are for selection, not for completion.  I thought we'd already
> established that the two are quite different.  We should not conflate
> them, nor force users use only one of them where both could make
> sense, IMO.

I don't think the distinction matters here.  We are discussing if
candidates should be shown eagerly, and my answer is "yes".

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

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> > Right away, i.e. even without the user typing anything? that'd produce
>>> > a huge list of candidates, which would be impractical to display.
>>> This is what e.g. ivy does on M-x, and it works well in practice.
>>>
>>> I find it much better to display candidates this way, and I think it
>>> would be a step forward if Emacs dit this itself OOTB.
>>
>> For me, it would be a step back.  I never use completion for
>> discovery, I always have a pretty good idea what I'm about to type
>> when I do.
>
> The fact that this UI paradigm is so ubiquitous suggests that you might
> be in the minority here.

I don't think that that should delegitimize the preference though. 

>>> (It's also a popular choice elsewhere, try for example entering
>>> something into the search bar on Google or DuckDuckGo.  The same
>>> paradigm you see there is used in a lot of desktop software.)
>>
>> Those are for selection, not for completion.  I thought we'd already
>> established that the two are quite different.  We should not conflate
>> them, nor force users use only one of them where both could make
>> sense, IMO.
>
> I don't think the distinction matters here.  We are discussing if
> candidates should be shown eagerly, and my answer is "yes".

Are you using an alternative completion framework? I find it interesting
how some people agree with the distinction and others don't, and wonder
if the way they use Emacs shapes their opinion.

-- 
	Philip K.

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

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

>> The fact that this UI paradigm is so ubiquitous suggests that you might
>> be in the minority here.
>
> I don't think that that should delegitimize the preference though.

Sure.

It should tell us something about which is the better default, though.

>>>> (It's also a popular choice elsewhere, try for example entering
>>>> something into the search bar on Google or DuckDuckGo.  The same
>>>> paradigm you see there is used in a lot of desktop software.)
>>>
>>> Those are for selection, not for completion.  I thought we'd already
>>> established that the two are quite different.  We should not conflate
>>> them, nor force users use only one of them where both could make
>>> sense, IMO.
>>
>> I don't think the distinction matters here.  We are discussing if
>> candidates should be shown eagerly, and my answer is "yes".
>
> Are you using an alternative completion framework? I find it interesting
> how some people agree with the distinction and others don't, and wonder
> if the way they use Emacs shapes their opinion.

I use ivy, and previously I've used ido for many years.  They both show
candidates immediately, without having to press TAB.

As does most other completion frameworks, AFAICT: helm, icomplete, smex,
selectrum, etc.

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

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-04-11 14:19]:
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > - It uses data structures quite different from what completing-read
> >   uses. That's pretty inconvenient, and requires a mental switch. I'd 
> > rather the two functions (or some future versions of them) were more
> > similar in shape, yet (obviously) different in behavior.
> 
> I think it would be possible to also support alists, hash tables,
> vectors but I'm not sure if it is necessary. Functions might be
> interesting to consider.

Helm has good support for such data structures. Completing-read can
also support hashes. I would like that such functions support variety
of data structures. Because they don't I have to cope with
it. Currently I am removing the built-in helm from all my functions as
I want them to work with any completion system.

One way I use for complex data structures is to have some kind of ID
and visual description, then by using the ID I fetch the data
structure later.

(defun rcd-completing-read-sql-hash (prompt sql pg &optional history initial-input)
  "Complete selection by using SQL.

First column shall be unique id, followed by text representation. Example SQL query:

SELECT people_id, people_firstname || ' ' || people_lastname FROM people

PG is database handle. HISTORY is supported with INITIAL-INPUT"
  (let* ((hash (rcd-sql-hash-with-key sql pg))
	 (values (hash-table-values hash))
	 (length (length values)))
    (if (= length 1)
	  (car values)
      (let* ((completion-ignore-case t)
	     (choice (completing-read prompt hash nil t initial-input history))
	     (choice (string-trim choice))
	     (id (gethash choice hash)))
	id))))

(defun rcd-sql-hash-with-key (sql pg)
  "Returns hash with key TEXT [ID] and value ID from SQL result
in the form ID, TEXT"
  (let ((hash (make-hash-table :test 'equal))
	(res (rcd-sql sql pg)))
    (dolist (i res hash)
      (cond ((eq (type-of i) 'vector) (puthash (format "%s [%s]" (elt i 1) (elt i 0)) (elt i 0) hash))))))

Then I can complete by using database entries which are converted to
hash. And I place unique IDs appended to the string such as:

Selection entry [123]

Some entries may have duplicate names. Showing the ID is necessary to
make the name unique as selection time.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Date: Sun, 11 Apr 2021 13:18:47 +0200
> Cc: emacs-devel@gnu.org
> 
> But this raises a more general question, of whether selecting-read and
> completing-read should be drop-in replacements of one another.

I think they should strive to, because it's conceivable that we will
have a user option to determine which one to call where currently we
call completing-read.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 11 Apr 2021 06:37:08 -0500
> Cc: monnier@iro.umontreal.ca, philipk@posteo.net, emacs-devel@gnu.org, 
> 	dgutov@yandex.ru
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Right away, i.e. even without the user typing anything? that'd produce
> >> > a huge list of candidates, which would be impractical to display.
> >> This is what e.g. ivy does on M-x, and it works well in practice.
> >>
> >> I find it much better to display candidates this way, and I think it
> >> would be a step forward if Emacs dit this itself OOTB.
> >
> > For me, it would be a step back.  I never use completion for
> > discovery, I always have a pretty good idea what I'm about to type
> > when I do.
> 
> The fact that this UI paradigm is so ubiquitous suggests that you might
> be in the minority here.

Am I supposed to be ashamed to be in the minority?

This isn't a "majority wins" situation.  A minority (if it is a
minority) that's used to do stuff the old ways shouldn't be ignored.

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Sun, 11 Apr 2021 14:24:23 +0200
> 
> > I don't think the distinction matters here.  We are discussing if
> > candidates should be shown eagerly, and my answer is "yes".
> 
> Are you using an alternative completion framework? I find it interesting
> how some people agree with the distinction and others don't, and wonder
> if the way they use Emacs shapes their opinion.

My theory is that some people prefer the selection-type of completion,
and others (like me) don't.  I don't see a reason to try to settle the
difference, it's a matter of personal preferences and past experience.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 11 Apr 2021 07:58:51 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, dgutov@yandex.ru, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> Philip Kaludercic <philipk@posteo.net> writes:
> 
> >> The fact that this UI paradigm is so ubiquitous suggests that you might
> >> be in the minority here.
> >
> > I don't think that that should delegitimize the preference though.
> 
> Sure.
> 
> It should tell us something about which is the better default, though.

I didn't realize we are discussing here a change in the defaults?  Are
we?  If so, what defaults are involved, and how are they supposed to
change?

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> The fact that this UI paradigm is so ubiquitous suggests that you might
>> be in the minority here.
>
> Am I supposed to be ashamed to be in the minority?

Not at all.  I hope nothing I wrote seemed like it.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 11 Apr 2021 10:32:51 -0500
> Cc: philipk@posteo.net, dgutov@yandex.ru, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The fact that this UI paradigm is so ubiquitous suggests that you might
> >> be in the minority here.
> >
> > Am I supposed to be ashamed to be in the minority?
> 
> Not at all.  I hope nothing I wrote seemed like it.

"You are in the minority" is an argument that adds nothing to the
point your are trying to make, so my advice is not to use it in this
kind of discussion.

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

[Philip Kaludercic]

Jean Louis <bugs@gnu.support> writes:

> One way I use for complex data structures is to have some kind of ID
> and visual description, then by using the ID I fetch the data
> structure later.

I'm not sure I completely understood your example. What do hash tables
offer over lists of objects that can have a programmed representation?

-- 
	Philip K.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> "You are in the minority" is an argument that adds nothing to the
> point your are trying to make, so my advice is not to use it in this
> kind of discussion.

You presented the fact that you don't do a certain thing as something
that was of interest to the discussion.  Then certainly pointing out
that that that's not the common use case is also of interest.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Sun, 11 Apr 2021 13:18:47 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> But this raises a more general question, of whether selecting-read and
>> completing-read should be drop-in replacements of one another.
>
> I think they should strive to, because it's conceivable that we will
> have a user option to determine which one to call where currently we
> call completing-read.

But why should that mean that both interfaces should be identical?  It
seems cleaner to instead have a sr->cr translation layer, as to prevent
unnecessary dependencies between the two interfaces?

-- 
	Philip K.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 11 Apr 2021 17:55:23 +0200
> Cc: philipk@posteo.net, dgutov@yandex.ru,
>  Stefan Kangas <stefankangas@gmail.com>, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > "You are in the minority" is an argument that adds nothing to the
> > point your are trying to make, so my advice is not to use it in this
> > kind of discussion.
> 
> You presented the fact that you don't do a certain thing as something
> that was of interest to the discussion.  Then certainly pointing out
> that that that's not the common use case is also of interest.

"Of interest" and "helps the discussion" aren't necessarily the same
thing.

The "majority" argument sounds like "there's your opinion and there's
mine, but mine is more important".  That is never helpful.

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: dgutov@yandex.ru,  emacs-devel@gnu.org
> Date: Sun, 11 Apr 2021 18:14:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But this raises a more general question, of whether selecting-read and
> >> completing-read should be drop-in replacements of one another.
> >
> > I think they should strive to, because it's conceivable that we will
> > have a user option to determine which one to call where currently we
> > call completing-read.
> 
> But why should that mean that both interfaces should be identical?  It
> seems cleaner to instead have a sr->cr translation layer, as to prevent
> unnecessary dependencies between the two interfaces?

I don't understand what you mean by "translation layer".

What I have in mind is a user option that tells completing-read to
invoke the "selection kind" of UI.  It follows that being able to use
the same arguments and data structures would be a boon for allowing
that.

And note that I said "should strive to", not "should be".  If there
are good reasons why they cannot have the same or similar enough
signatures, it's not a catastrophe.  But we should have a good reason,
IMO.

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

[Dmitry Gutov]

On 11.04.2021 16:39, Eli Zaretskii wrote:
>>> I don't think the distinction matters here.  We are discussing if
>>> candidates should be shown eagerly, and my answer is "yes".
>> Are you using an alternative completion framework? I find it interesting
>> how some people agree with the distinction and others don't, and wonder
>> if the way they use Emacs shapes their opinion.
> My theory is that some people prefer the selection-type of completion,
> and others (like me) don't.  I don't see a reason to try to settle the
> difference, it's a matter of personal preferences and past experience.

I agree we should be able to keep both kinds of completion and let the 
users choose they generally prefer, that's why I made emphasis on which 
usages really *can't* employ the wrong kind of completion (and thus 
would generally follow the programmer's hint and not the user 
customization).

I do think it's unfortunate you're adamant about using only one of these 
approaches, because we're missing out on valuable feedback and 
recommendations this way (and maybe some strategic support), but it's 
not a blocker of any kind, for this or related issues.

When I think back, though, and recall that you also agreed that more 
"IDE features" are important to have in Emacs, I believe that at some 
point in the future, as we're making progress on that path, some 
defaults will need to change, because AFAIK the vast majority of current 
"IDE" users are used to the selection-type completion, and so one is 
pretty strongly associated with the other. Again, not necessarily, but 
it would make sense.

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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dgutov@yandex.ru,  emacs-devel@gnu.org
>> Date: Sun, 11 Apr 2021 18:14:02 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> But this raises a more general question, of whether selecting-read and
>> >> completing-read should be drop-in replacements of one another.
>> >
>> > I think they should strive to, because it's conceivable that we will
>> > have a user option to determine which one to call where currently we
>> > call completing-read.
>> 
>> But why should that mean that both interfaces should be identical?  It
>> seems cleaner to instead have a sr->cr translation layer, as to prevent
>> unnecessary dependencies between the two interfaces?
>
> I don't understand what you mean by "translation layer".

completing-read has it's existing interface, and let's say that
selecting-read would not try to copy this interface 1:1. Instead a third
function could attempt to "translate" completing-read calls into
selecting-read calls, reducing the complexity of selecting-read.

I hope I'm not the only one, but writing "nil nil nil nil" just to
access a specific argument is cumbersome, and harder to extend. If it is
possible to keep a new interface cleaner, I think that this would help
it be more forwards-compatible.

-- 
	Philip K.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 11 Apr 2021 20:16:29 +0300
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca
> 
> I agree we should be able to keep both kinds of completion and let the 
> users choose they generally prefer, that's why I made emphasis on which 
> usages really *can't* employ the wrong kind of completion (and thus 
> would generally follow the programmer's hint and not the user 
> customization).

I'm not sure there could be use cases where it is clear up front which
UI is "right" and which is "wrong".  In every situation I thought
about there could be a place for both, depending on what the user
wants to do and how.

> I do think it's unfortunate you're adamant about using only one of these 
> approaches, because we're missing out on valuable feedback and 
> recommendations this way (and maybe some strategic support)

You make it sound like I could easily use the other approach, but just
won't because I'm stubborn or worse.  Nothing is farther from the
truth.  I cannot change my workflows, they are burnt into my muscle
memory.  I can only try "the other approach" briefly, and that is
unlikely to give you any useful feedback.

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: dgutov@yandex.ru,  emacs-devel@gnu.org
> Date: Sun, 11 Apr 2021 19:39:39 +0200
> 
> >> But why should that mean that both interfaces should be identical?  It
> >> seems cleaner to instead have a sr->cr translation layer, as to prevent
> >> unnecessary dependencies between the two interfaces?
> >
> > I don't understand what you mean by "translation layer".
> 
> completing-read has it's existing interface, and let's say that
> selecting-read would not try to copy this interface 1:1. Instead a third
> function could attempt to "translate" completing-read calls into
> selecting-read calls, reducing the complexity of selecting-read.

That's possible if necessary, but is not the best solution.  It is
better not to need any translation at all, I hope you will agree.

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

[Drew Adams]

> I'm not sure there could be use cases where it is clear up front which
> UI is "right" and which is "wrong".  In every situation I thought
> about there could be a place for both, depending on what the user
> wants to do and how.

+1.  That, taken generally, is one of the most
important points about Emacs UI, defaults, etc.

Defaults can be useful, and we of course always
want to find useful default behaviors.  But most
important is that users have control.

There's no DWIM or hard-coded substitute for giving
users control, and preferably making it _easy and
clear_ for users to control behavior. 

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

[Dmitry Gutov]

On 11.04.2021 21:19, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sun, 11 Apr 2021 20:16:29 +0300
>> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca
>>
>> I agree we should be able to keep both kinds of completion and let the
>> users choose they generally prefer, that's why I made emphasis on which
>> usages really *can't* employ the wrong kind of completion (and thus
>> would generally follow the programmer's hint and not the user
>> customization).
> 
> I'm not sure there could be use cases where it is clear up front which
> UI is "right" and which is "wrong".  In every situation I thought
> about there could be a place for both, depending on what the user
> wants to do and how.

We have discussed the case of xref-show-definitions-completing-read, 
whose use of completing-read you described as "very confusing" and 
"weird paradigm".

Whereas xref-show-definitions-buffer provides, in a way, a "selecting 
read" behavior, which you are fine with. So if 
xref-show-definitions-completing-read could itself reliably use a more 
"selecting read"-like interface, the impression should be better.

>> I do think it's unfortunate you're adamant about using only one of these
>> approaches, because we're missing out on valuable feedback and
>> recommendations this way (and maybe some strategic support)
> 
> You make it sound like I could easily use the other approach, but just
> won't because I'm stubborn or worse.  Nothing is farther from the
> truth.  I cannot change my workflows, they are burnt into my muscle
> memory.  I can only try "the other approach" briefly, and that is
> unlikely to give you any useful feedback.

I do not think it is easy, nor do I think you owe us anything, or that 
you don't have better things to do with your time.

I do believe the odds are high you could improve your workflows if you 
spend time on it, but I don't really know your work requirements, so I 
wouldn't bet a house on this.

But I'll probably continue asking for it, because even minor 
improvements in your efficiency are a win for us all. And the other 
stuff mentioned previously.

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

[Stefan Monnier]

>>> It would still miss the ability to quickly accept one of them
>>> with RET.
>> Right, but the cycle-threshold helps with that, no?
> At the moment, IIUC, the UI either lets you cycle, or shows the
> *Completions* buffer, but not both at the same time.

Looks like we may want to revisit this choice, then.

> Perhaps you're suggesting to remove that limitation

Exactly.

> (what would happen if I dismiss *Completions* and then press TAB
> again?).

I don't understand the question.

> Maybe the optimal UI which is close enough to the default behavior would
> look more like icomplete-vertical: the items closer to the prompt, and there
> is a visible selection which you can accept with RET.

That's probably right.


        Stefan

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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

>>> It would still miss the ability to quickly accept one of them
>>> with RET.
>> Right, but the cycle-threshold helps with that, no?
>
> At the moment, IIUC, the UI either lets you cycle, or shows the
> *Completions* buffer, but not both at the same time.

I get the *Completions* buffer if I press '?', or do you mean something else?

-- 
	Philip K.

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

[Stefan Monnier]

> IIUC, a variable "completing-read-show-matches-on-no-input" that would be
> setq-local'd by Xref and read by completion UI's would do the job.  Or am
> I missing something?

Yes, something like that, tho I think it'd be more like "show matches
eagerly" or maybe "use selection UI" ;-)

Also, rather than a new var, I'd prefer using something like the "extra
properties" (`completion-extra-properties`) since these already have a
matching mechanism for the `completion-at-point` case.


        Stefan

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

[Drew Adams]

> > At the moment, IIUC, the UI either lets you cycle, or shows
> > the *Completions* buffer, but not both at the same time.
> 
> Looks like we may want to revisit this choice, then.
> 
> > Perhaps you're suggesting to remove that limitation
> 
> Exactly.

FWIW, my tiny library sortie.el provides that.

You can cycle while seeing the candidates you cycle
among in *Completions*.  And you can change sort
orders on the fly by hitting a key (`C-,' by default).

The file header has a tiny toy example of Lisp use.

In general, IMO, it makes sense to bind both
`display-sort-function' and `cycle-sort-function' to
the same function.  (I've never understood why Emacs
has separate sort functions for display and cycling.)

(I pulled sortie.el out of what Icicles provides for
defining and changing sort orders.  And I pulled
keysee.el, which uses sortie.el, out of Icicles key
completion.)

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

[Drew Adams]

Sorry; I meant to include links:

Sortie code: https://www.emacswiki.org/emacs/download/sortie.el

 Doc: https://www.emacswiki.org/emacs/Sortie

KeySee code: https://www.emacswiki.org/emacs/download/keysee.el

 Doc: https://www.emacswiki.org/emacs/KeySee

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

[Dmitry Gutov]

On 12.04.2021 00:52, Philip Kaludercic wrote:
> I get the*Completions*  buffer if I press '?', or do you mean something else?

My mistake, never got used to a "normal" character in this binding.

I invoke *Completions* with TAB TAB, which is obviously taken if cycling 
is used.

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

[Stefan Monnier]

>> I get the*Completions*  buffer if I press '?', or do you mean something else?
> My mistake, never got used to a "normal" character in this binding.
> I invoke *Completions* with TAB TAB, which is obviously taken if cycling
> is used.

Oh, now I understand what you meant: it's not a problem because I was
suggesting to add an option that would cause the default completion to
bring up *Completions* eagerly without the user having to hit anything
like TAB.

But the default completion UI should be improved w.r.t the *Completions*
buffer, in that I think the buffer should be automatically refreshed
when it's displayed, and also when you cycle it would make a lot of
sense to highlight the choice that it selected somehow.


        Stefan

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

[Drew Adams]

1> I was suggesting to add an option that would cause the
 > default completion to bring up *Completions* eagerly
 > without the user having to hit anything like TAB.
 > 
2> But the default completion UI should be improved w.r.t the
 > *Completions* buffer, in that I think the buffer should
 > be automatically refreshed when it's displayed, and also
3> when you cycle it would make a lot of sense to highlight
 > the choice that it selected somehow.

Great ideas.  All invented by 2005 in Icicles, and
suggested for Emacs.  Perhaps their time has come?

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

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-04-11 18:53]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > One way I use for complex data structures is to have some kind of ID
> > and visual description, then by using the ID I fetch the data
> > structure later.
> 
> I'm not sure I completely understood your example. What do hash tables
> offer over lists of objects that can have a programmed
> representation?

Completing read supports hash tables, once representation candidate
has been selected one can then use the key to get value of some quite
different or very complex data structure.

(setq h (make-hash-table :test 'equal))
(puthash "United States" [("ABC" 30 t)] h)
(puthash "Australia" 2 h)
(puthash "United Kingdom" 3 h)

(message "%s" (gethash (completing-read "Choice: " h) h)) ⇒ "[(ABC 30 t)]"



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Philip Kaludercic]

Jean Louis <bugs@gnu.support> writes:

> * Philip Kaludercic <philipk@posteo.net> [2021-04-11 18:53]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> > One way I use for complex data structures is to have some kind of ID
>> > and visual description, then by using the ID I fetch the data
>> > structure later.
>> 
>> I'm not sure I completely understood your example. What do hash tables
>> offer over lists of objects that can have a programmed
>> representation?
>
> Completing read supports hash tables, once representation candidate
> has been selected one can then use the key to get value of some quite
> different or very complex data structure.
>
> (setq h (make-hash-table :test 'equal))
> (puthash "United States" [("ABC" 30 t)] h)
> (puthash "Australia" 2 h)
> (puthash "United Kingdom" 3 h)
>
> (message "%s" (gethash (completing-read "Choice: " h) h)) ⇒ "[(ABC 30 t)]"

But don't you think that it is weird that completing-read returns the
representation and not the object itself. That is exactly what I want to
avoid by having the representation computed using a method.

The best I can think of is using hash-maps to generate anonymous methods
but even that seems to be looking at the issue backwards.

-- 
	Philip K.

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

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-04-12 13:15]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Philip Kaludercic <philipk@posteo.net> [2021-04-11 18:53]:
> >> Jean Louis <bugs@gnu.support> writes:
> >> 
> >> > One way I use for complex data structures is to have some kind of ID
> >> > and visual description, then by using the ID I fetch the data
> >> > structure later.
> >> 
> >> I'm not sure I completely understood your example. What do hash tables
> >> offer over lists of objects that can have a programmed
> >> representation?
> >
> > Completing read supports hash tables, once representation candidate
> > has been selected one can then use the key to get value of some quite
> > different or very complex data structure.
> >
> > (setq h (make-hash-table :test 'equal))
> > (puthash "United States" [("ABC" 30 t)] h)
> > (puthash "Australia" 2 h)
> > (puthash "United Kingdom" 3 h)
> >
> > (message "%s" (gethash (completing-read "Choice: " h) h)) ⇒ "[(ABC 30 t)]"
> 
> But don't you think that it is weird that completing-read returns the
> representation and not the object itself. That is exactly what I want to
> avoid by having the representation computed using a method.

That could be implemented as some new options.

But users like me may not always want to use hash, I may want to use
the key, though the key has some optional data, I may wish to use key
only. At some other times I may want to use value in the hash or part
of that value.

How I understand, you want to use values or some variable data to
compute representation, fine and I hope it will not break standard
completion.

Side note, representation by hash key does not really support
duplicates, so when constructing a key, I am adding the unique ID to
the key to avoid duplicates. Maybe usages of duplicates is not
clear. Completion candidates could be in some order like

"Cash"
"Expenses" - could carry value 1
"Transfers"
"Expenses" - could carry value 2

and by looking into the order user could recognize that second one is
the one that is wanted. But as there is no option to have duplicates
in a hash, I am modifying keys to carry unique ID.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

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

[Philip Kaludercic]

Jean Louis <bugs@gnu.support> writes:

> How I understand, you want to use values or some variable data to
> compute representation, fine and I hope it will not break standard
> completion.

You don't have to worry about that, I'm playing with the concept of
selection.

-- 
	Philip K.

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

[Stefan Monnier]

> I attached a primitive version of selecting-read to this message.
> The UI is horridly primitive, but the basic idea should be understandable.

Nice starting point, thanks.
[ I'm too biased towards `completing-read` to make very useful comments
  at this point.  ]

I think if you want to get traction with this, you'll want to come up
with some concrete uses and a real UI which provides something that is
better (in those particular uses) than what we can already get from
existing completion systems (company/helm/ivy/younameit).


        Stefan

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

[Eric Abrahamsen]

Philip Kaludercic <philipk@posteo.net> writes:

> Jean Louis <bugs@gnu.support> writes:
>
>> * Philip Kaludercic <philipk@posteo.net> [2021-04-11 18:53]:
>>> Jean Louis <bugs@gnu.support> writes:
>>> 
>>> > One way I use for complex data structures is to have some kind of ID
>>> > and visual description, then by using the ID I fetch the data
>>> > structure later.
>>> 
>>> I'm not sure I completely understood your example. What do hash tables
>>> offer over lists of objects that can have a programmed
>>> representation?
>>
>> Completing read supports hash tables, once representation candidate
>> has been selected one can then use the key to get value of some quite
>> different or very complex data structure.
>>
>> (setq h (make-hash-table :test 'equal))
>> (puthash "United States" [("ABC" 30 t)] h)
>> (puthash "Australia" 2 h)
>> (puthash "United Kingdom" 3 h)
>>
>> (message "%s" (gethash (completing-read "Choice: " h) h)) ⇒ "[(ABC 30 t)]"
>
> But don't you think that it is weird that completing-read returns the
> representation and not the object itself. That is exactly what I want to
> avoid by having the representation computed using a method.
>
> The best I can think of is using hash-maps to generate anonymous methods
> but even that seems to be looking at the issue backwards.

This is my main complaint with `completing-read' -- you can pass it data
structures like alists or hash tables, but you still only get the string
keys back out of it. In the past I've imagined being able to pass a
lambda to `completing-read' (as if it didn't have enough arguments) that
would be used to extract the desired value. If we're going to build an
ad-hoc structure specifically for completion, we could just build it
inside the call to `completing-read', and it could do the caching and
value extraction.

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

[Drew Adams]

> > But don't you think that it is weird that completing-read returns the
> > representation and not the object itself. That is exactly what I want to
> > avoid by having the representation computed using a method.
> >
> > The best I can think of is using hash-maps to generate anonymous methods
> > but even that seems to be looking at the issue backwards.
> 
> This is my main complaint with `completing-read' -- you can pass it data
> structures like alists or hash tables, but you still only get the string
> keys back out of it. In the past I've imagined being able to pass a
> lambda to `completing-read' (as if it didn't have enough arguments) that
> would be used to extract the desired value. If we're going to build an
> ad-hoc structure specifically for completion, we could just build it
> inside the call to `completing-read', and it could do the caching and
> value extraction.

I already mentioned that you can put the _full_ candidate
-- whatever Lisp object it might be -- on the _display_
candidate, which is just a string.

Then, providing you have a `completing-read' that doesn't
strip off text properties, you have everything you need,
just in the returned string.

How to put the full candidate, which might be a list or
whatever, on just a string?

Suppose the full candidate is an alist entry:
("cand" . WHATEVER).  The display candidate is "cand".
Users match against it, and that's what `completing-read'
returns.  But you want to get the WHATEVER when "cand"
is chosen.

Just replace "cand" by a copy of that string with a text
property that has value WHATEVER:

(defun my-put-whole-cand-prop (cand)
  "Put cdr of CAND on its car, as text property `my-whole-cand'.
Returns a new propertized string corresponding to (car CAND)."
  (let ((text-cand  (copy-sequence (car cand))))
    (put-text-property 0 (length text-cand)
                       'my-whole-candidate (cdr cand)
                       text-cand)
    (setcar cand text-cand)
    text-cand))

Use (get-text-property STRING 'my-whole-cand') to get
back WHATEVER.

If you wanted the full candidate, ("cand" . WHATEVER),
instead of just WHATEVER, then you'd use that as the
property value.
___

I do the same thing with bookmarks, so you can have more
than one bookmark with the same name.  In that case, I
put the full bookmark, a list whose car is the bookmark
name, on that name as a property:

(put-text-property 0 (length bname) 'full-record bmk bname)

So the full bookmark has a car that's a string that
contains the full bookmark as a property.  And yes, that
full bookmark that's the property value has a car that's
the string that contains...

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

[Eric Abrahamsen]

Drew Adams <drew.adams@oracle.com> writes:

>> > But don't you think that it is weird that completing-read returns the
>> > representation and not the object itself. That is exactly what I want to
>> > avoid by having the representation computed using a method.
>> >
>> > The best I can think of is using hash-maps to generate anonymous methods
>> > but even that seems to be looking at the issue backwards.
>> 
>> This is my main complaint with `completing-read' -- you can pass it data
>> structures like alists or hash tables, but you still only get the string
>> keys back out of it. In the past I've imagined being able to pass a
>> lambda to `completing-read' (as if it didn't have enough arguments) that
>> would be used to extract the desired value. If we're going to build an
>> ad-hoc structure specifically for completion, we could just build it
>> inside the call to `completing-read', and it could do the caching and
>> value extraction.
>
> I already mentioned that you can put the _full_ candidate
> -- whatever Lisp object it might be -- on the _display_
> candidate, which is just a string.

I missed that the first time around! That's an interesting approach, and
one that hadn't occurred to me. In the simplest case it ends up being
way, way more code than just referencing the alist again, but I can
imagine it coming in handy in a larger system where the string travels
through many moving parts. Thanks.

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

[Drew Adams]

> > I already mentioned that you can put the _full_ candidate
> > -- whatever Lisp object it might be -- on the _display_
> > candidate, which is just a string.
> 
> I missed that the first time around! That's an interesting approach, and
> one that hadn't occurred to me. In the simplest case it ends up being
> way, way more code than just referencing the alist again, 

Why do you think so?  You have the string; you just use
`get-text-property' to get from it anything you need.

(Not to mention that looking up a key in an alist (1)
takes time and (2) doesn't allow for duplicate keys.)

All you're storing is a pointer.  The "object" you're
pointing to exists anyway, and needs to continue to exist
for you to do something with it.  You're adding nothing,
really, but a pointer. 

> but I can imagine it coming in handy in a larger system
> where the string travels through many moving parts.

I can't imagine what you're imagining. ;-)  It's about
`completing-read' only, however small your "system" is.

It requires that `completing-read' that doesn't strip
properties; that's all.

> Thanks.

You're welcome.

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

[Eric Abrahamsen]

Drew Adams <drew.adams@oracle.com> writes:

>> > I already mentioned that you can put the _full_ candidate
>> > -- whatever Lisp object it might be -- on the _display_
>> > candidate, which is just a string.
>> 
>> I missed that the first time around! That's an interesting approach, and
>> one that hadn't occurred to me. In the simplest case it ends up being
>> way, way more code than just referencing the alist again, 
>
> Why do you think so?  You have the string; you just use
> `get-text-property' to get from it anything you need.
>
> (Not to mention that looking up a key in an alist (1)
> takes time and (2) doesn't allow for duplicate keys.)

I mean that using `put-text-property' on one side of the
`completing-read' and `get-text-property' on the other is more code
(okay, maybe I was exaggerating, but it's still more code) than building
an alist on one side of the `completing-read' and then using
(cdr (assoc-string on the other. There may be other advantages to the
approach, but what I'd like to see is `completing-read' (or
`selecting-read') doing this job itself.

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

[Drew Adams]

> >> > I already mentioned that you can put the _full_ candidate
> >> > -- whatever Lisp object it might be -- on the _display_
> >> > candidate, which is just a string.
> >>
> >> I missed that the first time around! That's an interesting approach, and
> >> one that hadn't occurred to me. In the simplest case it ends up being
> >> way, way more code than just referencing the alist again,
> >
> > Why do you think so?  You have the string; you just use
> > `get-text-property' to get from it anything you need.
> >
> > (Not to mention that looking up a key in an alist (1)
> > takes time and (2) doesn't allow for duplicate keys.)
> 
> I mean that using `put-text-property' on one side of the
> `completing-read' and `get-text-property' on the other is more code
> (okay, maybe I was exaggerating, but it's still more code) than building
> an alist on one side of the `completing-read' and then using
> (cdr (assoc-string on the other. There may be other advantages to the
> approach, but what I'd like to see is `completing-read' (or
> `selecting-read') doing this job itself.

I don't think you're right about the relative work/code in
those two cases, but I won't argue about that.

I will say (again) that (cdr (assoc-string...)) won't deal
with duplicate keys.  You or someone else spoke of unique
objects.  Alist keys are not, in general, unique, even
when alist elements might be.  That's one reason I use the
approach I described (when I use it).  

Here's the doc string of a function I use to get the full
alist candidate that corresponds to a STRING display
candidate.  You can see that having the full candidate on
the string as a text property is one case - true some of
of the time.  In other cases I don't do that.

,----
| icicle-get-alist-candidate is a compiled Lisp function in
| 'icicles-fn.el'.
| 
| (icicle-get-alist-candidate STRING &optional NO-ERROR-P)
| 
| Return full completion candidate that corresponds to displayed STRING.
| STRING is the name of the candidate, as shown in `*Completions*'.
| Non-nil optional argument NO-ERROR-P means display a message and
| return nil instead of raising an error if STRING is ambiguous.
| If the value of NO-ERROR-P is `no-error-no-msg', then show no message
| and just return nil.
| 
| If `icicle-whole-candidate-as-text-prop-p' is non-nil, then the full
| candidate might be available as text property `icicle-whole-candidate'
| of STRING.  If so, then that is used.
| 
| Otherwise, the full candidate is obtained from
| `icicle-candidates-alist'.  In this case:
|  If the user cycled among candidates or used `mouse-2', then use the
|    current candidate number, and ignore STRING.
|  Otherwise:
|    If only one candidate matches STRING, use that.
|    Else respect NO-ERROR-P and tell user to use cycling or `mouse-2'.
`----

[FWIW, I don't want completing-read to do any such thing in
all cases.  Maybe you meant on demand, e.g., with some new
arg.  I do it on demand, indicating when I want/need it by
binding `icicle-whole-candidate-as-text-prop-p'.  And yes,
it's done in the Icicle mode version of `completing-read'.]

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

[Dmitry Gutov]

On 12.04.2021 16:59, Stefan Monnier wrote:
> I think if you want to get traction with this, you'll want to come up
> with some concrete uses and a real UI which provides something that is
> better (in those particular uses) than what we can already get from
> existing completion systems (company/helm/ivy/younameit).

I think that's a very high bar (ivy and friends are already pretty good 
as "selecting read" UIs too).

Rather than besting them, I think the criterion can be to have something 
better than both built-in completing-read and icomplete as 
selecting-read, and could be accepted by our users as better replacement 
in those cases in core code which we have identified as "needs selection 
UI".

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

[Dmitry Gutov]

On 12.04.2021 04:32, Stefan Monnier wrote:
> Oh, now I understand what you meant: it's not a problem because I was
> suggesting to add an option that would cause the default completion to
> bring up*Completions*  eagerly without the user having to hit anything
> like TAB.

I had a rather more involved scenario in mind:

- Start completion, *Completions* is shown (ok).
- Switch to *Completion*, press 'q' (because sometimes you need to see 
the buffer that was in that window, for example). *Completions* is hidden.
- Can't bring it back because TAB only cycles.

But ok, '?' will bring it back, if you know that binding and didn't 
change it.

> But the default completion UI should be improved w.r.t the*Completions*
> buffer, in that I think the buffer should be automatically refreshed
> when it's displayed, and also when you cycle it would make a lot of
> sense to highlight the choice that it selected somehow.

Sure.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 57 bytes --]


Here is an updated version, not with improved visuals:


[-- Attachment #2: selecting-read.el --]
[-- Type: application/emacs-lisp, Size: 12118 bytes --]

[-- Attachment #3: Type: text/plain, Size: 3832 bytes --]


For the most part, the suggestion is the same, I just added an
additional generic function

           (selecting-read-flags object)

that returns a list of flags, to indicate if an object is selectable,
should be folded by default, etc.

As a demonstration, the option selecting-read-auto-narrow enabled a
behaviour that is similar to what selecting completion framework
provide.

I have also mentioned that a "translation function" could be written to
translate completing-read calls into selecting-read. Here is an example
that could be set to completing-read-function, even if it does not
implement the entire interface:

--8<---------------cut here---------------start------------->8---
(defun selecting-read-<-completing-read (prompt collection &optional
					       predicate
					       require-match
					       initial-input
					       _hist
					       default
					       _inherit-input-method)
  "Translation interface for `completing-read' to `selecting-read'.
PROMPT, COLLECTION, PREDICATE, REQUIRE-MATCH, INITIAL-INPUT and
DEFAULT are all interpreted as by `completing-read'."
  (or (selecting-read (all-completions "" collection predicate)
		      :must-select (not (memq require-match
					      '(confirm-after-completion
						confirm
						nil)))
		      :initial-query initial-input
		      :prompt prompt)
      (cond ((listp default) (car default))
	    ((null default) "")
	    (default))))
--8<---------------cut here---------------end--------------->8---

There are still issues, especially with large collections (try C-h o and
wait). When I get around to working on this again, I'll try to implement
the lazy selection generation, as mentioned before.

Philip Kaludercic <philipk@posteo.net> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> 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.
>
> I attached a primitive version of selecting-read to this message. The UI
> is horridly primitive, but the basic idea should be understandable.
>
> Using generic functions, methods can be defined determining how an
> object is handled. In this iteration, three generic functions are used:
>
> - (selecting-read-represent object)
>
>   Return a string representing the object. This is the only necessary
>   method.
>
> - (selecting-read-properties object)
>
>   Return a plist denoting properties of the object
>
> - (selecting-read-children object)
>
>   Return a list of children of this object
>
> It seems that these three functions are enough, and that adding more
> would risk becoming too complicated.
>
> When evaluating a nonsensical query like
>
>         (selecting-read '((node "one" "one.1" "one.2" "one.3")
>                           (node ("two" :property "propertied" :key "value")
>                                 "two.1" "two.2")
>                           "three"))
>
> a child window appears and the user can select an object, that
> selecting-read returns directly (eq).
>
> Additional arguments are passed as keywords. A simple example is
> :multiple that lets selecting-read give me a list of items that were
> marked
>
>         (selecting-read '((node "one" "one.1\n" "one.2" "one.3")
>                           (node ("two" :property "propertied" :key "value")
>                                 "two.1" "two.2")
>                           "three")
>                         :multiple t)
>
> Because I'm not just now primarily concerned with what completing-read
> might look like, it doesn't do "automatic narrowing" like Helm or
> Ivy. The framework I sketched here should be flexible enough to support
> something like that, if preferred.

-- 
	Philip K.

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Date: Wed, 21 Apr 2021 09:20:24 +0000
> 
> Here is an updated version, not with improved visuals:

It looks like this only supports displaying selection lists and
interacting with users via buffers?  If so, I think we should also
support doing that via GUI dialogs (in Emacs configurations that
support dialogs, which nowadays means almost every build).  This is
what many other applications do, so I think we had better did the
same, at least as an option.

Of course, selections via dialogs not always make sense, so this
should be one of the possible UIs we support, not the only one.

Thanks.

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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Wed, 21 Apr 2021 09:20:24 +0000
>> 
>> Here is an updated version, not with improved visuals:
>
> It looks like this only supports displaying selection lists and
> interacting with users via buffers?  If so, I think we should also
> support doing that via GUI dialogs (in Emacs configurations that
> support dialogs, which nowadays means almost every build).  This is
> what many other applications do, so I think we had better did the
> same, at least as an option.
>
> Of course, selections via dialogs not always make sense, so this
> should be one of the possible UIs we support, not the only one.

Ideally yes, but is it possible to have a menu that can be both selected
and expanded? If not, I think the interface for selecting-read should be
updated to reflect this restriction (making every object with children
non-selectable).

> Thanks.

-- 
	Philip K.

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: emacs-devel@gnu.org
> Date: Wed, 21 Apr 2021 10:27:16 +0000
> 
> > It looks like this only supports displaying selection lists and
> > interacting with users via buffers?  If so, I think we should also
> > support doing that via GUI dialogs (in Emacs configurations that
> > support dialogs, which nowadays means almost every build).  This is
> > what many other applications do, so I think we had better did the
> > same, at least as an option.
> >
> > Of course, selections via dialogs not always make sense, so this
> > should be one of the possible UIs we support, not the only one.
> 
> Ideally yes, but is it possible to have a menu that can be both selected
> and expanded?

I don't think I understand what you mean by "expanded" here.  There
are submenus, if that's what you meant.

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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> Ideally yes, but is it possible to have a menu that can be both selected
>> and expanded?
>
> I don't think I understand what you mean by "expanded" here.  There
> are submenus, if that's what you meant.

The current model I am using assumes that selecting-read is passed a
list of objects, and each object can have sub-objects (children).

Every object has it's representation calculated and is displayed in the
popup buffer. Any objects can be selected, even those with children.

Most GUI menu interfaces I am familiar with do not allow selecting a
menu that has children, but only "leaf nodes". If selecting-read should
both have a buffer interface as well as a GUI interface, the abstraction
should be restricted so that it fits both paradigms.

-- 
	Philip K.

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: emacs-devel@gnu.org
> Date: Wed, 21 Apr 2021 12:50:00 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Ideally yes, but is it possible to have a menu that can be both selected
> >> and expanded?
> >
> > I don't think I understand what you mean by "expanded" here.  There
> > are submenus, if that's what you meant.
> 
> The current model I am using assumes that selecting-read is passed a
> list of objects, and each object can have sub-objects (children).

What is the semantics of selecting an object that has children?  Can
you give an example of such use case with one of the UIs we have today
that supports completion?

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

[Daniel Mendler]

On 4/21/21 11:20 AM, Philip Kaludercic wrote:
>>> 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.
>>
>> I attached a primitive version of selecting-read to this message. The UI
>> is horridly primitive, but the basic idea should be understandable.
>
> Here is an updated version, not with improved visuals:

I think it is interesting to experiment with actual use cases. Maybe it 
is a good demonstration to write a `read-buffer-function` and a 
`read-file-function` based on such a `selecting-read` API? The buffer 
selector is not hierarchical (at least as long as one leaves out 
perspectives or other levels), but there can be properties for 
filtering. In the case of the file selector one can experiment with 
hierarchical objects, and dynamic generation of the object tree. 
Partial-completion/initials can be used to filter/restrict the 
hierarchy. As with `completing-read` it should be possible to decouple 
the components in ui, filtering language and backend/object representation.

> I have also mentioned that a "translation function" could be written to
> translate completing-read calls into selecting-read. Here is an example
> that could be set to completing-read-function, even if it does not
> implement the entire interface:

This translation function implements only a small part of the 
`completing-read` interface (static completion tables). Did you look 
into how dynamic tables could be supported? Or is this something you 
would rather leave out to introduce a separation of `completing-read` 
and `selecting-read`? Separating the completion and selection use case 
may be technically cleaner. Going with a unified API could lead to a 
more consistent system overall?

Daniel

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

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-04-21 15:51]:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Ideally yes, but is it possible to have a menu that can be both selected
> >> and expanded?
> >
> > I don't think I understand what you mean by "expanded" here.  There
> > are submenus, if that's what you meant.
> 
> The current model I am using assumes that selecting-read is passed a
> list of objects, and each object can have sub-objects (children).
> 
> Every object has it's representation calculated and is displayed in the
> popup buffer. Any objects can be selected, even those with children.

That sounds as great new feature, sounds like I could use that. I have
"Sets" which have its sub-objects, but Sets can be run, for example I
can click on a set to open directory belonging to the set.

I would like to use something as an expandable tree similar to
speedbar in a full frame. Maybe speedbar can be used that way.

> Most GUI menu interfaces I am familiar with do not allow selecting a
> menu that has children, but only "leaf nodes". If selecting-read should
> both have a buffer interface as well as a GUI interface, the abstraction
> should be restricted so that it fits both paradigms.

Sounds well.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

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

[Philip Kaludercic]

Daniel Mendler <mail@daniel-mendler.de> writes:

> On 4/21/21 11:20 AM, Philip Kaludercic wrote:
>>>> 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.
>>>
>>> I attached a primitive version of selecting-read to this message. The UI
>>> is horridly primitive, but the basic idea should be understandable.
>>
>> Here is an updated version, not with improved visuals:
>
> I think it is interesting to experiment with actual use cases. Maybe
> it is a good demonstration to write a `read-buffer-function` and a 
> `read-file-function` based on such a `selecting-read` API? The buffer
> selector is not hierarchical (at least as long as one leaves out 
> perspectives or other levels), but there can be properties for
> filtering. In the case of the file selector one can experiment with 
> hierarchical objects, and dynamic generation of the object
> tree. Partial-completion/initials can be used to filter/restrict the 
> hierarchy.

I will try to look into this as practical examples, after the
performance has been improved and the query language is more than just
regular expressions. It hope that it would demonstrate limitations of
the current interface.

> As with `completing-read` it should be possible to decouple the
> components in ui, filtering language and backend/object
> representation.

Of course, the current implementation also provides this with the
generic functions on the one side and selecting-read-function on the
other. The current UI is pretty hacky, so I'd expect people with more
experience and enthusiasm when it comes to come up with better
solutions.

>> I have also mentioned that a "translation function" could be written to
>> translate completing-read calls into selecting-read. Here is an example
>> that could be set to completing-read-function, even if it does not
>> implement the entire interface:
>
> This translation function implements only a small part of the
> `completing-read` interface (static completion tables). Did you look 
> into how dynamic tables could be supported? Or is this something you
> would rather leave out to introduce a separation of `completing-read` 
> and `selecting-read`? Separating the completion and selection use case
> may be technically cleaner. Going with a unified API could lead to a 
> more consistent system overall?

The translation function is currently more of a POC, as there were some
messages on that topic in previous thread. It is entirely debatable if
selecting-read should provide a super-set of features that
completing-read provides, or it should just have an intersection.

I haven never really used dynamic tables for completing-read, so I'll
have to look into that and see how it might apply to selecting-read, if
at all.

> Daniel
>
>

-- 
	Philip K.

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-04-21 16:04]:
> > The current model I am using assumes that selecting-read is passed a
> > list of objects, and each object can have sub-objects (children).
> 
> What is the semantics of selecting an object that has children?  Can
> you give an example of such use case with one of the UIs we have today
> that supports completion?

In my case I do not use completion, but maybe I would, would that be
possible. I am using tabulated list mode, and have parent nodes with
children which may be launched or used depending on what I want.

Those are database nodes, and each have its ID and each have its
type. Those which have the type "Set" are those which may accept
sub-nodes.

The Set then is related to various other objects, it can be related to
people, it can be assigned to single person, to business, or group of
individuals or group of businesses, it may have some information
similar to bibliography, it could have its expiry date, tags, author,
permissions, including revision, language, it could have some
hyperlink, action status such as TODO/COMPLETED, it could be related
to domain name, or get related license, or a report of completion. It
can have its description and text as larger information related to the
set.

How it could be launched?

- for sending purposes, it could be chosen or selected similar to MIME
  so that all related sub-nodes or children get packed, compiled
  together and sent as a package to somebody by email;

- In case of documents being shared, it could share each document one
  by one, instead of all of them being packed and shared at once;

- it can be sent by email, with description and list of sub-nodes, but
  without including the sub-node objects;

- A Set can be opened as a directory by one click.

- In case of videos being played, it could represent a playing
  list. When launched, it could play one by one media files. In other
  words, Set could have its own types.

- In case of geographic positions, it could be launched to show the
  map of related geographical locations and their designations as
  parsed from sub-nodes;

- It could be simple opened to show the list of sub-nodes;

- It could represent or form the index or front page, depending of the
  type; with related sub-nodes following it;

- In case of documents to be published, it could publish all related
  sub-nodes when launching it;

- In case of taking the reference to all sub-nodes, it could create
  list of referencs to sub-nodes for further sharing so that people
  may access it.

Jean

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

[Stefan Monnier]

> The current model I am using assumes that selecting-read is passed a
> list of objects, and each object can have sub-objects (children).

Then it's called a "tree" ;-)


        Stefan

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

[Yuri Khan]

On Wed, 21 Apr 2021 at 20:04, Eli Zaretskii <eliz@gnu.org> wrote:

> > The current model I am using assumes that selecting-read is passed a
> > list of objects, and each object can have sub-objects (children).
>
> What is the semantics of selecting an object that has children?  Can
> you give an example of such use case with one of the UIs we have today
> that supports completion?

Choosing a directory or a mail folder comes to mind. One occasionally
wants to say “I want to install this program into this directory, even
though it has subdirectories” or “I want to set up my filter to move
mail into this folder, even though it has subfolders”.

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

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 21 Apr 2021 22:43:28 +0700
> Cc: Philip Kaludercic <philipk@posteo.net>, Emacs developers <emacs-devel@gnu.org>
> 
> > What is the semantics of selecting an object that has children?  Can
> > you give an example of such use case with one of the UIs we have today
> > that supports completion?
> 
> Choosing a directory or a mail folder comes to mind. One occasionally
> wants to say “I want to install this program into this directory, even
> though it has subdirectories” or “I want to set up my filter to move
> mail into this folder, even though it has subfolders”.

That's easy to support with menus: just doesn't create the submenu
unless the user says so with some mouse gesture, like pressing some
modifier key when clicking on a menu item.

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

[Stefan Monnier]

> That's easy to support with menus: just doesn't create the submenu
> unless the user says so with some mouse gesture, like pressing some
> modifier key when clicking on a menu item.

I don't think Gtk menus offer such a functionality, but another approach
is to add an extra entry to the submenu that represents "the menu's entry".


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 21 Apr 2021 15:22:34 -0400
> Cc: philipk@posteo.net, emacs-devel@gnu.org, Yuri Khan <yuri.v.khan@gmail.com>
> 
> > That's easy to support with menus: just doesn't create the submenu
> > unless the user says so with some mouse gesture, like pressing some
> > modifier key when clicking on a menu item.
> 
> I don't think Gtk menus offer such a functionality

Isn't the menu data created by Emacs, GTK or not?  If so, we control
whether a menu item has children or not.

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

[Stefan Monnier]

>> > That's easy to support with menus: just doesn't create the submenu
>> > unless the user says so with some mouse gesture, like pressing some
>> > modifier key when clicking on a menu item.
>> I don't think Gtk menus offer such a functionality
> Isn't the menu data created by Emacs, GTK or not?  If so, we control
> whether a menu item has children or not.

Right, but we can't re-create the menu while it's in use, so either the
entry has/is a submenu or it isn't.  It doesn't offer "some mouse
gesture" for the user to select "the entry that corresponds to
a submenu".  AFAIK the only thing you can do is walk the tree for
a while and at the end select one of the leaves.


        Stefan

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

[Drew Adams]

> > The current model I am using assumes that selecting-read is passed a
> > list of objects, and each object can have sub-objects (children).
> 
> Then it's called a "tree" ;-)

Nit:
From the description, the model is a forest:
a list of trees.  (Each "object" is a tree.)