Re: Emacs completion matches selection UI

[Dmitry Gutov <dgutov@yandex.ru>]

On 31.12.2013 19:52, Toby Cubitt wrote:
> I really wasn't trying to promote completion-UI over Company. Indeed, I
> completely agree (as I tried to say in my previous post) that
> company-mode is much more sophisticated than completion-UI, because it
> aims to do something much more ambitious.
>
> Completion-UI was only ever intended as "plumbing": an elisp package that
> provides functions and hooks to let you display and select completion
> candidates in various UIs. Nothing more.

My impression was that you proposed it as a wrapper around Company 
and/or related packages. In that case, lowering the level of 
sophistication means lowering the amount of features, which is bad.

But if you'd like us to just use the widgets from Completion-UI (and 
maybe some code related to customizing them?), that would be okay, 
although I'd have to look into fitting any of them inside the Company's 
interaction with the command loop, or rewrite it somehow.

> Company does *much* more than this. It's practically a way of life :)

It's not hard to describe Company in the same terms: it's a framework 
designed to fetch completion candidates from the configured backends and 
allow selecting between them in the configured frontends. The "show 
documentation" and "show definition" actions are small bonus features, 
as far as complexity of implementation goes.

> I considered switching to Company for the predictive-mode UI, since I'm
> really not that interested in coding and maintaining user-interface
> code. (It's both tedious, and difficult to do well.) But Company was too
> all-encompassing: the UI elements weren't cleanly separated out from the
> rest of the mode, and I couldn't see how to make use of them without
> buying into the whole company-mode shebang.

Company front-ends are not independent widgets, indeed. They don't 
encapsulate data, instead using the same buffer-local vars Company 
operates with.

And the popup code is a relatively small part of the package, so 
"switching to Company" really means writing a backend for it, in this 
case. I wonder which part of the backend API you didn't like.

 > Maybe that's changed now.
> Though I still can't seem to see a generic UI package separate from the
> rest of company-mode.

No one's requested it, so far. There's the popular popup.el, and there's 
dropdown-list.el of unclear providence on EmacsWiki which Yasnippet uses 
optionally.

I've been thinking about splitting the Company popup code properly, but 
being able to reuse (and contribute to) the popular option which is 
popup.el would be better.

> I've got nothing at all against company-mode. Indeed, if I remember
> right, someone (you?) has added predictive-mode as a company-mode source,

Nope.

> which is great! But I didn't want to force people to use company-mode in
> order to use my predictive package.

The usual way to go about it is to have a core package (maybe using 
completion-at-point-functions) and a couple of integrations with the 
popular completion packages.

> I just wanted to provide simple UIs
> for displaying and selecting completions.

I'd wager Predictive would have a better adoption if it wasn't coupled 
to a yet-another completion package. I, for one, don't even consider 
using it for this reason. Although maybe I'm just not the target audience.

> I'd be very happy to see the UI parts of Company stripped out and made
> into a simple, generic completion UI package and added to Emacs.

Would you like to propose an API for it? Same as popup.el?

> Since completion-UI was originally written as the UI for predictive-mode
> (which is most useful in text modes), it's strong on plain text features,
> and weaker on programming-related features. For example, last time I
> looked completion-UI's auto-completion-mode was much more sophisticated
> than that in any other package (which lacked many of the features that
> are crucial to implementing predictive completion).
>
> That's why I think merging the best bits of the generic UI stuff from all
> the various frameworks would be the best way to go.

It sounds good as an abstract idea, but I'd like to see a more specific 
proposal.

>> Toby Cubitt <toby-predictive@dr-qubit.org> writes:
>>> - has completely modularised completion user-interfaces, which can be
>>>    used in any combination the user likes (within reason)
>>
>> You can have some of that in Company by setting `company-frontends' to a
>> buffer-local value. Probably. I've never tried that, though, and I'm not
>> sure if I'll ever want to, personally.
>
> Really? Some people like auto-displayed tooltips, some people hate
> them. Some people like displaying completions in the echo area, some find
> it a distraction. Makes sense to me (given that this is Emacs we're
> talking about) to let people customize it the way *they* want via
> customization options, with sensible defaults.

Sorry, I took it to mean that in Completion-UI you can configure 
user-interfaces per completion source, which is probably not the case.

The user can of course configure the used front-ends in Company, by 
customizing the global `company-frontends' value (as opposed to 
buffer-local ones I mentioned above).

> Yes. And a "completion browser" that organises all the completions into a
> hierarchical set of menus. (As with most things, this generic version can
> be overridden by particular completion sources to provide a specific
> version that's more useful. I use that e.g. in the predictive-mode LaTeX
> support when completing LaTeX commands, environments, labels, etc.)

The browser sounds useful, I'll have to look into it.

A mouse-only menu won't fit Company because it won't work for idle 
completion, as I mentioned elsewhere in this thread, and we generally 
want to provide a consistent keyboard interface. There'll also be issues 
with implementation related to that.

>>> - lets you add a new completion UI with a single call to the
>>>    `completion-ui-register-interface' macro
>>
>> Company allows you to do that with a handy macro called `defun'.
>
> Needlessly snarky.

Sorry. I was aiming for cute rather than aggressive.

 > You still need some way to tell Company about the new
> UI, so that it knows to invoke it.

Actually, no. After defining the backend function with `defun', the user 
will need to add it to `company-backends', but that's not much different 
from them having to customize `auto-completion-source' in Completion-UI.

> It's not a conversion at all. The sophisticated parts of company aren't
> about displaying menus, or popups, or tooltips, etc. I'm just saying that
> if you had a generic Emacs completion UI, you could (and should) rebase
> Company's UI on that. This is a small and boring part of
> Company. Wouldn't you be happy to see that included in Emacs, so everyone
> could benefit instead of reimplementing the wheel?

Of course I would. But a) you don't own the popup code, which we would 
like to use, b) it could be hard to augment Completion-UI widgets with 
new commands, such as, for example, which using Company you can 
currently press `f1' when the popup is active to pop up the 
documentation buffer, or `C-w' to see the function source. How hard 
would it be?

>
> That's why I went to the effort many years ago now of separating the UI
> code out of predictive-mode into something generic. Unfortunately,
> everyone then went off and invented new wheels (the UI code in Company,
> anything, auto-compelte, etc. etc.).
>
>> Also, I think `company-backends' provides a nicer API than
>> `completion-ui-register-source'.
>
> Could well be. So help design a good API for a generic Emacs completion UI.

Yes, sure. Would someone maybe submit an initial proposal?