emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CSV parsing and other issues (Re: LC_NUMERIC)


From: Boruch Baum
Subject: Re: CSV parsing and other issues (Re: LC_NUMERIC)
Date: Sun, 6 Jun 2021 19:36:38 -0400
User-agent: NeoMutt/20180716

I wasn't cc'ed (and I don't subscribe to the list), so I only now saw
the continuation of my post.

1] @Maxim: You seemed to indicate that the default emacs locale is 'C'.
   That may be true, and I may be mixing up two separate things, but my
   observation is that I get 'nil' when I check for any related
   environment variable using function `getenv', and in practice I need
   to temporarily manually use function setenv to set LC_COLLATE=C in
   order to offer several sorting options in package diredc. Note though
   that feature isn't performing the sort within emacs; it's temporarily
   setting a shell environment and having the external ls program
   perform the sort for emacs-core dired. Thus, my experience has been
   that the default has been something other than C, at least for
   LC_COLLATE. I suspect that's true for ALL emacs users.

2] @Eli: You wrote

> > The problem with that, of course, is that not every supported
> > platform can dynamically change the locale, let alone do that
> > efficiently.

   I have no idea to what actual supported platform you're referring.

3] @ELi: Your wrote

> > Text processing in Emacs is generally separate from the current
> > locale's rules,
> > ...
> > 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

   Agreed. My input here is that there should be clear documentation of
   how to retrieve a value for that argument from a buffer's context,
   (maybe the same way that flyspell does?).

I see also that I created room for confusion in asking actually for TWO
features (single-quote and upper-case I) because the two will behave
differently in an expected default condition. The single quote format
(for the thousands separator) can be expected to produce a result always
for all conditions of locale, while I expect most locale cases won't
produce any special output for the upper-case I format option.


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0



reply via email to

[Prev in Thread] Current Thread [Next in Thread]