[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs completion matches selection UI
From: |
Toby Cubitt |
Subject: |
Re: Emacs completion matches selection UI |
Date: |
Tue, 31 Dec 2013 15:52:36 +0000 |
User-agent: |
Mutt/1.5.22 (2013-10-16) |
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 <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.
> > - 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: address@hidden
web: www.dr-qubit.org
- Re: Emacs completion matches selection UI, (continued)
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/21
- Re: Emacs completion matches selection UI, Ted Zlatanov, 2013/12/22
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/22
- Re: Emacs completion matches selection UI, Ted Zlatanov, 2013/12/23
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/23
- Re: Emacs completion matches selection UI, Ted Zlatanov, 2013/12/23
- Re: Emacs completion matches selection UI, Toby Cubitt, 2013/12/30
- Re: Emacs completion matches selection UI, Leo Liu, 2013/12/30
- Re: Emacs completion matches selection UI, joakim, 2013/12/31
- Re: Emacs completion matches selection UI, Dmitry Gutov, 2013/12/31
- Re: Emacs completion matches selection UI,
Toby Cubitt <=
- Re: Emacs completion matches selection UI, joakim, 2013/12/31
- Re: Emacs completion matches selection UI, John Yates, 2013/12/23
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/23
- Re: Emacs completion matches selection UI, John Yates, 2013/12/23
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/28
- Re: Emacs completion matches selection UI, John Yates, 2013/12/28
- Re: Emacs completion matches selection UI, Stefan Monnier, 2013/12/30
- Re: Emacs completion matches selection UI, João Távora, 2013/12/30
- Re: Emacs completion matches selection UI, João Távora, 2013/12/28
- Re: Emacs completion matches selection UI, John Yates, 2013/12/28