Re: [PATCH 2/4] gdb, gdbserver: Add AMX registers.

[Pedro Alves <pedro@palves.net>]

On 2022-06-28 13:09, Eli Zaretskii wrote:
>> Date: Mon, 27 Jun 2022 20:15:17 +0100
>> Cc: felix.willgerodt@intel.com, gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>>
>> Given the manual is written in US English, I wonder why we let locale influence
>> sorting order.  I mean, shouldn't we be forcing locale to LANC=C or some such when
>> generating the manual, to be sure the sections are always sorted the same way?
> 
> Doing this means we cannot include any non-ASCII text in the manual,
> ever.  Not even mention names of people whose names include non-ASCII
> characters.
> 

Are you sure?  I hacked in some non-ASCII characters, and did:

 cd gdb/doc
 LANG=C make
 LANG=C make html
 
and the non-ASCII characters were not lost, in either the texinfo manual nor the
html manual.

I also tried LC_COLLATE=C, LC_ALL=C.

> Also, I think doing that means the Unicode characters produced by
> makeinfo from the likes of @result, @print, @error, etc. will be
> replaced by their ASCII equivalents -- do we really want that?
> 
> In sum, this would be an unusual thing to do, as GNU manuals go.
> There is actually in recent years an urge to produce UTF-8 encoded
> manuals, not go back to plain ASCII.

That was just an example, I did say "or some such".  Could be LANG=C.UTF8 instead,
or LC_COLLATE=en_US.UTF-8, or some other setting, maybe even some texinfo flag
or something.  I don't know what influences texinfo's sorting behavior exactly.

Actually, I am surprised that LANG/LC_COLLATE/LC_ALL=C doesn't make the cindex
entries sort uppercase before lowercase.  I wonder what else one needs to do
to reproduce such an order without resorting to custom collations.

> 
>> (At least the html manual sorts the concept index ignoring case for me, and I see
>> the same in the docs copy in the gdb website, so I assume that's the order we want.)
> 
> The purpose of this convention to let everyone produce a manual with
> the same order, regardless of the locale in which the manual is
> produced.  That manuals on the site, which are produced in en_US, do
> TRT doesn't surprise me at all...
> 
> The burden in practice is not too heavy, since only a handful of our
> index entries use company names (or any proper names, for that matter).
> 

In the case at and, it forced the prepending of "Intel" to the name, so
someone that wouldn't find "Advanced" because they were looking for it
near the lowercase "a..." entries won't find it either.  It just seems a
little weird to me, to not be able to use uppercase in acronyms, since they
are names.  But as you say, it's not much of a burden, assuming we can
find some prefix word, like "Intel".  Myself, I don't think I actually read the index
entries sequentially, ever -- I instead hit the search function in the browser and type
what I'm looking for, so whether "advanced" is the first word or the second, doesn't
really matter.  I guess it might matter more for printed versions of the manual.  But
then in such case, I don't know whether I'd remember to look up under "Intel" rather
than "Advanced", and would probably end up just skimming the whole cindex for AMX.

Anyhow...  Thanks for the clarifications.