Command Line Switches: Addition of short switches for their long counterparts #11644

Makes perfect and logical sense - thank you too for adding info about these standards. :) So how about:

--disable-addons - consider adding a "-d" switch to perform this task

--debug-logging - consider adding a "-D" switch to perform this task

--no-logging - consider adding an "-n" switch to perform this task

--no-sr-flag - consider adding an "-N" switch to perform this task

Depending on feedback, happy to edit the initial description with these alternative switches.

First, NVDA does in fact support option combining as I mentioned it might (-Dd), according to user guide section 16.1.

Second, I'm not really clear on the value of the --no-logging option. That should be doable with "-l 0" or "-l 255" or something, even if it isn't now. So I'm not sure I support a short option for that, since I don't see the need for having the switch at all.

Third, I think the --portable-path=PORTABLEPATH switch should go away, and the portable creation options should require a pathspec.

Lastly, here is my list of suggestions for short options, incorporating those of yours with which I agree:

Note regarding -E: it is an uncommon option, so I capitalized it. Rather keep the lowercase for something more valuable.

@feerrenrut @josephsl : thoughts on the reasonableness of any of this?
I come from a Linux background, so it feels wrong to me if there aren't short switches for the vast majority of the CLI options.

I would prefer only adding short switches for commonly typed options. Adding short form for all options doesn't seem to solves any specific issue. Short form is useful for regularly typed options. If an admin is configuring a script or shortcut, it would be more sensible to use the long form since it is self documenting the intent.

cc: @gerald-hartig for triaging.

I have the same opinion as Reef (see #11644 (comment)), i.e. only adding short switches for commonly typed options.

Personally, I commonly type: --disable-addons, --debug-logging and --lang. If --lang is finally not selected in the short option subset, that's not a big problem because "--lang en" is not much longer than "-G en".

Closing as per Reef's comment.

I agree not to define a short switch for any option, especially for those only used in sysadmin install scripts.

Though, there are still commonly used options without a short switch:

• --lang
• --disable-addons
• --debug-logging

The actual question is: how do you define "commonly used"? Basic NVDA usage does not need to use command line. Thus the two most common usages IMO are:

1. A user has issues with NVDA and is instructed by someone else to launch NVDA with specific options. Providing a command line is much more synthetic than instructing to set or unset option X or Y.
2. An NVDA or add-on tester wants to test NVDA with settings that he does not usually uses, e.g. change language, disable add-ons, etc.

Thus, here is my proposal to introduce 3 other short switches:

• -d for --disable-addons
• -g for --debug-logging
• -L for --lang, or -n if we don't want or can't use case sensitive switches

All other switches are meant to be used in scripts IMO.

@gerald-hartig or @seanbudd would you accept a PR implementing this proposal?

I think switches for lang and disabling add-ons makes sense.

Wouldn't using the log short switch l -10 be sufficient for debug logging?

Wouldn't using the log short switch l -10 be sufficient for debug logging?

Well, if I want to provide a debug log to debug an add-on, typing "nvda -gn en" is shorter than "nvda -l 10 -n en".

Reopening to implement only the 2 or 3 most common switches.

@CyrilleB79 - the debug logging switch is redundant and longer than the alternatives. --log-level 10 and -l 10 are both shorter. I think we would drop it if it wouldn't be a breaking change. I don't think we should be adding (minor) complexity to it.
For short switches we plan to only accept:

-n or -g for --lang and -d for --disable-addons.