[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs completion matches selection UI

From: Dmitry Gutov
Subject: Re: Emacs completion matches selection UI
Date: Fri, 03 Jan 2014 00:20:38 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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,


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 <address@hidden> 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

Could well be. So help design a good API for a generic Emacs completion UI.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]