CLIENT-SPECIFICATION: Require support for long options

[pixelcmtd]

Inspired by: #9252 (comment)
For a project that emphasizes long and readable options as much as we do (imho often to an unnecessary degree), it is honestly completely incomprehensible to me that we would only support short options, and I have yet to come across any reasonable excuse for that. If you have one, please comment.

[EmilyGraceSeville7cf]

No mandatory fixes found, approved.
Thanks for a contribution! 😆 🚀 ❤️

[waldyrious]

Thanks for the proposal, @pixelcmtd — indeed it makes sense!

[tldr-pages] emphasizes long and readable options [...] imho often to an unnecessary degree

I hear you, and I agree that it's sometimes excessive/unjustified. I have ideas for changes to the guidelines that would make them clearer and more sensible about when to use long vs. short options.

[waldyrious]

I agree with this change, but I'd ask other maintainers to wait a few days (perhaps over a week, given the holiday season) before merging, so that client authors may get the chance to have a look and chime in. Perhaps we should even ping authors of the main clients just to be sure. Does anyone have a list of client authors handy?

[pixelcmtd]

@waldyrious I just looked through all clients listed in the wiki and the only somewhat spec compliant ones without long options are untldr and an old go implementation. The overwhelming majority of clients that respect the spec support long options.

[kbdharun]

@waldyrious I just looked through all clients listed in the wiki and the only somewhat spec compliant ones without long options are untldr and an old go implementation. The overwhelming majority of clients that respect the spec support long options.

Nice so I guess we can merge this PR. As suggested below we can wait for the client's author's opinions.

[pixelcmtd]

@kbdharun I'd also suggest still waiting a bit for others to comment their concerns

[waldyrious]

Thanks for doing that review! The authors of those clients don't seem to be very active, but just in case, let's ping them here in case they'd want to update accordingly: @unInstance, @k3mist.

[sbrl]

Yeah, this looks sensible. I think we didn't require the implementation of long options vs short options before 'cause of some arg parsing libs that don't support long options, but I don't see a reason why we shouldn't require long options now.

Also, @pixelcmtd can you update the changelog at the bottom of the client spec before this is merged?

imho often to an unnecessary degree

agreed

[CLAassistant]

All committers have signed the CLA.

[EmilyGraceSeville7cf]

No fixes found, approved.
Thanks for a contribution! 🚀 ❤️