Handle non-ascii names / options in from_usage(). #670
Conversation
|
Thanks for the pull request, and welcome! The team is excited to review your changes, and you should hear from @kbknapp (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Thanks for the PR! I'm out of town right now, so it may be a day or so before I can fully review this, but I'm excited for this! I'll let you know if I have any questions or changes 😉 |
|
@tormol looks great! Only thing I'd like to add is some tests for non-ASCII in shorts/longs and value names. Should be good to merge after that 👍 |
This should also speeds up the parser (except maybe for short options). Multi-codepoint characters still can't be used as short options, but people shouldn't non-ASCII options nyway. Closes clap-rs#664
….map(|(_,&v)| v) In many cases this makes the assert fit on one line, but the double references are a bit awkward.
tormol
force-pushed
the
parse_nonascii_usage
branch
from
e3426d6 to
fd4c087
Compare
|
Excellent! Thanks again for all the work! @homu r+ |
|
📌 Commit fd4c087 has been approved by |
Handle non-ascii names / options in from_usage(). Closes #664 and should make it faster too. Why aren't the stop_at functions written like `c != a && c != b`?
|
⚡ Test exempted - status |
Closes #664 and should make it faster too.
Why aren't the stop_at functions written like
c != a && c != b?