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: Mon, 17 Aug 2009 10:54:17 -0400 Message-ID: References: <19080.30520.886412.850420@leaf.lop> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250520882 3206 80.91.229.12 (17 Aug 2009 14:54:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Aug 2009 14:54:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: landes@mailc.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 17 16:54:35 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 1Md3bU-0003Bj-00 for ged-emacs-devel@m.gmane.org; Mon, 17 Aug 2009 16:54:32 +0200 Original-Received: from localhost ([127.0.0.1]:60755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Md3bT-0004DV-EF for ged-emacs-devel@m.gmane.org; Mon, 17 Aug 2009 10:54:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Md3bN-0004D0-LJ for emacs-devel@gnu.org; Mon, 17 Aug 2009 10:54:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Md3bJ-0004Bd-0U for emacs-devel@gnu.org; Mon, 17 Aug 2009 10:54:25 -0400 Original-Received: from [199.232.76.173] (port=43762 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Md3bI-0004BV-SU for emacs-devel@gnu.org; Mon, 17 Aug 2009 10:54:20 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:20826 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Md3bI-00054F-8I for emacs-devel@gnu.org; Mon, 17 Aug 2009 10:54:20 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAF8MiUpFpZNo/2dsb2JhbACBUtUChBkFh0k X-IronPort-AV: E=Sophos;i="4.43,396,1246852800"; d="scan'208";a="43659156" Original-Received: from 69-165-147-104.dsl.teksavvy.com (HELO pastel.home) ([69.165.147.104]) by ironport2-out.teksavvy.com with ESMTP; 17 Aug 2009 10:53:47 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id B772882F0; Mon, 17 Aug 2009 10:54:17 -0400 (EDT) In-Reply-To: <19080.30520.886412.850420@leaf.lop> (Paul Landes's message of "Sun, 16 Aug 2009 16:16:40 -0500") 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:114341 Archived-At: >> > 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? > For the former: anytime you want a discrete set of branches in a > function and don't want to convert using a lot of `intern' and > `symbol-name' calls. I figured this part ;-) What I meant is: how often does this happen for you. My impression is that it's not very frequent, but maybe you've seen it at many different places. >> 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. > Is this a new convention? No, not at all. It dates back to the introduction of the `def' argument to completing-read. > Seems I've run across many functions that > allow it (including `completing-read'). We definitely allow and support it because it is occasionally good. But we generally discourage its use. > What's the alternative to when it's useful to start with text to edit > rather than creating this text from scratch? Usually we provide the value in `def' and let the user hit M-n if she wants to edit the default. > This is tangential, but I've actually recently looked for a GNU Emacs > style guide but haven't found anything with the exception of the elisp > manual. Is there one? If so, I'd like to read up on this (and other > things concerning style). There is no such style guide that I know. We have some coding conventions in the Elisp manual, but it's about as far as it goes. If someone wants to start adding a "UI style guide" section, we'd be happy to install it. >> As for "adding default", I don't find in the code where/how this is done, >> could you explain what you mean by that? > I meant adding the default parameter to the function. I do not understand what you mean. >> One problem with your function is that it has even more arguments than >> completing-read (which already has too many). > I agree, it has a lot of parameters that are passed to it, but no more > that are required than `completing-read'. Only the first two are > required and most use cases won't require more than three or maybe > four. The problem is not the length of the compulsory parameters, but the overall length. Stefan