From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id XHaEJFNj2mP9JCcAWB0awg (envelope-from ) for ; Wed, 01 Feb 2023 08:04:19 -0500 Received: by simark.ca (Postfix, from userid 112) id 848691E128; Wed, 1 Feb 2023 08:04:19 -0500 (EST) 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=F+KRoGI6; 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=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 0BC8D1E110 for ; Wed, 1 Feb 2023 08:04:19 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2FBD13858C78 for ; Wed, 1 Feb 2023 13:04:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2FBD13858C78 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675256658; bh=tFEDJsdVLYwS1pDiJvsq0ZOESeF7gHmE0En7TaLfdig=; h=Date:To:Cc:In-Reply-To:Subject:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=F+KRoGI6xpCJfnzFLggUzyHK93kPOKpVWgoS1ONAglYNb+ec3n7717QD+Q4X9pOQe FD0uxfpILOj1lzFK3wM+hC39dWLEFL0JE9PcrCwAlWr491phfOd2i0yLd+HDqir4KM k3ztDzHeCnvOnWOpfAr/wT6zihRM/X4fVxdpSmt8= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id BBE8C3858D35 for ; Wed, 1 Feb 2023 13:03:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BBE8C3858D35 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNCm9-00080z-N2; Wed, 01 Feb 2023 08:03:45 -0500 Received: from [87.69.77.57] (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 1pNCm9-0002H1-5L; Wed, 01 Feb 2023 08:03:45 -0500 Date: Wed, 01 Feb 2023 15:03:43 +0200 Message-Id: <83357p1qs0.fsf@gnu.org> To: Andrew Burgess Cc: gdb-patches@sourceware.org, gdb-patches@sourceware.org, thiago.bauermann@linaro.org, simon.marchi@efficios.com In-Reply-To: <87lelhtwqv.fsf@redhat.com> (message from Andrew Burgess via Gdb-patches on Wed, 01 Feb 2023 12:07:20 +0000) Subject: Re: [PATCH v3 5/8] gdbserver: Transmit target description ID in thread list and stop reply References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-6-thiago.bauermann@linaro.org> <87lelhtwqv.fsf@redhat.com> 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 Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Cc: Thiago Jung Bauermann , Simon Marchi > > Date: Wed, 01 Feb 2023 12:07:20 +0000 > From: Andrew Burgess via Gdb-patches > > Finally, I wonder if it might make sense to add something like: > > @cindex Target Description IDs > > to every place where we discuss these ID's, then there will be an index > entry that links all the places together? Adding index entries is always welcome, as those help finding subjects quickly and efficiently. However: . we prefer index entries to use only lower-case letters, to avoid having their sorting order (which eventually affects whet you see in the Info reader when you use completion) depend on the locale where the manual is produced from Texinfo; . more importantly, it is not a good idea to have multiple identical index entries, since makeinfo then disambiguates them as foo<1>, foo<2>, etc., and when you see those in the list of completions, you have no idea which one is the one you want. So it is preferable to qualify each such index entry in a way that will convey enough information to the reader to know which one he/she wants. For example: @cindex target description id, and remote packets @cindex target description id, in python programs etc., you get the idea.