lol!
"politically-correct" here means a phrase that tries really hard not to offend anyone, with the outcome of resulting shallow at best, or even offending at worst.
e.g. @asdffdsa you are a strong and independent human being, and I respect your choices.
sure, but the 22-char limit was there well before the new flags in current beta, so I would have expected to have seen that mentioned in the docs.
the new docs will mention the new flags, sure, hopefully future docs-readers will see it.
if I say, for example, that the rclone config create
should not allow true
as a valid value for filename_encryption
if rclone complains about it later, then we are discussing about parameter configuration and programming logic.
it's fully unnecessary to be talking about "my use case", which is just invoking a command.
(I'm not saying you did say that on this issue, please take my metaphor with a grain of salt.)
you have done that multiple times and I've clearly expressed to you my thoughts on this, yet you keep doing it... as a consequence, the discussion becomes me vs you, and we don't ever go forward!
just take a look at the back and forth replies of this thread...
once again, this is not about my "use case":
IMHO it is a bad idea to have very different things happen upon execution of the following two commands:
rclone config create [...] password 123456789012345678901
rclone config create [...] password 1234567890123456789012
at present, the behaviour generates confusion, which generates folks coming to the forum with questions that should be answered by the docs.
in other terms, I was offering constructive criticism and suggesting, for example, that the new flags should be set mandatory so as to be explicitly telling rclone what to do. or, that a single default behavior should be chosen, independently of the number of chars.
again, this is so obvious that stating it is pretty insulting.
I understand docs can be updated -- I'm trying to wrap my head around the situation here.
I would want new users to give me suggestions on my code and user experience, and I would certainly not reply to them: "documentation can be updated".
if we cannot agree on whether that true
value is an issue, how can you ask folks to spend time preparing a pull request?
I know, I know! I respect your utter patience!
but, you should really stay more focused on the issues at hand.