[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
- Re: CSV parsing and other issues (Re: LC_NUMERIC),
Boruch Baum <=
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/07
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Boruch Baum, 2021/06/07
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/07
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Stefan Monnier, 2021/06/08
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Maxim Nikulin, 2021/06/08
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/08
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Maxim Nikulin, 2021/06/10
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/10
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Boruch Baum, 2021/06/10
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/10