From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FWF4GngRu2IRKQgAWB0awg (envelope-from ) for ; Tue, 28 Jun 2022 10:34:32 -0400 Received: by simark.ca (Postfix, from userid 112) id 5C6201E22B; Tue, 28 Jun 2022 10:34:32 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A37D21E222 for ; Tue, 28 Jun 2022 10:34:31 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 685F4396BADD for ; Tue, 28 Jun 2022 14:34:05 +0000 (GMT) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by sourceware.org (Postfix) with ESMTPS id CA1303895FEE for ; Tue, 28 Jun 2022 13:35:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA1303895FEE Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f50.google.com with SMTP id n1so17707333wrg.12 for ; Tue, 28 Jun 2022 06:35:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=jIlWA/arWxV+Ud/DNZTcAZKjKJ1XoXZkEsLLscGbZo0=; b=HpiCy8smjPOD84xeTTTr7zbQXwGzkaYSAu8KZieRIkIfHhFSgIdZ5h2ObBxevQ6KRI 97htEAIekDVt5TytZeDa60kT4ylaEldsHItSY8XPj/G5p0NEKzbsjRBZgE2o05QBi2ww Jy5sEb4l3Zv28ybMVZKWmdE7Mtk1NCv0CHMREOTsp1B1gQ2jkl7nH5xJTdD2u7rKKsLV Xc1w4zJfvcm9mfy+XmVmcSjZjYjyQNZyUoO8s2xQqL2ZG7M4clDmgDkWlF8bsmh875q9 3XC+f+gD7zE4ExEBf2NCYBXpBLbo7jP/q8nWmLbVOkk6PDEh5CVppwLMkOrB//0VjyWL 4lCg== X-Gm-Message-State: AJIora/T8XLCODtEJyiXs0pyx/PxFtQUXOITYJBW8sWkwRa0BbEijzgg 9vY9HcJ0r1icY8/5aL7sZpM= X-Google-Smtp-Source: AGRyM1tjGqquVXhFW98Piyd6xadR8K+epKnZTFAa3nkJcOel2wWi0NTHGPAmtHwVUJHRyIJEi10rHw== X-Received: by 2002:adf:fb46:0:b0:210:2316:dd02 with SMTP id c6-20020adffb46000000b002102316dd02mr18420928wrs.557.1656423331596; Tue, 28 Jun 2022 06:35:31 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id y5-20020a5d6145000000b0020cdcb0efa2sm13755764wrt.34.2022.06.28.06.35.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jun 2022 06:35:30 -0700 (PDT) Message-ID: <5eacf6cc-c8b8-5b04-a53c-7b2bb0aef5d1@palves.net> Date: Tue, 28 Jun 2022 14:35:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 2/4] gdb, gdbserver: Add AMX registers. Content-Language: en-US To: Eli Zaretskii References: <20220506121226.137608-1-felix.willgerodt@intel.com> <20220506121226.137608-3-felix.willgerodt@intel.com> <834k2226ht.fsf@gnu.org> <834k1ws3d3.fsf@gnu.org> <83y1xi6k22.fsf@gnu.org> <83pmit6lcb.fsf@gnu.org> From: Pedro Alves In-Reply-To: <83pmit6lcb.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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 >> >> 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.