Re: [PATCH 2/6] gdb: move display of completion results into completion_result class

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 30 Mar 2024 23:30:38 +0000
> From: Lancelot SIX <lsix@lancelotsix.com>
> Cc: Andrew Burgess <aburgess@redhat.com>, gdb-patches@sourceware.org
> 
> On Fri, Mar 29, 2024 at 03:14:07PM +0300, Eli Zaretskii wrote:
> > > From: Andrew Burgess <aburgess@redhat.com>
> > > Cc: Andrew Burgess <aburgess@redhat.com>
> > > Date: Fri, 29 Mar 2024 11:42:28 +0000
> > > 
> > > When using the 'complete' command to complete file names we have some
> > > problems.  The suggested completion should include any required
> > > escaping, so if there is a filename '/tmp/aa"bb' (without the single
> > > quotes), then this should be displayed in the completion output like:
> > > 
> > >   (gdb) complete file /tmp/aa
> > >   file /tmp/aa\"bb
> > 
> > Why should it be displayed with the backslash?  And would the
> > completed name, if passed to a command, also have the backslash added?
> > If so, it could cause some commands to fail; basically, you are adding
> > shell file-name semantics into commands that don't work via the shell.
> 
> Hi,
> 
> The "file" command currently expects "shell file-name semantics":

For starters, this fact, if it is true, is not really documented.

>     $ gdb -q
>     (gdb) file test/aa bb/a.out
>     test/aa: No such file or directory.
>     (gdb) file "test/aa bb/a.out"
>     Reading symbols from test/aa bb/a.out...
>     (gdb) file test/aa\ bb/a.out
>     Load new symbol table from "test/aa bb/a.out"? (y or n) y
>     Reading symbols from test/aa bb/a.out...
>     (gdb)

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.

Also, Andrew used the 'file' command in his examples, but completion
in GDB is used in many other commands, including those who don't
necessarily expect/need shell file-name semantics.

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.

> 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.  IOW, we should step back and discuss the valid
behavior first.  Andrew's patch series started from postulating a
certain desired result without any such discussion, and I think we
should discuss these aspects before we decide what is the desired
result.

> That being said, this is just my 2 cent, I am looking forward to
> hearing other people’s thoughts on the subject.

Same here.

Thanks.