-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix the behavior of Lexer.get_column #978
Conversation
e77b303
to
e29d371
Compare
Anything you want us to do at this point or are you happy with us trying this, when it reaches the the released state? |
I ran all of the |
Did you remove the Is my understanding right, that that's obsolete now? |
Yeah, tests pass without that. |
Actually, without that check, one of the example files in |
Will have to check, I just realized, that I never added the examples (elm-tooling/elm-language-server#527 (comment)) to our test suite. I probably thought, it's fixed now and we will never move that code again 😆 |
Added in elm-tooling/tree-sitter-elm@569336c |
Fixes #516
Fixes #589
Closes #640
Fixes #144
This PR finally makes the
Lexer.get_column
(needed for languages like Haskell, Elm) API work properly.get_column
, using a test fixture language with Haskell-like layout rules.get_column()
get_column
so that it returns a byte count, not a character countRegarding this last item - We originally returned a character count from
get_column
because it seemed more technically correct, since GHC counted the unicode characters (as opposed to the bytes) in its implementation of layout. But this adds so much complexity (and perf cost) to our code that I really don't think it's worth it. There could be some slightly incorrect layout-parsing if somebody uses a mixture of different non-ascii whitespace characters for their layout, but this seems like a very uncommon situation./cc @razzeee @tek @bglgwyng @banacorn