From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: i18n/l10n summary Date: Thu, 01 Jun 2017 08:17:37 +0000 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113ad7b815a80b0550e1ac02" X-Trace: blaine.gmane.org 1496305079 1065 195.159.176.226 (1 Jun 2017 08:17:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Jun 2017 08:17:59 +0000 (UTC) To: Paul Eggert , Jean-Christophe Helary , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 01 10:17:52 2017 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 1dGLIm-0008IB-BX for ged-emacs-devel@m.gmane.org; Thu, 01 Jun 2017 10:17:52 +0200 Original-Received: from localhost ([::1]:35956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGLIr-0005IC-DT for ged-emacs-devel@m.gmane.org; Thu, 01 Jun 2017 04:17:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGLIk-0005B4-FY for emacs-devel@gnu.org; Thu, 01 Jun 2017 04:17:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGLIj-00027g-BZ for emacs-devel@gnu.org; Thu, 01 Jun 2017 04:17:50 -0400 Original-Received: from mail-oi0-x235.google.com ([2607:f8b0:4003:c06::235]:34117) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGLIj-00027K-6R for emacs-devel@gnu.org; Thu, 01 Jun 2017 04:17:49 -0400 Original-Received: by mail-oi0-x235.google.com with SMTP id o65so20402125oif.1 for ; Thu, 01 Jun 2017 01:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JSrZ4uFYlC1nndqjcc3h51w5JCSwQtGAVoNfgZ73z5I=; b=mOYxf9x5krVI7QYz9x01kuBsxIg8R11kDOqo3G93dMf3JS25SMBdjH3lN3E50FgYdW 8DDRTxv6FRp7T8kMvzOPY0IjDMJwfHbFogqRuotPgp+Hv04lk22UoUqV1SRlAeh/nRYo PFlFDhg9W+2tpcNFnsHEqLVB2Qj1wEa/Y+t0BPPsh+mnHx/Q2mipcB9yHmonF4I2mDWt 5kx0jqtuAdiha+5tkMb6oAca2ZqbHw+wLK5v4kjgW6jjhY5f/KMpAao3Zd2wSZZDVqfR fkeh7/k504U75YNGof9NrPhAzAa7tIMzztMZYYcXyJnBYVU37O97ZeIeTpfd53ZtlnF6 PDjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JSrZ4uFYlC1nndqjcc3h51w5JCSwQtGAVoNfgZ73z5I=; b=Q0KacPnonNSvgesMsUEKkmHsG7FZiY+rdS5jEnKSekYPckJxRrtdV/nuRjSHaqK0Th RysKGozn8LyRvrJXFxOjq+24ogPED+VRsEsTTvnaYJViydubO9cHo+qkJmW3BO/ttItC LZVGASdi21gLYtVpMg2GEf6LpKmbDLafC+g6MSHtvRdKZmF/TpR9VALGLV3mxkRGysLy b+ePRPpTh9dzkqDFC3Z87iIsdQ55SGCn7WMxdcNCnzJQ/l2FKyQh2JaQdCQadmqb6bsC cMdz3pre5R1OeDeUnnfN/2A3ZR3U0zlQ6Y6gVuS/r+lq+47HLXM61k7KZw8m6o8G2Mnq 1Wzg== X-Gm-Message-State: AODbwcC+3cyccHVhmMCep6eiJqW+X8omrVmm5zgp1rkoUvsoUUyXeYsE WdRDgYKFrH5tKpSMhqNU2qD0vrXwLw== X-Received: by 10.202.87.76 with SMTP id l73mr112527oib.191.1496305068514; Thu, 01 Jun 2017 01:17:48 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::235 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:215381 Archived-At: --001a113ad7b815a80b0550e1ac02 Content-Type: text/plain; charset="UTF-8" Paul Eggert schrieb am Do., 1. Juni 2017 um 07:18 Uhr: > Thanks for that patch: it's a good move forward for i18n. Some suggestions: > > * Today I fixed the bug with "%%" and the 'error' function, so there's no > need > for a FIXME or a workaround any more. > > * In strings.texi, reorder the format spec description so that it matches > the > textual order of a format spec. This should lessen confusion. > > * Allow field numbers in a %% spec. All other components of a format spec > are > allowed in %%, so odd to report an error for just field numbers. > The reason I banned that initially is that the behavior for the case "%1$% %d" is confusing: will the %d take argument 1 or 2? (We should ban such mixing instead, see below.) > > * There is no need for a special diagnostic for field numbers greater than > PTRDIFF_MAX. Just use the same diagnostic other too-large field numbers > use. > This avoids a need for an alloca. > > * Reword "Invalid field number `0'" to "Invalid format field number 0" to > make > it more obvious that it's a format and there's no need to quote the 0. > > Proposed further patch attached (it addresses the above points), along > with a > copy of your patch rebased to current master for convenience. > Thanks, feel free to push. Two further things: - Probably there's a bug lurking because the info[n] ought to be indexed by specification index, not argument index. Something like (format "%1$c %1$d" ?a) will probably do the wrong thing (untested). - We should ban mixing explicit and implicit field numbers, like POSIX printf(3) does. The gain from allowing to mix is negligible, and it makes the implementation and the documentation needlessly complex. --001a113ad7b815a80b0550e1ac02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Do., 1. Juni 2017 um 07:18=C2=A0Uhr:
Thanks for that patch: it's a good move forward for i18n.= Some suggestions:

* Today I fixed the bug with "%%" and the 'error' functio= n, so there's no need
for a FIXME or a workaround any more.

* In strings.texi, reorder the format spec description so that it matches t= he
textual order of a format spec. This should lessen confusion.

* Allow field numbers in a %% spec. All other components of a format spec a= re
allowed in %%, so odd to report an error for just field numbers.

The reason I banned that initially is that the be= havior for the case "%1$% %d" is confusing: will the %d take argu= ment 1 or 2? (We should ban such mixing instead, see below.)
=C2= =A0

* There is no need for a special diagnostic for field numbers greater than<= br> PTRDIFF_MAX. Just use the same diagnostic other too-large field numbers use= .
This avoids a need for an alloca.

* Reword "Invalid field number `0'" to "Invalid format f= ield number 0" to make
it more obvious that it's a format and there's no need to quote the= 0.

Proposed further patch attached (it addresses the above points), along with= a
copy of your patch rebased to current master for convenience.

Thanks, feel free to push.

= Two further things:
- Probably there's a bug lurking because = the info[n] ought to be indexed by specification index, not argument index.= Something like (format "%1$c %1$d" ?a) will probably do the wron= g thing (untested).
- We should ban mixing explicit and implicit = field numbers, like POSIX printf(3) does. The gain from allowing to mix is = negligible, and it makes the implementation and the documentation needlessl= y complex.
--001a113ad7b815a80b0550e1ac02--