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

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrew Burgess <aburgess@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Fri, 12 Apr 2024 18:24:31 +0100
> 
> Eli Zaretskii <eliz@gnu.org> 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.