[v3?] ErrorStdOut naming

[Descolada]

I wish the #ErrorStdOut directive and /ErrorStdOut command line arguments were either renamed to ErrorStdErr, or modified to output to StdOut instead. At the moment the naming is confusing, because one would expect that of StdOut and StrErr, ErrorStdOut would redirect output to StdOut.

[lexikos]

Existing tools would not work if the behaviour was changed. At best, another name could be added, and we would have two directives and two switches that do the same thing: output errors to stderr. Tools would still use /ErrorStdOut, otherwise they wouldn't work with versions of AutoHotkey that exist right now.

I considered it more a pedantic concern than a practical one.

[V2User]

ErrorStdOut is a kind of StdOut. So, currently, the naming convention follows the Portuguese naming rules, where type or kind is at the last position within a name.

[Descolada]

ErrorStdOut is a kind of StdOut. So, currently, the naming convention follows the Portuguese naming rules, where type or kind is at the last position within a name.

It is not a kind of StdOut. StdOut is one of the three standard streams along with StdErr and StdIn.

Existing tools would not work if the behaviour was changed. At best, another name could be added, and we would have two directives and two switches that do the same thing: output errors to stderr. Tools would still use /ErrorStdOut, otherwise they wouldn't work with versions of AutoHotkey that exist right now.

I think adding another name would probably just add to the confusion. If this change was ever to be considered, then perhaps for v3+, so if anyone (probably you?) is making a list of potential backwards incompatible changes, this could be one of them.

I considered it more a pedantic concern than a practical one.

Most definitely more a pedantic concern, but in practice I spent quite a bit of time figuring out why ExecScript wasn't outputting errors to StdOut when using /ErrorStdOut. I don't always read the docs carefully

[lexikos]

For command line switches and other features which connect with external tools, such as the debugger engine, it is not just a matter of following the typical backward-compatible rule.

Backward-compatibility means that a new version works with old tools, even if they are no longer being maintained. But beyond that, differences in the command line switches between versions mean that external tools need additional complexity (if minor) to support both versions, or the author must choose to support the new version at the expense of the old version. For tools which support AutoHotkey only via configuration files, it might not be simple to support both versions in a convenient way.