Re: Emacs completion matches selection UI

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 20 Dec 2013 05:08:22 +0200 Dmitry Gutov <dgutov@yandex.ru> wrote: 

DG> Ted Zlatanov <tzz@lifelogs.com> writes:
DG> The hard technical part would be to draw the tooltip in the right place
DG> above the frame, make it fast, and offer a good Elisp interface. Then
DG> the code, of which there's a lot, can integrate it.

DG>           ^^^ existing code

>> `widget-choose' does this already to some degree, right?  Do you see any
>> shortcomings in it?

DG> 1. It captures all user input.

DG> That prohibits from using it for displaying completion candidates during
DG> unobtrusive, idle completion. Which is a feature users value.

I agree that's a good API option (being able to specify asynchronous
vs. synchronous completion) and the widget should support it.

DG> 2. It has no support for incremental narrowing (consequence of item 1).

DG> You call the completion command, but there are too many candidates!
DG> What do you do? You type a few chars and see the list shortened on the fly.

DG> `widget-choose' won't let you do that. You'll have to dismiss it, type a
DG> couple of chars, display it again, see whether the list of short enough
DG> now, and if it isn't, dismiss the widget and try again. Most people will
DG> give up now and either type the whole word themselves, or start
DG> scrolling the list with the mouse, hunting for the required candidate.

Yup, absolutely.  The autocomplete web browser widgets (e.g. the jQuery
UI one) have that on-the-fly narrowing.  This specifically conflicts
with the way in-buffer completion works right now, and the in-minibuffer
completion kind of works like this if you turn `icomplete-mode' on and
hit TAB to see the candidates every time you type a character.  IMO this
should be an API option.

DG> 3. It's displayed near the mouse cursor.

DG> Did I miss a way to change that?

I'm sure that can be changed to be an API option.  Showing the
candidates near point is one of the big issues with the current
situation, where *Completions* can pop up at the other side of the
screen, so I think that's an important element as well.

DG> 4. It does not support long lists.

I'm not sure it's useful to show a very long list like we do currently.
The *Completions* buffer does it with multiple columns and TAB to move
to the next page and it's not great visually.  For instance showing all
the Unicode characters with `C-x 8 RET TAB' shows a huge list this way
(you can narrow it with "substring TAB") and would be a good use case.

Showing icons for every list element would be a nice option, especially
for the Unicode glyphs.

It may be better for the API call to allow multiple columns as an option
but default to showing just what fits on the screen in a single column,
indicating how many more candidates are not shown.  Something like this,
if only 9 lines fit on the screen (the indicators for "100 more" would
be appropriate to the native widget):

"[... 100 more ... ]
candidate1
candidate2
candidate3
candidate4
candidate5
candidate6
candidate7
[... 100 more ... ]"

And then you could handle a case like the Unicode characters by breaking
out into a table or something even denser.

Ted