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, 04 Jun 2021 22:17:24 +0300 Message-ID: <83lf7pl9rv.fsf@gnu.org> References: <20210602185441.nhvhirdffamahgfy@E15-2016.optimum.net> <921965d7-af86-6d2e-8b48-3d0b9b51998e@gmail.com> <83eedjvvps.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30708"; mail-complaints-to="usenet@ciao.gmane.io" Cc: utkarsh190601@gmail.com, emacs-devel@gnu.org To: Maxim Nikulin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 04 21:18:03 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 1lpFKU-0007qQ-OV for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 21:18:02 +0200 Original-Received: from localhost ([::1]:37950 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpFKT-0002zj-QP for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 15:18:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54416) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpFJz-00027C-FP for emacs-devel@gnu.org; Fri, 04 Jun 2021 15:17:31 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48020) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpFJy-0003ZR-Ov; Fri, 04 Jun 2021 15:17:31 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2261 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 1lpFJy-0007JW-BV; Fri, 04 Jun 2021 15:17:30 -0400 In-Reply-To: (message from Maxim Nikulin on Fri, 4 Jun 2021 23:31:13 +0700) 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:270400 Archived-At: > Cc: utkarsh190601@gmail.com > From: Maxim Nikulin > Date: Fri, 4 Jun 2021 23:31:13 +0700 > > > Setting a locale globally in Emacs is a non-starter, for the reasons > > that you point out and others. Text processing in Emacs is generally > > separate from the current locale's rules, mainly to have Emacs work > > the same in any locale. So passing a locale argument to functions > > that produce output, with the intent to request some behavior to be > > tailored to that locale, is the only reasonable way to have this kind > > of functionalities in Emacs. The problem with that, of course, is > > that not every supported platform can dynamically change the locale, > > let alone do that efficiently. > > I do not think it is efficient to require from users to fight with > number formatting themselves. I didn't suggest that. I was talking about the design of the APIs that need to be able to provide locale-specific formatting. The implementation should be provided by Emacs core, of course. > Do you mean that it is necessary to create new implementation of number > formatter specially for Emacs? Either that, or use the underlying C library if it can accept a locale specifier, or if it supports efficient dynamic change of the locale, like we do in some of the implementations of string-collate-lessp. > On linux I see that Emacs is linked with ICU It isn't. It's either HarfBuzz or maybe libc that pulls in the ICU library. Emacs doesn't use it directly. > Do you have a bright idea concerning implementation of parser-formatter > for numbers with reasonable efforts? See above.