Re: Emacs completion matches selection UI

[Ted Zlatanov]

On Fri, 20 Dec 2013 15:18:15 +0200 Dmitry Gutov <address@hidden> wrote: 

DG> Ted Zlatanov <address@hidden> writes:
>> I agree that's a good API option (being able to specify asynchronous
>> vs. synchronous completion) and the widget should support it.

DG> I think synchronous vs. asynchronous is a concern of a backend, and it
DG> has nothing to do with the widget. The latter only has to support the
DG> mode of operation where it passes through most of the keystrokes (except
DG> the ones specifically bound) through to Emacs. Or, better yet, captures
DG> none of them and lets the main event loop trigger right commands in the
DG> currently active maps, which in turn can modify the contents of the
DG> widget.

DG> Have you tried reading the company-mode source code?

(that reminds me I should write a CFEngine-specific completion backend
for company-mode, like I did for general completion in cfengine.el :)

I've explored anything/Helm and company-mode and a few others.  They all
have pluses and minuses.  I do like how company-mode separates frontends
from backends and agree with you about where synchronous
vs. asynchronous as a choice belongs.  But I don't know if a standard
Emacs completion/selection API like what we're discussing would have
such a separation, or if it would be better to keep it simpler.

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

DG> There's no real conflict, in-buffer completion could be made to work
DG> this way. I believe it doesn't right now just because it could be too
DG> performance-intensive when using some completion functions.

Perhaps, I don't know the history and there may be some reasonable
concerns with performance and code complexity.  But I agree this is how
it *should* work in general, since it's already how the in-minibuffer
completion works as I mentioned (modulo the extra TABs to show the
narrowed selection).

>> IMO this should be an API option.

DG> The API just has to allow updating the list on the fly.

That's not a simple thing, since Emacs doesn't have data notifications,
does it?  It would have to be a callback?  But those have performance
penalties and may need to be queued...  For large lists we have to
consider all this.

DG> 4. It does not support long lists.
>> 
>> Showing icons for every list element would be a nice option, especially
>> for the Unicode glyphs.

DG> Will this require explicit support? Emacs supports inline images.

If the list display is purely done in Emacs, it could work (although
IIRC tooltips have special rules about graphics depending on the
platform).  If it's a native widget, they sometimes have a special slot
for icons.  I don't know for sure what's the right approach here but it
seems that displaying the list in a purely Emacsian popup, as opposed to
a native widget, would be the better choice for cross-platform
consistency and functionality.

>> It may be better for the API call to allow multiple columns as an
>> option

DG> I don't think multiple column display is a good option for a popup, at
DG> all. Maybe as a special case, but that could be added later.

OK, I don't have a strong opinion here.

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

DG> Yes. Or a scroll bar. Depending on how "native" the widget will be.

DG> Another nice feature would be to allow "columns", but of a different
DG> kind. The first column would be the completion options. The second one
DG> would be their annotations (all lines up vertically). Maybe add the
DG> option of having multiple annotations for the third, fourth, etc,
DG> columns.

Right, so for example the symbol completion could show the docstring and
current value (for defcustoms).  I agree this is a very useful extra.

Ted