Skip to content
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

Consider using more accurate wordPattern #224

Open
lierdakil opened this issue Mar 18, 2023 · 2 comments
Open

Consider using more accurate wordPattern #224

lierdakil opened this issue Mar 18, 2023 · 2 comments

Comments

@lierdakil
Copy link

Currently, language-haskell sets the word pattern to

wordPattern: /([\w'_][\w'_\d]*)|([0-9]+\.[0-9]+([eE][+-]?[0-9]+)?|[0-9]+[eE][+-]?[0-9]+)/

Would be nice to use something that matches the syntax definition itself, f.ex.

/(?:[\p{Ll}_\p{Lu}\p{Lt}][\p{Ll}_\p{Lu}\p{Lt}\p{Nd}']*)|(?:[\p{S}\p{P}](?<![(),;\[\]`{}_"']))+/u

Feel free to omit operator regex if you feel it's extraneous, I'm on the fence about it.

Side note: numbers are apparently filtered by vscode anyway, so matching on numeric literals is kinda pointless.

@JustusAdam
Copy link
Owner

Hmm, I would be willing to try a different word pattern and I think including operators is not a bad idea. Are you saying the new pattern you propose is just the one copied from the syntax file?

@lierdakil
Copy link
Author

copied from the syntax file?

For the most part. I've adapted it slightly, as JS regex doesn't support range boolean operations, so it's using negative lookbehind in the operator pattern instead. I've also merged data/type constructor pattern [\p{Lu}\p{Lt}][\p{Ll}_\p{Lu}\p{Lt}\p{Nd}']* and identifier/tyvar pattern [\p{Ll}_][\p{Ll}_\p{Lu}\p{Lt}\p{Nd}']* (notice the only difference is in the first range).

FWIW I've patched language-haskell locally, and it works well enough for my purposes (i.e. autocomplete). However, operator pattern picks up things like .., which can be a little annoying sometimes. Perhaps limiting operators to length 3 and up (i.e. use {3,} instead of +) could be beneficial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants