From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by sourceware.org (Postfix) with ESMTPS id 582B63834E7E for ; Thu, 26 May 2022 10:09:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 582B63834E7E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-lf1-x129.google.com with SMTP id p4so1695333lfg.4 for ; Thu, 26 May 2022 03:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=7TgrL0uQx21c4lNetgEYrfeFI12uva1Zs1ZQZYDrFcg=; b=NuQpjdsx5psuwK91dVDd5gT9pV7outrN7kNfk9XYCSRR2pIU0vl9A+/81xupBTtkWz aHWMlv+JJM0O/ERqyaH+KnAcOH/2dgHwfB346qtj+kxdpSdwiMR/bUCsxAMaKQLqLj/J YJkPjCAHluzUg4jVzGF92MLFbpnjADg1Lxjn2D/W6uIlmGvCaS3QOAlnn4cnhj5qt1N1 qontHqWbDxowq3KRpB4PDXB5u46aeGlgDe82xi8luGPTlP7T5lh4lN+ah3teF3cZ8OIt P04nAHmHPy9E6ITZuoh+LH9Vk/2dXBMIonImI/e7YtDVaSgdy2ie3XQsf3b4FNVhMo5p WIUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=7TgrL0uQx21c4lNetgEYrfeFI12uva1Zs1ZQZYDrFcg=; b=qfKZNGlbWzTiZ5N4kEahsObXc+YmyDWtCTI87tLPhv0gXK3cWXe2DkHX32vPhFkt6j H5LNYduR1TYvH7Oo7T2Pcplrnac7fev+/D049z6Vwo02xk6PlsPxvrf7X0BPRBAUkmLL nLroG3U7CdbTFaWJ6OFle3vE1SLN2phosM+L3RubqRY1hlq+l6/YMenbRs3kzvDZUw7D DLH01W4G5N3jl+Kw1PL6OoI6acaSKIrr0Xm0BKQ4rfk2+d8WoijpXy1jnqiwRPuGyFZu +gqjcsWI9V9Mxulz3vz7fm+iYekBPBjxU+nvYU7W3qg6/p1wIRI3C4GE+xIq2iaSpJDP a8yw== X-Gm-Message-State: AOAM530zT9OKBVHEzg1skUNY77uaKdajb3Eo/VXv+3O9nxjnUSA9hbLr dldZtiMFprXg8S+AQa4I92c89g== X-Google-Smtp-Source: ABdhPJwQ2nkKtutu3lvvCCGF9q6CzRc3WbL1UyI7tzQ9mtIoAhK8LskyHisgvkwFbMmt7Lmpv8IDrA== X-Received: by 2002:a05:6512:ad5:b0:478:67da:6094 with SMTP id n21-20020a0565120ad500b0047867da6094mr16557405lfu.686.1653559781338; Thu, 26 May 2022 03:09:41 -0700 (PDT) Received: from [192.168.219.3] ([78.8.192.131]) by smtp.gmail.com with ESMTPSA id q20-20020a05651232b400b00473c87152bcsm266862lfe.127.2022.05.26.03.09.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 May 2022 03:09:40 -0700 (PDT) Date: Thu, 26 May 2022 11:09:38 +0100 (BST) From: "Maciej W. Rozycki" To: Bruno Larsen cc: gdb-patches@sourceware.org, Simon Sobisch , Tom Tromey , Andrew Burgess Subject: Re: [PATCH v5 3/8] GDB: Add `NUMBER' completion to `set' integer commands In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Thu, 26 May 2022 10:09:45 -0000 Hi Bruno, > > Index: src/gdb/cli/cli-decode.c > > =================================================================== > > --- src.orig/gdb/cli/cli-decode.c > > +++ src/gdb/cli/cli-decode.c > > @@ -989,6 +989,8 @@ integer_unlimited_completer (struct cmd_ > > NULL, > > }; > > + if (*text == '\0') > > + tracker.add_completion (make_unique_xstrdup ("NUMBER")); > > complete_on_enum (tracker, keywords, text, word); > > } > > Seeing as the point of "complete_on_enum" is to add all keywords to the > tracker, why not add "NUMBER" as a keyword? The only possible unfavorable side > effect I can think of would be GDB completing N to NUMBER, and personally > I feel abstracting away how the option would be added is more important than > not adding this completion option. This just follows the existing logic in `parse_option' and is really a special case. I am inconvinced that there is a benefit from getting the completion broken visibly to the user for the sake of avoiding a manual call in the code. Sorry. > Another option would be having the function like this: > > void > integer_unlimited_completer(...) > { > static const char * const keywords [] = > { > "NUMBER", > "unlimited", > NULL > } > if (*text != '\0') > complete_on_enum (tracker, keywords + 1, text, word); > else > complete_on_enum (tracker, keywords, text, word); > } > > Or some more concise way of writing it. And then with 6/8 (which removes `integer_unlimited_completer' entirely) that "NUMBER" entry would have to be added to all the keyword lists passed along rather than a single place in `integer_literals_completer', and still handled as a rather fragile special case where people writing any new keyword lists will have to remember to put a "NUMBER" entry first. I really fail to see the advantage of such approach. Sorry again. Thank you for your input however, it's always good to have a look from a different angle! Maciej