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 B10413858D38 for ; Sat, 13 Apr 2024 06:36:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B10413858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B10413858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712990188; cv=none; b=TqNOw9sx2JEo9cKx/wtDCT83dD14PddRcSkWwZfvjf+v28E16I1g7UnwEyuCS0JfIuJa/HmeIqEDggWYuNTwSYKADBBqVptkduITKDa21EAci20jQvUOC4UJYhWOremikBg0Mdx/2VbZsjQYLd+uDbm05VQaeJpvRLJtMBXGYFY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712990188; c=relaxed/simple; bh=EFaFPjfncjVGhBqRgrJfc+XqO2M1vNQK34s9TjUHdQQ=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=Hjf4JKtbEPQAw0+indKpbLhNUEtXOysOnMyAT7Ax87BWkWlyaijsrHAHGRxXn2DkoXKMKx9MQDdO503DL4tQNvuVMB0gCS/AJzt/PbmT7NWb3t1g7PLhmJfM8uRHze+02skZjtXeY0B84zjoozL1hsUW+fft5QoDpjO4x/2WAdY= ARC-Authentication-Results: i=1; server2.sourceware.org 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 1rvWzv-0007qR-Rv; Sat, 13 Apr 2024 02:36:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/ltbd8ZRx1vQx2Lcb7LFmdA6p3YztTNLfSzmvaDm33o=; b=YNuuwrJnhphF 5j2uHvbBeONcXKMAJKIDxrFsSkvS9wZSfFTM0q0g3m77KMwjJg1rNKbRTMWKQ6X1ai1t2PkgkVkxS EeIXGYV/bxyxpabgK8fAUaWN/JAgRQjIvE8LgC+SDcIa/zKLCNn/hdTthboBMFfNG3Qmi7jXO/EQr Qnvxp7/51IT6uHNd5qk7noNRAvHo+bpfoW78H016ToXh31qNda1pkOZ+s7GS6NnhJn5uYSjAt6mLo JSc5/8eueGu9pyyJ5IXnjzOSemvnzTWM+R3ksq9YwkPjs6f5C4h9Gy77WIFk/mzc4i2gGZNP0q904 PGYaFRe7PCYHG2kpFUl5RA==; Date: Sat, 13 Apr 2024 09:36:10 +0300 Message-Id: <86zftxrcpx.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: lsix@lancelotsix.com, gdb-patches@sourceware.org In-Reply-To: <87le5i440e.fsf@redhat.com> (message from Andrew Burgess on Fri, 12 Apr 2024 23:20:33 +0100) Subject: Re: [PATCH 2/6] gdb: move display of completion results into completion_result class References: <86v855dyls.fsf@gnu.org> <20240330233038.sol5j3cp7vsym4uz@octopus> <86v853ar3c.fsf@gnu.org> <87v84m4hps.fsf@redhat.com> <867ch2s9rw.fsf@gnu.org> <87le5i440e.fsf@redhat.com> X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Andrew Burgess > Cc: lsix@lancelotsix.com, gdb-patches@sourceware.org > Date: Fri, 12 Apr 2024 23:20:33 +0100 > > Eli Zaretskii writes: > > > What is "gdb-shell"? Saying "gdb-shell semantics" is only useful if > > the term "gdb-shell" is known and understood by many. Otherwise, we > > should not use this terminology, because it doesn't explain anything. > > It's a name I made up for the thing you type at after a (gdb) prompt. > > The point is, it's not a "shell", it's GDB. It has its own rules. Do we have those rules spelled out somewhere? In the context of this discussion, the pertinent rules are those for quoting in file names. Are they documented? And does this patch series modify those rules in some way that users will need to know? I guess this part: > + We are agreed that there's clearly a documentation issue. However, > I would argue that the documentation is missing for current > functionality (i.e. the current rules for quoting and escaping file > names). We wouldn't document this stuff as part of "command > completion", that doesn't really make sense I think. I will start > working on a separate patch to try and improve the documentation for > how file names are quoted / escaped currently, means the answer is NO. So yes, it would be good to document those rules in the manual (it would also be useful when someone would like to fix the bugs in Emacs you mention below). > OK, so now the bad news. > > My patched GDB doesn't "just work" with emacs. > > Remember though, an unpatched GDB doesn't work either when trying to > complete a filename with spaces in, so it's not that I've made things > worse. > > I tracked at least one bug down to this function in gud.el: > > (defun gud-gdb-completion-at-point () > "Return the data to complete the GDB command before point." > (let ((end (point)) > (start > (save-excursion > (skip-chars-backward "^ " (comint-line-beginning-position)) > (point)))) > ;; FIXME: `gud-gdb-run-command-fetch-lines' has some nasty side-effects on > ;; the buffer (via `gud-delete-prompt-marker'): it removes the prompt and > ;; then re-adds it later, thus messing up markers and overlays along the > ;; way (bug#18282). > ;; We use an "insert-before" marker for `start', since it's typically right > ;; after the prompt, which works around the problem, but is a hack (and > ;; comes with other downsides, e.g. if completion adds text at `start'). > (list (copy-marker start t) end > (completion-table-dynamic > (apply-partially gud-gdb-completion-function > (buffer-substring (comint-line-beginning-position) > start)))))) > > This is trying to figure out everything before the completion word on > the current line and doing the apply-partial with this context on > gud-gdb-completion-function. > > So if we are completing 'file /tmp/abc' then we'd end up doing: > > (apply-partial gud-gdb-completion-function "file ") > > The completion context is calculated as running from the start of the > line up to 'start', which is calculated in the 'let'. And 'start' is > calculated by starting from 'point' and moving backward to the first > whitespace. > > That's not going to work for completing any line that contains a space. > > I think this function would need to get smarter to understand about > escaping and quoting. Yes. Would you mind submitting a bug report about that, using the command "M-x report-emacs-bug"? > And, finally, some good news. > > If a filename _doesn't_ include any spaces, then as far as I can tell, > from my limited testing, everything works fine in emacs, and is now > improved. > > On an unpatched GDB, given a file /tmp/qqq/f1, within emacs: > > (gdb) file /tmp/qq > => file /tmp/qqq > *Sole Completion* > > That's it. At this point emacs will not help me complete this at all. > I have to manually add the '/' and only then will emacs offer the next > level of completion. > > Compare this to plain GDB: > > (gdb) file /tmp/qq > => file /tmp/qqq/ > => file /tmp/qqq/f1 > > With a patched GDB, emacs is now as good as plain GDB. This is thanks > to me adding the trailing '/' character in the 'complete' command > output. > > And on the subject of quotes. With an unpatched GDB emacs is perfectly > happy completing a file containing quotes (well, as happy as it is with > an unquoted file name), e.g.: > > (gdb) file "/tmp/qq > => file "/tmp/qqq > > But, when I get to the final file completion, emacs doesn't add the > trailing quote, so: > > (gdb) file "/tmp/qqq/f > => file "/tmp/qqq/f1 > > In contrast and *unpatched* GDB at the CLI will add the final quote. > > With a patched GDB, emacs is just as happy handling the quotes, only now > it adds the final trailing quote on, just like GDB's CLI: > > (gdb) file "/tmp/qqq/f > => file "/tmp/qqq/f1" SGTM, thanks. > Are there any concerns that I haven't addressed? I don't want to miss > anything that's concerning you. No, I don't think you've missed anything. Thanks for working on this important feature (I happen to be one of those completion junkies, so any improvements in this area are welcome here).