-
Notifications
You must be signed in to change notification settings - Fork 3
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
Trimming TEXT token values while lexing #12
Comments
I don't think it should. It would make the lexer lossy. I'll have something for you (this issue and #10) in the next few days. Certainly in the form of a token stream (see Kocal/prettier-plugin-twig#17 (comment)) that will be easily filterable and come with a It is already done and mainly tested (thanks to @Kocal), I just have to move it there. |
Nice to hear that. However is this token stream's |
@ericmorand I'm waiting for the changes on your part. |
The token stream will be deployed by the end of the day. Note that the TEST_OPERATOR token will remain. I really think that the This is backed up by the fact that in both TwigPHP and Twing, there is a test at one point in the parser that goes "if the token is an operator > if its value is It should be trivial to replace TEST_OPERATOR tokens by OPERATOR tokens in the stream, would you need it. |
Got it. |
In TwigPHP, the use of whitespace control modifiers on statements can affect the value of the preceding or following
TEXT_TYPE
token depending on where the modifier was used.Should this lexer implementation do the same and trim the preceding or following
TEXT
Token value when it encounters a statement with whitespace control modifiers?The text was updated successfully, but these errors were encountered: