From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Tue, 31 Dec 2013 18:45:54 +0100 Message-ID: References: <20131231155235.GA9294@c3po> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1388511989 15111 80.91.229.3 (31 Dec 2013 17:46:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Dec 2013 17:46:29 +0000 (UTC) Cc: Toby Cubitt , emacs-devel@gnu.org, Dmitry Gutov To: Toby Cubitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 31 18:46:35 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 1Vy3Ok-0006zB-KE for ged-emacs-devel@m.gmane.org; Tue, 31 Dec 2013 18:46:34 +0100 Original-Received: from localhost ([::1]:35241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy3Ok-0007V0-9i for ged-emacs-devel@m.gmane.org; Tue, 31 Dec 2013 12:46:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy3Oc-0007Ur-2F for emacs-devel@gnu.org; Tue, 31 Dec 2013 12:46:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vy3OT-0001Cy-ES for emacs-devel@gnu.org; Tue, 31 Dec 2013 12:46:26 -0500 Original-Received: from mx2.bahnhof.se ([213.80.101.12]:58184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy3OT-0001CX-10 for emacs-devel@gnu.org; Tue, 31 Dec 2013 12:46:17 -0500 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx2-reinject (Postfix) with ESMTP id F32B67AF08D; Tue, 31 Dec 2013 18:46:14 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF3) Original-Received: from mf3.bahnhof.se ([127.0.0.1]) by localhost (mf3.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSFVYJvP9UXz; Tue, 31 Dec 2013 18:46:10 +0100 (CET) Original-Received: from mta.verona.se (h-235-102.a149.priv.bahnhof.se [85.24.235.102]) by mf3.bahnhof.se (Postfix) with ESMTP id B7EB23E8C79; Tue, 31 Dec 2013 18:46:09 +0100 (CET) Original-Received: from localhost (unknown [127.0.0.1]) by mta.verona.se (Postfix) with ESMTP id 62CD84E5F2D; Tue, 31 Dec 2013 17:45:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at verona.se Original-Received: from mta.verona.se ([127.0.0.1]) by localhost (exodia.verona.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4mIwhXhK02I; Tue, 31 Dec 2013 18:45:54 +0100 (CET) Original-Received: from exodia.verona.se (www.verona.se [192.168.200.15]) by mta.verona.se (Postfix) with ESMTP id 5FAE64E5F25; Tue, 31 Dec 2013 18:45:54 +0100 (CET) In-Reply-To: <20131231155235.GA9294@c3po> (Toby Cubitt's message of "Tue, 31 Dec 2013 15:52:36 +0000") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Mac OS X 10.x X-Received-From: 213.80.101.12 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:167014 Archived-At: Toby Cubitt 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 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