[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CSV parsing and other issues (Re: LC_NUMERIC)
From: |
Eli Zaretskii |
Subject: |
Re: CSV parsing and other issues (Re: LC_NUMERIC) |
Date: |
Mon, 14 Jun 2021 20:19:31 +0300 |
> From: Maxim Nikulin <manikulin@gmail.com>
> Date: Mon, 14 Jun 2021 23:38:19 +0700
>
> >> You forgot `setlocale(LC_NUMERIC, "C")', didn't you?
> >
> > No, I didn't. Adding a call to setlocale to locale-info, even if we
> > want to add an argument for the caller to control the locale, is
> > trivial.
>
> I would avoid such manipulations and the reason is not efficiency of
> particular implementation.
But we already do that in locale-info, for locale categories other
than LC_NUMERIC.
> >> > Here's a trivial example:
> >> >
> >> > (insert (downcase (buffer-substring POS1 POS2)))
> >> >
> >> > Contrast with
> >> >
> >> > (insert (downcase "FOO"))
> >>
> >> Either `set-text-properties' should be called on "FOO" before passing it
> >> to `downcase'
> >
> > Which property will help here? we don't have such properties. they
> > need to be designed and implemented.
> Let's name it "locale". Its value is some object that represents either
> a "solid" locale such as de_DE or combined LC_NUMERIC=en_GB +
> LC_TIME=de_DE + default fr_FR. Data required for particular operations
> may be loaded on demand.
How do you associate such an object with text of a buffer or a string
such that different parts of the text could have different "locales"
(as required for a multi-lingual editor such as Emacs)?
> > How would you implement locale-downcase? Are you familiar with how
> > Emacs case tables work?
>
> No, I am not familiar with Emacs internals dealing with case conversion.
> I already wrote I am even unaware how to properly handle Turkish. For
> the scripts I am familiar with, it is enough to have default table for
> normalizing and conversion. I can admit that sometimes conversion may
> depend on language and the language can not be determined from code
> point. In such cases I expect additional override table that has higher
> priority than the default one.
>
> > And even if we had locale-downcase, which locale would you
> > pass to it in any given use case?
>
> I already mentioned responsibility chain: explicit value or set of
> overrides passed by user, text property for particular span of
> characters, buffer-local variables, global environment variables. Locale
> may be instantiated from its name "it_IT". Convenience functions to
> obtain locale at point likely will be useful as well. (Actually I am
> assuming number parsing-formatting rather than case conversion.)
What you describe doesn't exist, not even in its design stage. We are
back where we started: I said at the very beginning that this
infrastructure is missing. It is futile to discuss solutions which
rely on infrastructure that doesn't exist.
- Re: CSV parsing and other issues (Re: LC_NUMERIC), (continued)
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Filipp Gunbin, 2021/06/11
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/11
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Filipp Gunbin, 2021/06/11
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/11
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Maxim Nikulin, 2021/06/11
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/11
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Maxim Nikulin, 2021/06/14
- Re: CSV parsing and other issues (Re: LC_NUMERIC),
Eli Zaretskii <=
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Maxim Nikulin, 2021/06/16
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Eli Zaretskii, 2021/06/16
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Stefan Monnier, 2021/06/10
- Re: CSV parsing and other issues (Re: LC_NUMERIC), Maxim Nikulin, 2021/06/12