From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by sourceware.org (Postfix) with ESMTPS id 5182B385DC1D for ; Wed, 25 May 2022 20:05:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5182B385DC1D 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-wm1-f54.google.com with SMTP id p19so4644909wmg.2 for ; Wed, 25 May 2022 13:05:20 -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=gBwKaagOjtpUSbf8sgZrEavgUJD5RtuRuOvG/f9Ng0I=; b=qF9AONWGc/CYOn8Yq32NFL7Zzt72z4ge6H/XCHB7s8WB6+CtCgBOW82MRapVLdSGTp J5gmzYRTVpUF5ecdsYiJM3MIJlAB790+Q+V0mcv2eXAzQCS2fujzdRszTmxA7MaXVNic 18B/0AiGdhOoe+j+N/LbulJo/cruQ8se6AQvJNeL8W0z1PvOWOLIYKQgFoyCZYIPxNg3 5BloIG6n1vEcD0lU7D2MYORdbHLr0FsCEoO5FMo3zYgBpAsLUyV23BwiMHODo4yNyxI+ x2nmSSAQWxSuBrhs9+qgHRlShx0hEwmEJuZWIHSnogeC6KbcHatnfiTLB9OE6C+H8MbM obcA== X-Gm-Message-State: AOAM532DjoOyoov31SYRYx4+tZHTLgdOIptY6S3mVYOuXP2ZvdXpTLZf isqzwOrJhAVQFsq2ol4ntHrSGzPsGGg= X-Google-Smtp-Source: ABdhPJxQnsm3x7zSMvaqaqP2sgB+kPpMn7SrVGORFY6v0mvXhoKWwaV33Z37RMVfJQ1hq6w1X1154A== X-Received: by 2002:a05:600c:b53:b0:397:335b:546e with SMTP id k19-20020a05600c0b5300b00397335b546emr9894971wmr.177.1653509119201; Wed, 25 May 2022 13:05:19 -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 n10-20020a5d588a000000b0020d02262664sm3098020wrf.25.2022.05.25.13.05.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 May 2022 13:05:18 -0700 (PDT) Message-ID: <0f341f7e-1eca-7087-495f-32f32fcc58e8@palves.net> Date: Wed, 25 May 2022 21:05:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH] gdb/manual: Introduce locspecs Content-Language: en-US To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20220525193126.1613411-1-pedro@palves.net> <83mtf5perq.fsf@gnu.org> From: Pedro Alves In-Reply-To: <83mtf5perq.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 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 20:05:22 -0000 On 2022-05-25 20:56, Eli Zaretskii wrote: >> 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. Yet, we have "linespec" and people understand it just fine, it's described once in a single spot in the manual. "locspec" just sounds novel now, but it won't be novel anymore once we start using it. It sounds like you are against any term that is new just because it is new. That just blocks progress forever. It is not reasonable. New shorthand names for for things that are referred very frequently should be fine to invent. Our users aren't dummies and they learn things. > "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), No we wont. Everywhere I used "locspec" already has a xref to where it is defined... Please give the patch a change and read it in more detail. > 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. And I've already explained why that would be incorrect. Please give it a read, here: https://sourceware.org/pipermail/gdb-patches/2022-May/189418.html > > Or maybe there are other ideas to resolve this difficulty. If someone > has alternative proposals, please describe them, and let's discuss. > > Thanks. >