From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id A4XbNK4Qu2K9KAgAWB0awg (envelope-from ) for ; Tue, 28 Jun 2022 10:31:10 -0400 Received: by simark.ca (Postfix, from userid 112) id C8B701E22B; Tue, 28 Jun 2022 10:31:10 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=yaLiUYg4; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED 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 701C61E222 for ; Tue, 28 Jun 2022 10:31:10 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6AE45390371A for ; Tue, 28 Jun 2022 14:31:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6AE45390371A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1656426660; bh=qW+WEbApRsTA8yS1tD1zINRkubF+UDjyDuDaXTFeJvE=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=yaLiUYg4qHsAamuZxLGE+DjRvvY9GsVGjaaFu1qRSVS4hdSeK9hdnAQG4yKqp6eBh 8RVMTnu3zx0OFuSnEz8UC42dBWg/rCSjJjOmLFfu7lxfKjWpYLPih4X226U4xpDD23 spnqFAulOeWQUHWSX8c3L23tI4yDbWqkIuET/Ny0= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 780FC382FE4B for ; Tue, 28 Jun 2022 12:11:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 780FC382FE4B Received: from fencepost.gnu.org ([2001:470:142:3::e]:57588) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6A1x-0003t7-2P; Tue, 28 Jun 2022 08:09:21 -0400 Received: from [87.69.77.57] (port=3153 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6A1w-0005lB-E0; Tue, 28 Jun 2022 08:09:20 -0400 Date: Tue, 28 Jun 2022 15:09:24 +0300 Message-Id: <83pmit6lcb.fsf@gnu.org> To: Pedro Alves In-Reply-To: (message from Pedro Alves on Mon, 27 Jun 2022 20:15:17 +0100) Subject: Re: [PATCH 2/4] gdb, gdbserver: Add AMX registers. 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> 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: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > 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. 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. > (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).