From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Fri, 03 Jan 2014 00:20:38 +0400 Message-ID: <52C5CA16.3060001@yandex.ru> References: <20131231155235.GA9294@c3po> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1388694055 22322 80.91.229.3 (2 Jan 2014 20:20:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jan 2014 20:20:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Toby Cubitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 02 21:21:00 2014 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 1VyolH-0005oj-TZ for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2014 21:21:00 +0100 Original-Received: from localhost ([::1]:46914 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyolH-0005ax-EJ for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2014 15:20:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vyol7-0005Xj-Nb for emacs-devel@gnu.org; Thu, 02 Jan 2014 15:20:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vyol1-0004vT-Ml for emacs-devel@gnu.org; Thu, 02 Jan 2014 15:20:49 -0500 Original-Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:45430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vyol0-0004vF-Pv for emacs-devel@gnu.org; Thu, 02 Jan 2014 15:20:43 -0500 Original-Received: by mail-ea0-f174.google.com with SMTP id b10so6422418eae.19 for ; Thu, 02 Jan 2014 12:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mUnsP1LhZyEcmP82rgVLNopGj2j4ljYpUfwV7hHATIc=; b=m2qjcsKPloGBKcjDGuX/nGFAz3l8q/7SLjZ8FZszwdBvyrIDeeP2XUeK93xCBYvikc Y1dsnk5W+JJrkeb3NdbCsib7y4DJ/FgaY1QfMFTl6gkrbEi4tf3M/E27PFg0kzvUXoaI rT2x2F4piLZBdBw7jQBgb/man2dKTRAXDqAX95cCxXJcYYYJMLGe87bMcKO09KjlXVaE eDjx6HbGsR2UFDJa//0MkzcjF78m6UsVzFpDm4Cegh0iKonQGlxTwb35CnC777G6yP2O 9KZQNk6qEjnD+e1kWmWvLVlSL2GpcdCjfTW3mK7jep4icOwbhummw+1TFNMcLlPkiGC8 v6vA== X-Received: by 10.14.107.3 with SMTP id n3mr17288177eeg.67.1388694041832; Thu, 02 Jan 2014 12:20:41 -0800 (PST) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id e3sm139007772eeg.11.2014.01.02.12.20.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jan 2014 12:20:40 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <20131231155235.GA9294@c3po> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22e 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:167071 Archived-At: On 31.12.2013 19:52, Toby Cubitt wrote: > 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. My impression was that you proposed it as a wrapper around Company and/or related packages. In that case, lowering the level of sophistication means lowering the amount of features, which is bad. But if you'd like us to just use the widgets from Completion-UI (and maybe some code related to customizing them?), that would be okay, although I'd have to look into fitting any of them inside the Company's interaction with the command loop, or rewrite it somehow. > Company does *much* more than this. It's practically a way of life :) It's not hard to describe Company in the same terms: it's a framework designed to fetch completion candidates from the configured backends and allow selecting between them in the configured frontends. The "show documentation" and "show definition" actions are small bonus features, as far as complexity of implementation goes. > 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. Company front-ends are not independent widgets, indeed. They don't encapsulate data, instead using the same buffer-local vars Company operates with. And the popup code is a relatively small part of the package, so "switching to Company" really means writing a backend for it, in this case. I wonder which part of the backend API you didn't like. > Maybe that's changed now. > Though I still can't seem to see a generic UI package separate from the > rest of company-mode. No one's requested it, so far. There's the popular popup.el, and there's dropdown-list.el of unclear providence on EmacsWiki which Yasnippet uses optionally. I've been thinking about splitting the Company popup code properly, but being able to reuse (and contribute to) the popular option which is popup.el would be better. > 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, Nope. > which is great! But I didn't want to force people to use company-mode in > order to use my predictive package. The usual way to go about it is to have a core package (maybe using completion-at-point-functions) and a couple of integrations with the popular completion packages. > I just wanted to provide simple UIs > for displaying and selecting completions. I'd wager Predictive would have a better adoption if it wasn't coupled to a yet-another completion package. I, for one, don't even consider using it for this reason. Although maybe I'm just not the target audience. > 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. Would you like to propose an API for it? Same as popup.el? > 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. It sounds good as an abstract idea, but I'd like to see a more specific proposal. >> 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. Sorry, I took it to mean that in Completion-UI you can configure user-interfaces per completion source, which is probably not the case. The user can of course configure the used front-ends in Company, by customizing the global `company-frontends' value (as opposed to buffer-local ones I mentioned above). > 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.) The browser sounds useful, I'll have to look into it. A mouse-only menu won't fit Company because it won't work for idle completion, as I mentioned elsewhere in this thread, and we generally want to provide a consistent keyboard interface. There'll also be issues with implementation related to that. >>> - 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. Sorry. I was aiming for cute rather than aggressive. > You still need some way to tell Company about the new > UI, so that it knows to invoke it. Actually, no. After defining the backend function with `defun', the user will need to add it to `company-backends', but that's not much different from them having to customize `auto-completion-source' in Completion-UI. > 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? Of course I would. But a) you don't own the popup code, which we would like to use, b) it could be hard to augment Completion-UI widgets with new commands, such as, for example, which using Company you can currently press `f1' when the popup is active to pop up the documentation buffer, or `C-w' to see the function source. How hard would it be? > > 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. Yes, sure. Would someone maybe submit an initial proposal?