Re: Emacs completion matches selection UI

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 17 Dec 2013 13:29:30 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> Right, it wouldn't care about the invocation context, the "dismiss on
>> input when called in a buffer context" behavior would be an option.  For
>> those who like it, it can stay.  I don't think it should be the default.

SM> I'm not sure why you see it as something the user wouldn't like.

Because it's not familiar.

SM> More specifically, why would you want to force the user to use special
SM> commands to leave the "completion choice mode"?
SM> I must be missing something.

I am asking for more familiar behavior.  It's a standard "select from a
list of things" popup, sometimes with autocomplete.  Those have been
around for a long time and have well-established UI conventions, so we
don't have to invent our own.

In today's standard autocompleted lists, you finish the interaction by
either down{n}+RET to select, ESC to cancel, or with input that clears
the candidate list (so none match).  These are not special commands.
The user is not captive to the UI.  Do you need examples of how popular
and standard this behavior is today?  Do they matter to you?

Generally the candidates are displayed on a layer above the application
with transparency to indicate they are transient.

>> Otherwise yes, `completing-read' could be the list-selection API.

SM> I think "list-selection" is a restrictive way to think about it: hitting
SM> TAB to complete doesn't necessarily mean "the user wants to select
SM> a completion candidate".  It can also mean "the user wants to complete
SM> "fo" to "fooba" and then complete this identifier by adding something
SM> else that's not in any of the completion candidates.

Right, so perhaps it can do all of that.  But surely list selection is a
basic use case it should cover without trying to read minds?

>> Could `completing-read' call `widget-choose' regardless of the
>> invocation point and show a graphical popup or a simple text buffer?
>> Even in the minibuffer I think that would look OK.

SM> We wouldn't use completing-read, for API reasons.  But indeed, the
SM> minibuffer.el code is slowly moving towards using the same completion
SM> mechanism as in other buffers (completion-at-point).

OK, I understand.  It seems that you already have a direction in mind so
I only hope you make it closer to what's standard today, and that it's
exposed as an API.

Ted