From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: RFC: String interpolation Date: Mon, 12 Dec 2016 12:41:38 -0800 Organization: UCLA Computer Science Department Message-ID: <3ff9e7e4-aee7-191e-5e3b-4d4ac0006a1f@cs.ucla.edu> References: <51825111-ace4-f750-4077-026a3b648d27@gmail.com> <8737hwnc52.fsf@lifelogs.com> <8c117f5c-209a-97d8-79ce-a78f707f0545@gmail.com> <76c9c475-0180-aa49-3d4a-006d4e3f943c@gmail.com> <89a6a20d-e135-caad-6b31-760ab7ac90fc@cs.ucla.edu> <87fultkjte.fsf@lifelogs.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1481575317 10255 195.159.176.226 (12 Dec 2016 20:41:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Dec 2016 20:41:57 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Cc: Lars Ingebrigtsen To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 12 21:41:50 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cGXPy-0001nB-0N for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2016 21:41:50 +0100 Original-Received: from localhost ([::1]:33530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cGXQ2-0006Gd-6w for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2016 15:41:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cGXPs-0006FE-0Q for emacs-devel@gnu.org; Mon, 12 Dec 2016 15:41:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cGXPo-0002So-O3 for emacs-devel@gnu.org; Mon, 12 Dec 2016 15:41:43 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51314) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cGXPo-0002SN-IC for emacs-devel@gnu.org; Mon, 12 Dec 2016 15:41:40 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 54D5B160203; Mon, 12 Dec 2016 12:41:39 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id nInk9PfZcwIU; Mon, 12 Dec 2016 12:41:38 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 872281601FE; Mon, 12 Dec 2016 12:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id t00o1V5p-L4g; Mon, 12 Dec 2016 12:41:38 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 6E1501601FD; Mon, 12 Dec 2016 12:41:38 -0800 (PST) In-Reply-To: <87fultkjte.fsf@lifelogs.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:210372 Archived-At: On 12/12/2016 11:51 AM, Ted Zlatanov wrote: > I like how this separates expressions from strings. It might be more > readable if the % begins the next string: > > (format "Altitude= " alt "%.2f, direction = " dir "%.2f.") Unfortunately although this syntax is clean it would not be upward compatible, as 'format' currently silently discards excess trailing arguments. In contrast, Lars's suggestion: > (format "Altitude= %.2f%" alt ", direction = %.2f%" dir ".") is upward compatible. Also, I suspect that Lars's suggestion will be less error-prone than mine, as it would be more likely to diagnose stray occurrences of "%" at the end of a format. > It has some downsides: it only works in one function; `(apply 'format ...)` > can become surprising; and repeating a parameter requires duplicating > the code. True for repeating a nontrivial parameter. However, that is not common and 'let' should be good enough for that, e.g., (let ((dup (complicated expression))) (format "appearance1 = %f%" dup ", appearance2 = %g%." dup)). I'm not sure what is meant mean by 'only works in one function'. format-message should behave like 'format', and any function that calls 'format' or 'format-message' will get the extended behavior for free. For example, (message ...) would get the extended behavior. (apply 'format FMT ...) would not get the extended behavior unless FMT itself uses the extension, and this should be good enough to avoid most surprises. Ah, perhaps you're thinking about mixed forms like (format "x = %1d, y = %2d%" EX WYE ", z = %3d" ZEE)? To avoid confusion, the extension could work only if the format string has just one conversion specifier, at the end (just before the "%" at end of string). The idea would be to encourage people to write either the extended (format "x = %1d%" EX ", y = %2d%" WYE ", z = %3d%" ZEE) or the traditional (format "x = %1d, y = %2d, z = %3d" EX WYE ZEE) instead of trying to write a confusing mixture of the two.