From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Toby Cubitt Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Tue, 31 Dec 2013 15:52:36 +0000 Message-ID: <20131231155235.GA9294@c3po> References: <877gal5bzc.fsf@yandex.ru> Reply-To: Toby Cubitt NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388505181 7823 80.91.229.3 (31 Dec 2013 15:53:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Dec 2013 15:53:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 31 16:53:09 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vy1cw-0002wY-Q3 for ged-emacs-devel@m.gmane.org; Tue, 31 Dec 2013 16:53:07 +0100 Original-Received: from localhost ([::1]:34355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy1cw-0008Mh-9K for ged-emacs-devel@m.gmane.org; Tue, 31 Dec 2013 10:53:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy1cq-0008Ma-As for emacs-devel@gnu.org; Tue, 31 Dec 2013 10:53:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vy1cm-0003SO-4h for emacs-devel@gnu.org; Tue, 31 Dec 2013 10:53:00 -0500 Original-Received: from sanddollar.geekisp.com ([216.168.135.167]:47857) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Vy1cl-0003SE-Vb for emacs-devel@gnu.org; Tue, 31 Dec 2013 10:52:56 -0500 Original-Received: (qmail 32181 invoked by uid 1003); 31 Dec 2013 15:52:54 -0000 Original-Received: from localhost (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Tue, 31 Dec 2013 10:52:49 -0500 Content-Disposition: inline In-Reply-To: <877gal5bzc.fsf@yandex.ru> X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc User-Agent: Mutt/1.5.22 (2013-10-16) X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) X-Primary-Address: toby@dr-qubit.org X-detected-operating-system: by eggs.gnu.org: OpenBSD 4.x-5.x [fuzzy] X-Received-From: 216.168.135.167 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167013 Archived-At: 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 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