Re: Emacs completion matches selection UI

[Ted Zlatanov]

On Fri, 22 Nov 2013 07:33:33 -0500 Ted Zlatanov <address@hidden> wrote: 

TZ> On Fri, 22 Nov 2013 09:36:20 +0200 Eli Zaretskii <address@hidden> wrote: 
>>> From: Juri Linkov <address@hidden>
>>> Cc: address@hidden,  address@hidden,  address@hidden
>>> Date: Fri, 22 Nov 2013 02:10:48 +0200
>>> 
>>> >> > Many people access `previous-history-element' in the minibuffer through
>>> >> > the up arrow, so I hope it is not commandeered for this purpose.
>>> >>
>>> >> The web browsers solve this problem by combining completions for
>>> >> history and suggestions in the same list (separated by a horizontal 
>>> >> line).
>>> >
>>> > The problem with that is that the resulting list is frustratingly
>>> > long.
>>> 
>>> The browsers put the most frequently visited history items at the top.

EZ> And therein lies the problem: I frequently cannot locate the history
EZ> item I need in that list.

TZ> I think it can be addressed: `up' goes into the popup, starting with the
TZ> history items in the order you expect.  `down' also goes into the popup
TZ> but starts with the completion candidates.  So if you want to select the
TZ> first completion candidate, you'd use `down RET'.  And for the first
TZ> history item, `up RET'.  That, plus searching (see below) would IMO be
TZ> a good UI.

>>> As I see icomplete does the same when displaying completions in the
>>> minibuffer.  So items could be sorted either by frequency or by recency
>>> in the *Completions* buffer as well.

EZ> That only solves part of the use cases.  My typical history even for a
EZ> single day is very long, and will many times defeat these strategies.
EZ> We need to have a solution for such situations, which I believe is not
EZ> uncommon in Emacs uses.

TZ> Once you've entered the completion candidates selection UI, regular
TZ> letter keys can be used to filter the list by substring because you're
TZ> in a new keymap.  Like `Control-R' in a shell with libreadline history.

>From the lack of followups I think we've settled into some agreement on
this: trigger the completion candidates UI on `up' and/or `down' and
inside that mode, remap keys for the single purpose of filtering and
selecting match candidates.  We also said the input history should be
available in the same interface, so the UI will in effect be a general
"give me things of interest" interface.  The visuals (popup or better
*Completions* buffer) are not clear yet, but we have some votes for
either approach.

I don't know this area of the code well, but can probably give it a try
in a while.  Is anyone else able to attack this problem soon-ish?  I
would gladly assist with testing and documentation, debugging, etc.

Thanks
Ted