Re: Emacs completion matches selection UI

[joakim@verona.se]

Toby Cubitt <tsc25@cantab.net> writes:

> 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 did this at some point. Perhaps I can dig out the code if its deemed
interesting. I have vague recollection of mailing you the code.

atm  I  dont use it because the company popup didnt work well for me,
and then I got sidetracked into providing a gtk popup, which didnt pan out.



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

-- 
Joakim Verona