From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: CSV parsing and other issues (Re: LC_NUMERIC) Date: Fri, 11 Jun 2021 09:19:43 +0300 Message-ID: <83v96kapog.fsf@gnu.org> References: <20210608004510.usj7rw2i6tmx6qnw@E15-2016.optimum.net> <83h7i9f5ij.fsf@gnu.org> <73df2202-081b-5e50-677d-e4498b6782d4@gmail.com> <83eedcdw8k.fsf@gnu.org> <83lf7hbqte.fsf@gnu.org> <20210610180145.staexpqsmqpiv44c@E15-2016.optimum.net> <83a6nxbllz.fsf@gnu.org> <20210610190453.gaq5pqlfbvy4zwmp@E15-2016.optimum.net> <837dj1bk1k.fsf@gnu.org> <20210610202045.4b42osqejx66pb6p@E15-2016.optimum.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2567"; mail-complaints-to="usenet@ciao.gmane.io" Cc: manikulin@gmail.com, emacs-devel@gnu.org To: Boruch Baum Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 11 08:20:38 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lraWy-0000PX-Gm for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Jun 2021 08:20:36 +0200 Original-Received: from localhost ([::1]:57134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lraWx-00015e-3g for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Jun 2021 02:20:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lraWH-0000Mc-V1 for emacs-devel@gnu.org; Fri, 11 Jun 2021 02:19:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50414) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lraWH-0008MY-8A; Fri, 11 Jun 2021 02:19:53 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4141 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lraWG-0000jI-QV; Fri, 11 Jun 2021 02:19:53 -0400 In-Reply-To: <20210610202045.4b42osqejx66pb6p@E15-2016.optimum.net> (message from Boruch Baum on Thu, 10 Jun 2021 16:20:45 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270684 Archived-At: > Date: Thu, 10 Jun 2021 16:20:45 -0400 > From: Boruch Baum > Cc: manikulin@gmail.com, emacs-devel@gnu.org > > On 2021-06-10 22:23, Eli Zaretskii wrote: > > > Date: Thu, 10 Jun 2021 15:04:53 -0400 > > > From: Boruch Baum > > > Cc: manikulin@gmail.com, emacs-devel@gnu.org > > > > > > > That would make the output of 'format' dependent on the current > > > > locale > > > > > > That's the elisp programmer's business, not your responsibilty. > > > > What could the Lisp programmer do in this situation? > > It's not your responsibilty. It is my responsibility to make sure we don't add to Emacs features that are not very useful, or are against the Emacs philosophy and/or design principles. > I can say that in the use-case that prompted my request, I'm confident > it will *never* be an issue. I ask format to give me a string and I > display it. End of story. Whether just 99% or 99.99%, the overwhelming > majority of cases will be the same. Your concerns are total non-issues. You can always write a module to implement this feature, if you want it for your own purposes. Or you could change Emacs to support that directly and maintain that change locally. There's no need to introduce into Emacs features that are useful for a few people. > [Commentary: I see all format specifiers supported but the two > requested.] You are overlooking some aspects of the code if that is your conclusion. > > I don't think it's TRT for Emacs to expose locale-dependent features > > that cannot be controlled from Lisp > > Then don't make them locale specific. Implement the single-quote > specifier the same way you currently handle the floating-point specifier > '%f', a locale-specific format that has existed in emacs without > complaint since ... That was my suggestion, more or less. Patches are welcome to implement that.