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 1C8473858294 for ; Fri, 12 Apr 2024 18:42:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1C8473858294 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 1C8473858294 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=1712947337; cv=none; b=v7GchrJMnKPCBYY7WaFgqdi/hR7+9ws+HgxvvIez67g+5uRl+K/cgJhyirnXzCrR4S22KiP3dAUog+dOEjIXXhyrws21HkJ3yyEQP1wiz7YZoOTGXyUqAyuMFyIIcxMlTk7VDIA4eET6KTxrWO9FWGqlkOKe9LiYwXuCEmxnaDM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712947337; c=relaxed/simple; bh=ve8Jd5M5mbnZ4dhWamDcXZglpcDDGdNdNLlJEsm8+kg=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=koGclmXLvwc6GNG1fEL8wJ/rc254D2l8A5WgGMrnhF2fmnVEI1vGOP3WMfjuQkP8DExTO975AeufXFgcF1B2vRJe/Jktu8NltyTYUj5o2ffCBdQvZ3DSnaBJP5DZ4hED5iQXfGPySsmG5PiuT3M+NPx6YRNxkf8lFHhBYS0FYmo= 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 1rvLqo-0008OP-Fy; Fri, 12 Apr 2024 14:42:14 -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=xnmDvGi2DZvxJPolG5Y+4MJ3HvV3SyMAgYQuJ+alp4Y=; b=m0+OhAjEHgS9 O1iEtedYfavxcQ4Wztgb1O5rbnUceVWZQHDZuKUgdfi4/KP4j29IOMxB7H/0aWqN4a/WbaJ1v7Bke xXn6xzGzq//iTMWhhk+rj49xduAvl7gO5/K3XVxttfbmPRJqHrlyvd8HVcDacazDfhYeQUOjMh7sd g9Bk81KfwCQe3Z5U1YJFaCMSB45wxNQZWlL8/d02vT3nIEICvalWU6pHn7LC2tZTuP+VJTeWwTDOe plrz5zvYe8meXEjFvYf+G2NSdqtH+R1E+Jt756ka5aXyYSHhqZiNGLTCc4wB9d4mgIcTaRs2cUbdO fKbez291CmbMuoVNAYOEKQ==; Date: Fri, 12 Apr 2024 21:42:11 +0300 Message-Id: <867ch2s9rw.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: lsix@lancelotsix.com, gdb-patches@sourceware.org In-Reply-To: <87v84m4hps.fsf@redhat.com> (message from Andrew Burgess on Fri, 12 Apr 2024 18:24:31 +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> X-Spam-Status: No, score=-0.7 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: gdb-patches@sourceware.org > Date: Fri, 12 Apr 2024 18:24:31 +0100 > > Eli Zaretskii writes: > > > Next, if 'file' indeed expects shell file-name semantics, then the > > question is: which shell? Should the above behave differently on, for > > example, MS-Windows, since file-name quoting there works differently? > > For example, escaping whitespace with a backslash will not work on > > Windows. > > I think calling this "shell file-name semantics" makes this change seem > worse than it is. If we want to call it anything, then it should be > called gdb-shell semantics. 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. > > And last, but not least: the manual says about the 'complete' command: > > > > This is intended for use by GNU Emacs. > > > > So one other thing we should consider is how Emacs handles these cases > > and what it expects from GDB in response. > > Happy to test such a thing. Can you point me at any instruction/guides > for how to trigger completion via emacs? Invoke either "M-x gdb" or "M-x gud-gdb" from Emacs, and then, after the debugging session starts, type TAB to complete file names in commands that accept file names. > My hope is that this change will fix things rather than break them. > Previously the 'complete' command would output a partial completion that > was invalid, that is, if the user passes emacs a short string and then > triggers completion, GDB would provide a longer string which was > invalid. If emacs then feeds that longs string back to GDB the command > isn't going to work. After this change that should no longer be the > case. I hope you are right. Let's see. In general, Emacs doesn't need any quoting when it receives file names from a sub-process (in this case, from GDB). > >> The problem Andrew is trying to solve is that the current completer for > >> this command completes to something that is not a valid input. > > > > My point is that we need to have a clear idea what is a "valid input" > > before we decide whether the current behavior is invalid, and if so, > > how to fix it. > > I do disagree with the "decide whether the current behaviour is invalid" > part of this text. Completion of files containing whitespace doesn't > work right now, so I'd suggest the current behaviour is self-evidently > invalid. But ... > > > IOW, we should step back and discuss the valid > > behavior first. > > I'm totally happy to take suggestions on what the working behaviour > should look like. I made one alternative suggestion about completing a file name that begins with a quote, for example. Whether it is a good suggestion depends on what we want the behavior to be, so that should preferably be discussed before deciding on the solution. Thanks.