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: Tue, 17 Dec 2013 13:29:30 -0500 Message-ID: References: <87fvqtg02v.fsf@flea.lifelogs.com> <87k3g47m7b.fsf@yandex.ru> <528B6F11.7070607@yandex.ru> <87y54ke8v3.fsf@flea.lifelogs.com> <87li0kdrsz.fsf@flea.lifelogs.com> <878uwi8t3r.fsf@mail.jurta.org> <83ob5ee7ow.fsf@gnu.org> <87d2ltl2if.fsf@mail.jurta.org> <8338moevm3.fsf@gnu.org> <8761rkaa5e.fsf@flea.lifelogs.com> <87txf0390n.fsf@flea.lifelogs.com> <87y53komex.fsf@flea.lifelogs.com> <87haa8moh6.fsf@flea.lifelogs.com> <874n67n450.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387304992 8295 80.91.229.3 (17 Dec 2013 18:29:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Dec 2013 18:29:52 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 17 19:29:55 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 1VszP0-0007vI-Do for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 19:29:54 +0100 Original-Received: from localhost ([::1]:34916 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VszP0-0005jC-1E for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 13:29:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VszOp-0005Z6-E6 for emacs-devel@gnu.org; Tue, 17 Dec 2013 13:29:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VszOi-00038L-16 for emacs-devel@gnu.org; Tue, 17 Dec 2013 13:29:43 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:60112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VszOh-000388-MA for emacs-devel@gnu.org; Tue, 17 Dec 2013 13:29:35 -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 rBHITVVo022361; Tue, 17 Dec 2013 13:29:32 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 01768AE129; Tue, 17 Dec 2013 13:29:30 -0500 (EST) In-Reply-To: <874n67n450.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Tue, 17 Dec 2013 05:49:47 -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 RV4795=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4795> : inlines <333> : streams <1092417> : uri <1627033> 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:166555 Archived-At: > Yes, I understand. But this is at odds with the way that > `completing-read' and `widget-choose' and most modern UIs work. You mean it's feature that the other systems lack. Yes, agreed ;-) > The user has explicitly invoked a completion command, right? There's no doubt that it can be made more modal, but it's more convenient if the mode is exited seamlessly. Historically, TAB completion is non-mini buffers did not affect the subsequent behavior. This was a convenient feature with the downside that the *Completions* buffer was left around. So I wanted to fix this problem while preserving the property that the mode stays out of the way. > Right, it wouldn't care about the invocation context, the "dismiss on > input when called in a buffer context" behavior would be an option. For > those who like it, it can stay. I don't think it should be the default. I'm not sure why you see it as something the user wouldn't like. More specifically, why would you want to force the user to use special commands to leave the "completion choice mode"? I must be missing something. > `completing-read' moves the focus of the user from point to the > minibuffer IIUC, and then makes the entire interaction > minibuffer-centric. That seems to be the fundamental reason why we > invented `completion-in-region-mode', to avoid that context switch. Indeed, using completing-read to complete text from a normal buffer would be inconvenient (tho it's done occasionally). `completion-in-region' is a lot more lightweight for the user, staying out of the way as much as possible. > Otherwise yes, `completing-read' could be the list-selection API. I think "list-selection" is a restrictive way to think about it: hitting TAB to complete doesn't necessarily mean "the user wants to select a completion candidate". It can also mean "the user wants to complete "fo" to "fooba" and then complete this identifier by adding something else that's not in any of the completion candidates. > Could `completing-read' call `widget-choose' regardless of the > invocation point and show a graphical popup or a simple text buffer? > Even in the minibuffer I think that would look OK. We wouldn't use completing-read, for API reasons. But indeed, the minibuffer.el code is slowly moving towards using the same completion mechanism as in other buffers (completion-at-point). > Or maybe `completing-read' could be called for in-buffer completion if > the minibuffer could somehow be moved closer to point? Imagine if the > minibuffer could slide up to point during the completion (perhaps by > simply growing it upwards until it reaches point), then there wouldn't > be a disorienting focus switch. Ideally the entire minibuffer would > slide up and look the same otherwise, but that's probably going to be > hard to implement. Still very disruptive. Stefan