-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sh: switch to LALRPOP? #34
Comments
I think it's OK to say that "invalid UTF-8 paths can't be given directly" for now and use LALRPOP or pest (pest looks good since it uses PGE for parsing). Then, let's explain our usages to the pest/LALRPOP authors and push the implementation of the "matching bytes" feature. |
So, I ended up rewriting the parser without a library using iterators (retrieved from I imagine the performance can be vastly improved as I just did a simple port from The rewritten parser is in the |
BTW the code from |
OK, good. Let's use the handwritten parser first and consider LALRPOP/Pest later (if we cannot handle it properly). |
I would vastly prefer to use something like LALRPOP or
pest
instead ofnom
, but right now neither support arbitrary bytes as input. There is this issue for LALRPOP and this one forpest
that deal with that problem, but I'm not sure if it's fine to just say that invalid UTF-8 paths can't be given directly as arguments for now (they'd still work if a glob was given where the expanded part was invalid UTF-8). Switching to either LALRPOP orpest
should help improve the error messages and make it simpler to fix some of the current parsing issues.As a side note, this is actually the same issue that prevented me from just using
pest
in the first place.The text was updated successfully, but these errors were encountered: