Re: Emacs completion matches selection UI

[Ted Zlatanov]

On Mon, 16 Dec 2013 21:10:02 -0500 Stefan Monnier <address@hidden> wrote: 

>> I am trying to say that Emacs itself, outside of the
>> window/frame/etc. logic, should have code to "show a list of choices and
>> pick one."  An API to list selection, from the minibuffer or from a
>> buffer, with consistent key bindings and no dependence on the context in
>> which it was invoked.  This seems to be what `widget-choose' could do
>> with some polish, and that's where I'd put effort.  Do you agree?

SM> I could agree, but do note that one of the main design goals of
SM> completion-in-region-mode was that the mode is exited as a side-effect
SM> of the user's normal editing.  IOW, the user is free to ignore the list
SM> of completions and do whatever else she wants to do, rather than having
SM> to somehow indicate explicitly "oh, never mind, I won't choose any of
SM> these options".

Yes, I understand.  But this is at odds with the way that
`completing-read' and `widget-choose' and most modern UIs work.  The
user has explicitly invoked a completion command, right?  Or is
`completion-in-region-mode' ever called implicitly?

SM> But IIUC the "choice" API you suggest would allow something like
SM> completion-in-region-mode as one possible UI.

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.

>> To me, It seems crazy that there is no standard way to do this and
>> that so many packages, internal and external, have invented their own
>> UI to do it.

SM> There is one, which is completing-read.  But this one size doesn't
SM> fit all.  Maybe there is some other one size which does, but maybe not.

`completing-read' moves the focus of the user from point to the
minibuffer IIUC, and then makes the entire interaction
minibuffer-centric.  That seems to be the fundamental reason why we
invented `completion-in-region-mode', to avoid that context switch.
Otherwise yes, `completing-read' could be the list-selection API.

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.

Or maybe `completing-read' could be called for in-buffer completion if
the minibuffer could somehow be moved closer to point?  Imagine if the
minibuffer could slide up to point during the completion (perhaps by
simply growing it upwards until it reaches point), then there wouldn't
be a disorienting focus switch.  Ideally the entire minibuffer would
slide up and look the same otherwise, but that's probably going to be
hard to implement.

Ted