From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Sun, 22 Dec 2013 20:59:49 -0500 Message-ID: References: <87fvqtg02v.fsf@flea.lifelogs.com> <87y53komex.fsf@flea.lifelogs.com> <87haa8moh6.fsf@flea.lifelogs.com> <874n67n450.fsf@flea.lifelogs.com> <87eh5bkxca.fsf@flea.lifelogs.com> <87d2kuzzqj.fsf@uwakimon.sk.tsukuba.ac.jp> <87a9fylusq.fsf@flea.lifelogs.com> <878uvizrwz.fsf@uwakimon.sk.tsukuba.ac.jp> <8761qmkyn1.fsf@flea.lifelogs.com> <87zjnyxdpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k3f2j7xv.fsf@flea.lifelogs.com> <2518D79A-B9E4-45DF-A403-8330145DFD17@gmail.com> <87eh58j0x3.fsf@flea.lifelogs.com> <87mwjvfrfy.fsf@flea.lifelogs.com> <877gawbhp0.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387764007 10082 80.91.229.3 (23 Dec 2013 02:00:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Dec 2013 02:00:07 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 23 03:00:13 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 1VuuoT-0001O4-Lo for ged-emacs-devel@m.gmane.org; Mon, 23 Dec 2013 03:00:09 +0100 Original-Received: from localhost ([::1]:60013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuuoT-0001fC-BM for ged-emacs-devel@m.gmane.org; Sun, 22 Dec 2013 21:00:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuuoJ-0001aR-Bk for emacs-devel@gnu.org; Sun, 22 Dec 2013 21:00:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuuoC-0002oG-0U for emacs-devel@gnu.org; Sun, 22 Dec 2013 20:59:59 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:50139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuuoB-0002o9-R9 for emacs-devel@gnu.org; Sun, 22 Dec 2013 20:59:51 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id rBN1xlfZ022051; Sun, 22 Dec 2013 20:59:48 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 6C2E2AE25E; Sun, 22 Dec 2013 20:59:49 -0500 (EST) In-Reply-To: <877gawbhp0.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Sun, 22 Dec 2013 18:15:55 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4800=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4800> : inlines <347> : streams <1095425> : uri <1632516> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:166755 Archived-At: > I mean TAB (and its equivalent in-buffer keybinding) should be bound to > a single Elisp function, and the effect (list candidates, complete > immediately the single candidate, or cycle candidates depending on the > user preferences) should be consistent in any invocation context. Not sure what you feel is missing here. `completion-at-point' is basically it, AFAICT. But it's OK if different UIs provide other commands (or other ways, since completion can also happen as a side-effect of normal commands, as is the case with auto-complete and company-mode). The important point is that the completion command to use shouldn't depend on the "backend" (e.g. on the current major mode), and AFAIK we're almost there (the new completion code in Emacs-23 and subsequent bit-by-bit updates of major modes to make use of completion-at-point-functions was dedicated to this task). Can't remember what are the remaining exceptions, other than Eshell. SM> Hmm... Could you explain which parts are not consistent? > "Select with up/down" is not consistent between in-minibuffer and > in-buffer completion. AFAIK it is consistent: neither in minibuffer nor in in-buffer up/down is bound to a completion-related command. It's not what you want, but it's consistent w.r.t the completion UI. > You can always go into the *Completions* buffer and then use up/down, > but up/down immediately have different effects otherwise. Lots of other keys have different effects in minibuffers and normal buffers, but these don't make the completion code inconsistent in this respect. > I think they should do the same thing, enter a special popup > as Dmitry and I described. If/when those keys are given a completion-related meaning I'd expect it to be the same in both contexts, yes. > "Keep on editing" acts differently as well. Details? > OK, so do we agree on this specific improvement? "Whether in the > minibuffer or in a buffer, typing more characters should narrow the list > of candidates without having to press TAB or other special keys." If you add the qualifier "when the completion list is displayed", I think I agree, yes (I actually hesitated to add that feature when wrote the new minibuffer.el code, but then decided to keep it for later, sine there was plenty of other behavioral changes introduced at that time already). You might want to make it configurable, but I think enabling it by default would be OK. SM> Usually, if it works for in-buffer, it works as well in the SM> minibuffer case. > Good point. But why not simply enter an auto-narrowing popup in both > contexts? Didn't I just agree in the previous paragraph? > The user has explicitly requested completion, right? I keep > thinking that if in both contexts we locked the user into a selection > popup, the up/down and motion issues would be easily solved. It would > also allow `C-1' through `C-9' (or some similar keys) to be used to > immediately select a candidate by position, like `widget-choose' does it. As I already said in earlier discussions, it might very well be acceptable to hijack those keys. But only experience can confirm it. SM> I still don't quite understand what you want here. Are you thinking of SM> a function like x-popup-menu or display-completion-list? > Yes, `display-completion-list' but hacked to use `widget-choose' at > least in graphical mode and to auto-narrow. Here again you're confusing API and implementation. Be very careful, please, because it's making this discussion difficult. The API design should presumably make it possible to use company-mode's overlay-based popups, or widget-choose's popup, or good ol' *Completions* buffer. It should maybe also make it possible for the caller to provide some data that might influence which kind of popup to use (in case the kind of popup to use might depend on the context: not sure if that's really necessary), tho the ultimate choice should be with the user's config, of course. > This should work with (interactive) calls, of course, as a common > use case. I'm again lost here. We're talking about a *function* which needs to be told *by another Lisp function* what it is that needs to be displayed. So it's meaningless to consider interactive calls. > So let's say I'm inside gnutls.el and want to ask the user to select a > client certificate to present to the remote server. I have a list of 3 > such certificates. I would say `(display-completion-list > list-of-certificates)' and expect the result to be nil or an element of > the list. Does that usage make sense? No. That would seem to call for a completely different API meant to generalize completing-read rather than display-completion-list. Stefan