Feedback about users/palves/cli-options

[Pedro Alves]

On 5/18/19 11:35 AM, Philippe Waroquiers wrote:

> I have re-checked with the last state 4397e95d5f213937af6748c9df098b8d546182d7.
> Everything works as expected, except that 'help thread apply'
> still speaks about frame information.

Thanks so much for the testing / feedback.  Much appreciated.

You've probably noticed that I sent the patches to the list now.

> 
> Some further possible fine tuning:
> * The behaviour for 'frame|thread apply' in case of error could be better
>   explained in the help, as '-c' speaks from an error without referring to COMMAND.
>   What about:
>    -c
>      Print the error raised by a COMMAND and continue.

I did this.

> 
> * For 'number options' (such as -elements): we could (similarly to boolean options)
>   make the value optional, meaning unlimited by default, e.g.
> 
>   -array-indexes [on | off]
> Â Â Â Â Set printing of array indexes.
> 
> Â  -elements [NUMBER | unlimited]
> Â Â Â Â Set limit on string chars or array elements to print.
> Â Â Â Â No value or "unlimited" causes there to be no limit.
> 
> Effectively, if I do not give a limit after -elements, there is no limit :).
This one I did not do.  I'm not super sold on it.  E.g., I wonder
whether it make sense to make no-value revert the option
to gdb's default?  Dunno.  Maybe looking through all/most of
the uinteger options would be more revealing of whether that's a natural
choice.

In any case, I'd like for such a change keep consistency with
the "set" commands.  With boolean "set" commands, you can suppress
the "on", it's implied.  E.g., "set non-stop" works.  But you can't
suppress the "unlimited" with "set" commands either:

 (gdb) set print elements 
 Argument required (integer to set it to, or "unlimited".).

So if we changed options I think we should change "set" too.

Thanks,
Pedro Alves