How strong is the dislike for non-standard syntax?

[samhocevar]

Hello. I am not (yet) a CLI11 user but I am growing frustrated with the bugs in clipp and CLI11 seems like a very mature alternative. The README states that this is not supported:

Non-standard variations on syntax, like -long options. This is non-standard and should be avoided, so that is enforced by this library.

I do avoid these, too. However I am writing a replacement for some non-free software which uses such flags. If I ever want to provide a drop-in replacement that does not break existing user scripts, I am a bit stuck for reasons that are not really technical.

What are my options? Should I just fork? Or would you accept a PR under certain conditions, like an opt-in macro that users should explicitly provide?

[phlptp]

See #462 for some other discussion on this.

I think it would be fairly challenging to add support without breaking a bunch of other stuff, but as long as the first character of the -xxxx option doesn't match another single character option the option gets placed in an extra arguments location. So then after regular processing you can have a second step which deals with unhandled options more directly or have a final_callback which deals with them like the example given in #462.

[samhocevar]

Thanks for the suggestion. Unfortunately I do need to support conflicting stuff such as -o something and -out something_else. Also using final_callback would prevent me from using all the nice type-safe argument parsing.

I guess I will try to implement the feature and keep it updated in a custom branch.

Edit: by the way, I am now a CLI11 user and already very satisfied.

[samhocevar]

So, I wrote a proof of concept in ca183479b7c11f2ec59fcade9efc95e302ef7b96. My strategy is to store these special flags in the short options, but try to parse them as if they were long options first. If option lookup fails, try again with Classifier::SHORT.

This allows to define options -o, -p and -poop and they all work as expected; -pop will behave like -p -o -p but -poop will be something else.

This is not very elegant and not complete, but it suits my needs and is non-intrusive enough that I can maintain the patch without much effort.

[henryiii]

I wouldn't be against adding it if it can be added safely, and if there is a little warning about using it in the docs, saying something like this should be for legacy support only or something like that. I was targeting being able to be used in ROOT at some point, and it does have 1-2 legacy "medium" options. It shouldn't match long options. I think defining "-medium" should be the only way to trigger a medium option match.

Your basic PR looks pretty good; I'd just add a medium option list and only match against that; the medium options would be filled by dash + more than one char in definition. We might need to make sure it works properly in Windows mode, too.

[samhocevar]

Thanks for the review. I initially considered having a list of medium options, but the signature for get_names was already a bit long so I decided against it. I will create a struct instead of adding a 4th element to the tuple.