Re: [RFA 0/3] Allow the user to define default leading args for commands and aliases

[Philippe Waroquiers <philippe dot waroquiers at skynet dot be>]

On Wed, 2019-07-24 at 10:15 -0600, Tom Tromey wrote:
> > > > > > "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:
> 
> Philippe> Allow the user to define default leading args for commands and aliases.
> Philippe> This patch series implements, tests and documents the following commands:
> 
> Thank you for the patches.
> 
> Philippe>   set leading-args COMMAND [= LEADING-ARGS...]
> Philippe>   show leading-args [COMMAND]
> Philippe>   set enable-leading-args [on|off]
> Philippe>   show enable-leading-args
> 
> Philippe> It also changes the alias command to be:
> Philippe>   alias [-a] [--] ALIAS = COMMAND [= LEADING-ARGS...]
> 
> I don't really like the "leading args" approach, but I've put off
> responding to this because I wasn't sure how to articulate my
> objections.
> 
> However, I never did come up with a really good way to talk about it.
> 
> Partly, I think, the feature seems obscure.  It's preferable, in my
> view, to continue the approach gdb already takes; namely, adding "set"
> commands to affect the behavior of commands when desirable.
IMO, the "set <some setting>" commands and "set leading-args"
have 2 different objectives:
  * "set <some setting>" defines a specific setting that changes
    the behavior of a command.  Since Pedro's cli option framework,
    settings can have equivalent command args.
  * "set leading-args" allows to define default arguments for
     any command.
     It is not very clear to me how to do the second objective with
     the first.

> 
> 
> On the related commands:
> 
> What is the rationale for "set enable-leading-args"?  This seems truly
> unnecessary.
'set leading-args' allows to define default arguments to the "standard"
gdb commands (such as "backtrace").

So, 'set enable-leading-args off' allows to go back to the default behavior
of such standard commands.
It typically would be used in the "with" command, e.g.:
   with enable-leading-args off -- backtrace

Now, this is only useful if we keep the functionality to define default
leading-args for standard GDB commands.

If "set leading-args" is really too obscure, we can just keep the
"alias" part of this patch.


> 
> For "alias", I don't see why the second "=" is required.  "alias" would
> be better if it just allowed arguments without special syntax.
> 
> On that topic you wrote:
> 
> Philippe> Also, an '=' character must be specified in the alias command before
> Philippe> the LEADING-ARGS for consistency with set leading-args.
> Philippe> This also ensures that the user cannot type a wrong command name
> Philippe> that would be interpreted as leading args and/or cause 'mismatch'
> Philippe> of length between ALIAS and COMMAND
> 
> I don't really see this as a big concern.  Presumably someone would
> notice if their alias did not work properly.
Ok, I will modify the patch to remove the need for this second "=".

If ever we see in the future that (sometimes) an "=" is needed to
avoid the confusion between a leading argument and a command name, we can
always modify the "alias" command to optionally accept an "=" to separate
the COMMAND from its arguments.

Philippe