Date: Sat, 25 Jul 2026 17:05:47 +0200
From: "[email protected]" <[email protected]>
Message-ID:
<ambp191mb2886c6c26935be13d77fe57dce...@ambp191mb2886.eurp191.prod.outlook.com>
| The US-legislation joke, first, because it cuts the other way
No, it doesn't - the only reason for that "joke" was to make it
clear that nothing about what will happen in the future can be
guaranteed, your:
| this patch instead uses the locale-independent UAX #31 set
| with an NFC guarantee
from the original message (repeated in different contexts, I think)
is meaningless. There is no such thing as an NFC guarantee.
| Load the table at startup / generate at build time
| --------------------------------------------------
| I kept the generated header in the tree rather than generating
| unconditionally during build,
For me, that compromise (assuming any of this is ever accepted) would be
fine.
| A runtime-loadable external table I'd push back on, though, and the
| reason is this feature specifically. The whole security argument for
| UAX #31 + NFC -- byte equality is identity, no invisibles, no
| unreviewable names -- evaporates if the accepted set becomes
| site-editable data:
You seem to fail to understand that *everything* about bash is site-editable
data - any open source project is, that's the whole point of their existence.
So:
| now every host can define its own notion of a valid name,
As they can now. After all, that is exactly what you're proposing
in your patch, and I'm quite sure you've tried the result locally.
You have defined your own notion of a valid name in your local bash
(whether or not you have installed it as your system's bash.)
As it is very unlikely any of this will ever happen, that's most
probably where it will remain, a local host's private definition
of what is a valid name.
| SARA AM -- you found a real thing, but it isn't a generator bug
I never claimed that any of what I'm objecting to are generator bugs.
| SARA AM has XID_Start=false in the UCD itself,
So? Why is that prescriptive?
| The reason is mechanical -- it has a canonical decomposition
| (to U+0E4D + U+0E32),
I doubt anyone would write it that way, ever, as I suspect that isn't
a genuine equality, just an approximation. The E32 part would be OK,
but I'm not sure an E4D (which combines normally with the attached
consonant, not the subsequent vowell) would always end up positioned
correctly to properly form SARA AM (it might never be correct).
But I am certainly no expert (not even close) at correct representations
of Thai text.
| and characters that decompose that way are kept
| out of XID_Start so that identifier identity survives normalization.
But it isn't just XID_Start, it is excluded completely from your tables.
The effect of that is that lots of perfectly sane Thai words can't be
used as variable names in your proposal (using SARA AM as the lead in
character would be rare - probably would only occur if that were the
entire variable name, except perhaps in the case that variable names are
being generated on the fly - but as a subsequent character it is quite
common.) Excluding 0xe4d would be less objectionable, it is one of the
less frequently seen characters, but you don't do that, so you kind of
allow a poor approximation of SARA AM as a non-starting character, but
not the real thing. That's very poor.
| So it's excluded, but by Unicode, and for the NFC-identity reason that is
| the spine of this whole patch, not arbitrarily.
Deciding upon the criteria you picked is arbitrary. That other languages
have done that is irrelevant, that some other shells have made the same
mistake you're proposing (though you suggest few have) is unfortunate,
but also irrelevant - but if you wanted to be compatible with anything,
pick other shells over other languages.
| Same mechanism, inverted,
| is why it *is* a valid continuation character.
The "it" there is SARA AM, right (0x0e33)? But:
+ { 0x00E01, 0x00E30, 3, 0 }, { 0x00E31, 0x00E31, 2, 0 },
+ { 0x00E32, 0x00E32, 3, 0 }, { 0x00E34, 0x00E37, 2, 0 },
+ { 0x00E38, 0x00E39, 2, 103 }, { 0x00E3A, 0x00E3A, 2, 9 },
where exactly is E33 in there? If it isn't there, how is it valid?
| Where I'd correct the framing: this isn't my design choice, it's UAX #31's
But it was your choice to use that profile.
| XID_Start, which is letters (L*) plus a few Nl, and excludes the nonspacing
| combining marks (Mn) as *starters* precisely because a name beginning with
| a combining mark has nothing to combine onto -- it would render as a
| dotted circle.
That entirely depends upon the nature of the layout. It is perfectly
normal to show SARA I (or SARA U etc) alone, if one is discussing the
way to draw it (its shape, etc). It certainly can't be in a Thai word
alone, but we're not making Thai words here, any more than any bash
identifiers are expected to be words of any language (words can be used,
but there's no restriction that says identifiers need to be valid language
words).
| SARA I is a dependent vowel: in Thai text it never begins
| a cluster, it attaches above a preceding consonant.
It does indeed. All Thai vowels must be attached to a consonant, including
those that precede their consonant (and so, in Thai, are entered first -- in
some other related languages even their vowels that are formatted ahead of
the consonant follow it as typed in a file/document.)
If what makes sense in Thai (or any other language) were what mattered here,
then Sara
| That is not Latin chauvinism in my table;
But it is. That you have copied the chauvinism from others who
have also adopted it means nothing. Wrong is wrong, and if you choose
to adopt it, then ....
| and diverging from it means bash alone disagrees with
| every other language about what a Thai identifier is.
Thai identifiers have nothing whatever to do with it. It is bash
identifiers that are being discussed here, and that bash disagrees
with anything else about what a bash identifier should be would just
illustrate that the anything else should be minding its own business.
I doubt this discussion is worth continuing.
kre
