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: Mon, 16 Dec 2013 21:10:02 -0500 Message-ID: References: <87fvqtg02v.fsf@flea.lifelogs.com> <877gc5fm30.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387246224 1143 80.91.229.3 (17 Dec 2013 02:10:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Dec 2013 02:10:24 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 17 03:10:29 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 1Vsk79-0002lM-UH for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 03:10:28 +0100 Original-Received: from localhost ([::1]:59327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsk79-0003zy-C8 for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2013 21:10:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41989) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsk6x-0003yo-SI for emacs-devel@gnu.org; Mon, 16 Dec 2013 21:10:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vsk6p-0007wK-6e for emacs-devel@gnu.org; Mon, 16 Dec 2013 21:10:15 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:60402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsk6p-0007vP-0Q for emacs-devel@gnu.org; Mon, 16 Dec 2013 21:10:07 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.DIT.UMontreal.CA (8.14.1/8.14.1) with ESMTP id rBH2A3bA008493; Mon, 16 Dec 2013 21:10:04 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id DD571AE2BE; Mon, 16 Dec 2013 21:10:02 -0500 (EST) In-Reply-To: <87haa8moh6.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Mon, 16 Dec 2013 17:15:49 -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 RV4794=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4794> : inlines <330> : streams <1092012> : uri <1626308> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:166532 Archived-At: > I am trying to say that Emacs itself, outside of the > window/frame/etc. logic, should have code to "show a list of choices and > pick one." An API to list selection, from the minibuffer or from a > buffer, with consistent key bindings and no dependence on the context in > which it was invoked. This seems to be what `widget-choose' could do > with some polish, and that's where I'd put effort. Do you agree? I could agree, but do note that one of the main design goals of completion-in-region-mode was that the mode is exited as a side-effect of the user's normal editing. IOW, the user is free to ignore the list of completions and do whatever else she wants to do, rather than having to somehow indicate explicitly "oh, never mind, I won't choose any of these options". But IIUC the "choice" API you suggest would allow something like completion-in-region-mode as one possible UI. > To me, It seems crazy that there is no standard way to do this and > that so many packages, internal and external, have invented their own > UI to do it. There is one, which is completing-read. But this one size doesn't fit all. Maybe there is some other one size which does, but maybe not. Stefan