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: completing-read enhancement Date: Sun, 16 Aug 2009 01:04:44 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250399105 24768 80.91.229.12 (16 Aug 2009 05:05:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Aug 2009 05:05:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Landes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 16 07:04:58 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1McXvO-0006tF-3n for ged-emacs-devel@m.gmane.org; Sun, 16 Aug 2009 07:04:58 +0200 Original-Received: from localhost ([127.0.0.1]:55763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1McXvN-0004YY-JF for ged-emacs-devel@m.gmane.org; Sun, 16 Aug 2009 01:04:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1McXvH-0004YA-Bw for emacs-devel@gnu.org; Sun, 16 Aug 2009 01:04:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1McXvC-0004U0-KP for emacs-devel@gnu.org; Sun, 16 Aug 2009 01:04:50 -0400 Original-Received: from [199.232.76.173] (port=54487 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1McXvC-0004TZ-Am for emacs-devel@gnu.org; Sun, 16 Aug 2009 01:04:46 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:60527 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1McXvB-0002ZG-TU for emacs-devel@gnu.org; Sun, 16 Aug 2009 01:04:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAJYwh0pFpZNo/2dsb2JhbACBUs9LhBkFh0g X-IronPort-AV: E=Sophos;i="4.43,389,1246852800"; d="scan'208";a="43621319" Original-Received: from 69-165-147-104.dsl.teksavvy.com (HELO ceviche.home) ([69.165.147.104]) by ironport2-out.teksavvy.com with ESMTP; 16 Aug 2009 01:04:17 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 9E8017801D; Sun, 16 Aug 2009 01:04:44 -0400 (EDT) In-Reply-To: (Paul Landes's message of "Wed, 12 Aug 2009 01:57:39 +0000 (UTC)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114290 Archived-At: >> > This isn't a patch to completing-read, instead it is a new function. >> > I think of it more as a facade with bells and whistles. In summary, >> > it makes prompting for user input easy requiring terse, in the context >> > of a function invocation, code for this purpose. >> >> Could you describe how it relates to completing-read (i.e. how it >> differs, mostly; both from the point of view of the user, and from the >> point of view of the coder)? > The read-completing-choice uses completing-read and doesn't intend to > supplant it. I understand, yes, that's fine. > To the developer, it offers a quicker way of prompting the user purely > based on a list of choices (either symbols or strings) and. > It adds the following features: > - accepts either symbols or string as input and converts between type > automatically > - returns user input as either a symbol or string When/why are these useful? > - when the size of the list is one, the initial input is the car of the list As a convention in Emacs, we usually prefer to start with an empty input (and rely on the "use default if the result is the empty string"), so I don't think this is something we want to encourage. > - renders default formatting (i.e. "File" -> "File (default subst.el): ") This is good. > - optionally allows for empty data Could you say something more about this. E.g. why you came up with it, in which situations did you find it useful/needed, ... > To the user, it provides a quicker (for most cases) way to select from > the list of choices (i.e. by populating the initial data from the > choices passed or by adding a default). IIUC, the initial data is built by (try-completion "" choices), right? It might make sense when require-match is set, but ho often does it return something else than ""? As for "adding default", I don't find in the code where/how this is done, could you explain what you mean by that? One problem with your function is that it has even more arguments than completing-read (which already has too many). Stefan PS: BTW, (try-completion "" choices) should also work just fine for the singleton case.