From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 7C54C385624D for ; Wed, 25 May 2022 19:56:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7C54C385624D Received: from fencepost.gnu.org ([2001:470:142:3::e]:49336) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntx7j-0008Mu-I6; Wed, 25 May 2022 15:56:51 -0400 Received: from [87.69.77.57] (port=1525 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 1ntx7j-0003NS-25; Wed, 25 May 2022 15:56:51 -0400 Date: Wed, 25 May 2022 22:56:41 +0300 Message-Id: <83mtf5perq.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <20220525193126.1613411-1-pedro@palves.net> (message from Pedro Alves on Wed, 25 May 2022 20:31:26 +0100) Subject: Re: [PATCH] gdb/manual: Introduce locspecs References: <20220525193126.1613411-1-pedro@palves.net> X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.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: , X-List-Received-Date: Wed, 25 May 2022 19:56:53 -0000 > From: Pedro Alves > Date: Wed, 25 May 2022 20:31:26 +0100 > > To clarify this, I propose we use the term "Location Specification", > with shorthand "locspec", when we're talking about the user input, the > argument or arguments that is/are passed to commands to instruct GDB > how to find locations of interest. This is distinct from the actual > locations in the program, which are what GDB finds based on the > user-specified locspec. Then use "locspec" thoughout instead of > "location" when we're talking about the user input. Sorry, but I don't think this is a good idea. It is IMO okay to introduce "location specification" into our terminology; it is even okay to use "location spec" as its shorthand. But "locspec" is too much: it's not a word, so it doesn't explain itself enough, and thus cannot be used very far from where it is defined, because the reader will likely not understand what it means. "Locspec" is fine to use in the likes of @var{locspec}, where we describe commands that take a location specification as an argument, but using it as a general term everywhere in the manual (and we have quite a lot of references to location specs, as several commands work in these terms) will make the manual more awkward to write (we will need a lot more references to where "locspec" is defined), and as result harder to read where these are mentioned, due to the need to actually go to that cross-referenced section. As I suggested elsewhere, I think it would be a better idea to reserve the use of "location" only to these specifications, and use some other term (e.g., "address") for the actual "resolved" locations that are places in the program's code. That will allow us to use "location" as a shorthand for "location specification", something that will inevitably happen anyway (people being what they are: we hate to type long phrases when we think a shorter one will do). If we use "location" for two related but different concepts, this tendency will cause confusing text both in the manual and even in our discussions here on the list. Or maybe there are other ideas to resolve this difficulty. If someone has alternative proposals, please describe them, and let's discuss. Thanks.