From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 69C41385C41A for ; Fri, 1 Jul 2022 15:13:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 69C41385C41A 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-wm1-x32d.google.com with SMTP id j7so1507133wmp.2 for ; Fri, 01 Jul 2022 08:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:subject:message-id:user-agent:mime-version; bh=EO1rryCbP254ribyOsYSI8ud+dpUEa58WsUx1NYlVX8=; b=P/b9iZZBmjjicFtUrWMug9tpcgoWBL/v5uhF3iujcnIaAIuvt9r5wypqNk5MG1WDWN eEJC/8UBOsLt+chvi5G7Zq0YBb7EmQ0QSMxyRdrnQMQQTN6l3GPWwibpZtLACUdOrkYl 7SMBf04V6XW05lvzt2t01PDZ2aSLnpZOBVOje0VqmDOA1Y+625DjY2l4s+9ogzSCvKlA PSjZ/1nBTWU6xWmMKrnhji4/ExMNDuTt4tNUGR7M2cuVgcDs5hjhRWAimRKnwyAVy923 N0vJO/nXdLam0AzMWXl9wCkLf/wim4EOARZTFpJveUdVyTy7/9WBB+hTkL/XQEIsLF1a JJDA== 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:subject:message-id:user-agent :mime-version; bh=EO1rryCbP254ribyOsYSI8ud+dpUEa58WsUx1NYlVX8=; b=CHzIQXtx2QBXwnwcGRthtm13T2pTZ86CPM5NUrRlQ/xpxz2FbbNLKBXnHVEaTtmTM+ obfhcK1WJ2AP9O56hpZveswHo9yD1PqfH2ePKVZm6hPUtml60CYnuEbnIH3EXETdY3xy Q6KTXfEKeg9ciPXSc7DYoLnkSqQoS/bZKKYtk/OOkHzbalWJMyuIFM975vVhjFdERs51 8gYhgTXDKZc1GtjPy8Ir9xQtkZcyNWu+MjPfmQB87xoohXJvSaNL1I4OC0SpfBZ5yTva L1lBCNN2sVLIon8vS/VbL6Csir60mDp86AVBE1f+RJXdMeLvy+nrj3HxqIQtOEORcvQ3 x6vw== X-Gm-Message-State: AJIora+EKvUINCtv3PIEXvMe9ydPy/mH/vftoJ1nwpaYAlc8+RxV7/+9 YgKYiTuIGXd7m1hDo08owNwE5mmR1OkGGQ== X-Google-Smtp-Source: AGRyM1s1Sg8UUqHQdksG+trjHa0Wla/bnIKbp1i/yA4BEDasuRC64Wv7IfoyPs2v46WvDSEBkGnfOQ== X-Received: by 2002:a05:600c:218b:b0:3a1:8e79:df6 with SMTP id e11-20020a05600c218b00b003a18e790df6mr3362012wme.29.1656688388152; Fri, 01 Jul 2022 08:13:08 -0700 (PDT) Received: from tpp.orcam.me.uk (tpp.orcam.me.uk. [2001:8b0:154:0:ea6a:64ff:fe24:f2fc]) by smtp.gmail.com with ESMTPSA id a1-20020a05600c348100b003a03be22f9fsm1575536wmq.18.2022.07.01.08.13.06 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jul 2022 08:13:07 -0700 (PDT) Date: Fri, 1 Jul 2022 16:13:05 +0100 (BST) From: "Maciej W. Rozycki" To: gdb-patches@sourceware.org Subject: [PATCH] GDB/doc: Remove extraneous spaces from completion examples Message-ID: 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: Fri, 01 Jul 2022 15:13:11 -0000 Completion results are usually different when the operation is applied to a word that is or is not followed by a space. In some cases they are equivalent, however a space would not be produced if completion was used earlier on in the word processed. However in the manual we have completion examples given using a space that actually prevents the example from working. E.g.: (gdb) info bre (nothing) and: (gdb) info bre Display all 200 possibilities? (y or n) as it now goes on to propose the entire symbol table, while: (gdb) info bre (gdb) info breakpoints does the right thing, but is not what is shown in the manual. In other cases an extraneous space is used that does not correspond to the actual completion pattern shown, which gives an impression of sloppiness. Remove extraneous spaces then from completion examples as appropriate. --- Hi, Noticed while making documentation updates for "NUMBER" completion. OK to apply? Additionally we do have an issue with completion here. For example when debugging `cc1' from GCC 12, which has a huge number of template class function symbols, e.g.: hash_table::expand() hash_table::find_slot_with_hash(action_record* const&, unsigned int, insert_option) hash_table::~hash_table() hash_table::expand() [1100+ entries follow] if you try to complete such a symbol correctly, it seems to work as expected: (gdb) break hash_tab (gdb) break hash_table< However if you do it with a space inserted, then you get: (gdb) break hash_tab (gdb) break hash_tab le< which is already wrong. And on one but not all of my systems if you try to complete again at this point: (gdb) break hash_tab le< (gdb) break hash_tab le() func() (@value{GDBP}) p 'func< @end smallexample @@ -2050,7 +2050,7 @@ usually need to type a quote before the function: @smallexample -(@value{GDBP}) b func< @kbd{M-?} +(@value{GDBP}) b func<@kbd{M-?} func() func() (@value{GDBP}) b func< @end smallexample @@ -2063,9 +2063,9 @@ that takes an @code{int} parameter, @cod that takes a @code{float} parameter, @code{name(float)}. @smallexample -(@value{GDBP}) b bubble( @kbd{M-?} +(@value{GDBP}) b bubble(@kbd{M-?} bubble(int) bubble(double) -(@value{GDBP}) b bubble(dou @kbd{M-?} +(@value{GDBP}) b bubble(dou@kbd{M-?} bubble(double) @end smallexample