Re: Emacs completion matches selection UI

[Toby Cubitt <tsc25@cantab.net>]

Hi Dmitry,

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.

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

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

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. I just wanted to provide simple UIs
for displaying and selecting completions.

I deliberately restricted completion-UI to do just that one simple task:
provide UIs for displaying and selecting completion candidates in a more
"modern" way than the *Completions* buffer. This seems to align with
what's being discussed here. Whereas I can't see Company being added to
Emacs as the generic Emacs completion UI.

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. Then I
could switch to using that, and ditch completion-UI and the concomitant
development and maintenance burden!

But it's inevitable each of the various completion frameworks will each
have a few very useful features that don't exist elsewhere. A better
approach is would be to, separate out and merge any useful parts of the
various packages that make sense as a generic Emacs completion UI
framework. But even if none of the code gets used, I still think you'll
end up with something much closer to completion-UI than Company.

[Further detailed comments inline, below]

Cheers,
Toby



On Tue, Dec 31, 2013 at 06:30:47PM +0400, Dmitry Gutov wrote:
> When I looked into the different completion interfaces available for
> Emacs, Completion-UI came out a lowest denominator in terms of features
> that can be supported by completion backends.

Good! Because it's precisely intended to be a "lowest common
denominator".

> Both Company and Auto-Complete support displaying candidate "summaries"
> (usually calltips and/or first line of the candidate's docstring),
> fuller documentation (in a new buffer, or in a popup, respectively), and
> Company also allows backends to return the candidate's location (as a
> position in a buffer or a line in a file), which has a respective "show
> definition" command. These are quite useful for programming.

Yes, I can see why that could be a useful feature for programming
modes. It doesn't sound particularly difficult to implement.

> Completion-UI, from what I can tell, only considers candidates as
> strings to be inserted, without any introspection facilities.

Yes, that's accurate.

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.

> And because your source interface doesn't provide much, Completion-UI
> user-interfaces don't handle the extra options either. So, as things
> currently stand, if one was to write translation functions from Company
> backends and Auto-Complete sources, a whole slice of their features
> would be lost (see `company-backends' docstring for some details).
> 
> Conversely, Company also provides swappable front-ends (see the
> docstring of `company-frontends'), so from where I stand, it should be
> easier to adapt any widgets you have implemented that we don't have as
> new Company front-ends.

Yes, but then you have to buy into the whole company-mode world. Which is
fine if that's what you want. Not so useful for a generic Emacs
completion UI.

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

> > - comes with all the UIs people usually ask for: in-buffer text
> >   completion, tooltips (both real tooltips, and the "pop-up tip"
> >   overlay-based tooltips), drop-down menus, pop-up mini-frames, list of
> >   completions in echo area, hotkeys to select completions...
> 
> Company doesn't have mini-frames and, I guess, drop-down menus. Is the
> latter a graphical menu that only allows interaction with mouse and
> arrow keys?

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

> > - 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. You still need some way to tell Company about the new
UI, so that it knows to invoke it.

> > - lets you register a new completion source with a single call to the
> >   `completion-ui-register-source' macro
> 
> Ditto.

Sure. And you'd hope all the other completion frameworks do too! (They
do.)

> > Completion-UI isn't another company-mode or anything or auto-complete-mode.
> > It was always intended to be "plumbing": a generic completion user-interface
> > toolkit that other packages could use, to unify the interface for selecting
> > completions in Emacs. It would, I think, be rather easy to modify
> > company-mode, auto-complete-mode, anything.el, etc. to use completion-UI
> > instead of their built-in UI code.
> 
> See above. It would be a lossy conversion.

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?

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.

> > I use (a slightly modified version of) Tomohiro
> > Matsuyama's popup.el library for the overlay-based tooltips. I don't know
> > if Tomohiro has papers on file.
> 
> It would be nice to be able to use it, but from what I see Matsuyama is
> not the sole significant contributor. I opened a related issue
> (https://github.com/auto-complete/popup-el/issues/50), but there's been
> no response so far.

Shame.

> By the way, why are you bundling a modified version of popup.el instead
> of contributing the changes upstream?

I simply haven't found time. I haven't even had time to roll a new
predictive release for a while now (though the git version still gets
updates). Plus my popup.el change is a trivial one-liner.


-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
and Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge

email: tsc25@cantab.net
web:   www.dr-qubit.org