-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
Add way to style identifiers. #148
Conversation
Thanks, that was fast! All in all I think this is a good change, but I'll have to read through and check the code when I get the time. Since this changes the public API this is considered a breaking change. You might see that the commit lint failed so please see the contribution guidelines for information on the commit message format used. This also means you need to add something like the following footer to your commit:
I'm wondering if there is some way of releasing this in a non-breaking fashion, but I don't think there is. I don't like pushing breaking changes too often so maybe it's time for me to have another look at how I manage releases so there can be a |
55de594
to
cadb0a9
Compare
Thanks.
My bad on that one, I'll update the message.
I've also been wondering about that. The But |
Replace "default" segment with "whitespace" and "identifier" segments, with fallback to "unknown" segment. Also, classify backticked identifiers like `foo` as "identifier" rather than "string". This allows for identifiers to be styled independently from strings and whitespace. It also simplifies getSegments() from 30 lines down to 5, by removing the special-case code for the "default" segment. BREAKING CHANGE: The `default` segment has been split into `identifier` and `whitespace` segments. There's also a new `unknown` segment that will only show up for malformed SQL such as an unclosed string. However, the highlight() function works largely the same as before, both normal mode and HTML mode, except for the bug fix to stop classifying identifiers as strings. In other words, SQL like select * from EMP where NAME="John Smith" will get highlighted the same as before, i.e. no syntax highlighting for EMP or NAME. Fixes scriptcoded#147.
cadb0a9
to
d6fb836
Compare
This pull request has been marked as stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 5 days. |
Anything you need from me on this? |
Hi again! I'm really sorry for letting you wait so long. Managing life, work and non-paid open source work can be a struggle sometimes. Should've left an update either way. I've switched to using semantic-release for managing the package now which makes it possible to distribute using dist-tags on NPM. So I'll merge this to the I also took the liberty of adding Thanks so much for your patience! |
No worries, it seems like you're putting a lot of pressure on yourself with that scriptbot 2-week timer. :-)
Sure, looks good, I have no opinions about colors. |
I added it mostly to be able to close some issues that I didn't get responses on previously. But this time it came back to me 😅 Turns out it's a pretty good reminder. Anyways, let's merge then! I'll come around to your other issues eventually! |
🎉 This PR is included in version 5.0.0-beta.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Rearrange regexps so "special" regexp catches everything not caught by other regexps. Eliminates the "unknown" segment I added in scriptcoded#148. In practice, the only time we would hit the "unknown" segment is for a few weird character that weren't already caught by the "special" segment, for example, the ? and unclosed ` in "a `?> b". I figured that in those rare cases, we might as well just call those characters "special". Fixes scriptcoded#178, refs scriptcoded#148.
Rearrange regexps so "special" regexp catches everything not caught by other regexps. Eliminates the "unknown" segment I added in scriptcoded#148. In practice, the only time we would hit the "unknown" segment is for a few weird character that weren't already caught by the "special" segment, for example, the ? and unclosed ` in "a `?> b". I figured that in those rare cases, we might as well just call those characters "special". Fixes scriptcoded#178, refs scriptcoded#148.
Rearrange regexps so "special" regexp catches everything not caught by other regexps. Eliminates the "unknown" segment I added in scriptcoded#148. In practice, the only time we would hit the "unknown" segment is for a few weird characters that weren't already caught by the "special" segment, for example, the ? and unclosed ` in "a `?> b". I figured that in those rare cases, we might as well just call those characters "special". Fixes scriptcoded#178, refs scriptcoded#148.
Rearrange regexps so "special" regexp catches everything not caught by other regexps. Eliminates the "unknown" segment I added in #148. In practice, the only time we would hit the "unknown" segment is for a few weird characters that weren't already caught by the "special" segment, for example, the ? and unclosed ` in "a `?> b". I figured that in those rare cases, we might as well just call those characters "special". Fixes #178, refs #148.
Rearrange regexps so "special" regexp catches everything not caught by other regexps. Eliminates the "unknown" segment I added in scriptcoded#148. In practice, the only time we would hit the "unknown" segment is for a few weird characters that weren't already caught by the "special" segment, for example, the ? and unclosed ` in "a `?> b". I figured that in those rare cases, we might as well just call those characters "special". Fixes scriptcoded#178, refs scriptcoded#148.
Rearrange regexps so "special" regexp catches everything not caught by other regexps. Eliminates the "unknown" segment I added in #148. In practice, the only time we would hit the "unknown" segment is for a few weird characters that weren't already caught by the "special" segment, for example, the ? and unclosed ` in "a `?> b". I figured that in those rare cases, we might as well just call those characters "special". Fixes #178, refs #148.
Rearrange regexps so "special" regexp catches everything not caught by other regexps. Eliminates the "unknown" segment I added in #148. In practice, the only time we would hit the "unknown" segment is for a few weird characters that weren't already caught by the "special" segment, for example, the ? and unclosed ` in "a `?> b". I figured that in those rare cases, we might as well just call those characters "special". Fixes #178, refs #148.
# [5.0.0](v4.4.2...v5.0.0) (2024-07-02) * chore!: add support for Node 22 ([9478bf1](9478bf1)) ### Bug Fixes * improve number detection ([02d459a](02d459a)), closes [#149](#149) * improve operator detection ([183a4fb](183a4fb)), closes [#150](#150) * typo in unknown segments ([70af287](70af287)), closes [#148](#148) [#178](#178) [#148](#148) ### Features * add way to style identifiers ([25677d4](25677d4)), closes [#147](#147) * release 5.1.0 ([cb0c0f1](cb0c0f1)) ### BREAKING CHANGES * The `default` segment has been split into `identifier` and `whitespace` segments. There's also a new `unknown` segment that will only show up for malformed SQL such as an unclosed string. However, the highlight() function works largely the same as before, both normal mode and HTML mode, except for the bug fix to stop classifying identifiers as strings. In other words, SQL like select * from EMP where NAME="John Smith" will get highlighted the same as before, i.e. no syntax highlighting for EMP or NAME. * drop support for Node 14.
# [5.0.0](v4.4.2...v5.0.0) (2024-07-02) * chore!: add support for Node 22 ([9478bf1](9478bf1)) ### Bug Fixes * improve number detection ([02d459a](02d459a)), closes [#149](#149) * improve operator detection ([183a4fb](183a4fb)), closes [#150](#150) * typo in unknown segments ([70af287](70af287)), closes [#148](#148) [#178](#178) [#148](#148) ### Features * add way to style identifiers ([25677d4](25677d4)), closes [#147](#147) ### BREAKING CHANGES * The `default` segment has been split into `identifier` and `whitespace` segments. There's also a new `unknown` segment that will only show up for malformed SQL such as an unclosed string. However, the highlight() function works largely the same as before, both normal mode and HTML mode, except for the bug fix to stop classifying identifiers as strings. In other words, SQL like select * from EMP where NAME="John Smith" will get highlighted the same as before, i.e. no syntax highlighting for EMP or NAME. * drop support for Node 14.
# [6.0.0](v5.0.0...v6.0.0) (2024-07-02) ### Bug Fixes * improve number detection ([02d459a](02d459a)), closes [#149](#149) * improve operator detection ([183a4fb](183a4fb)), closes [#150](#150) * typo in unknown segments ([70af287](70af287)), closes [#148](#148) [#178](#178) [#148](#148) ### Features * add way to style identifiers ([25677d4](25677d4)), closes [#147](#147) * release 5.1.0 ([3a58def](3a58def)) ### BREAKING CHANGES * The `default` segment has been split into `identifier` and `whitespace` segments. There's also a new `unknown` segment that will only show up for malformed SQL such as an unclosed string. However, the highlight() function works largely the same as before, both normal mode and HTML mode, except for the bug fix to stop classifying identifiers as strings. In other words, SQL like select * from EMP where NAME="John Smith" will get highlighted the same as before, i.e. no syntax highlighting for EMP or NAME.
Replace "default" token with "whitespace" and "identifier" tokens, with fallback to "unknown" token.
Also, change backticked identifiers like
`foo`
to be classified as "identifier" rather than "string".This allows for identifiers to be styled independently from strings and whitespace.
It also simplifies getSegments() from 30 lines down to 5, by removing the special-case code for the "default" token.
Fixes #147.