-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Introduce new syntax highlighting stdlib #51810
Introduce new syntax highlighting stdlib #51810
Conversation
I imagine there's going to be some bikeshedding of the highlight rules in https://github.com/JuliaLang/JuliaSyntaxHighlighting.jl/blob/main/src/JuliaSyntaxHighlighting.jl 🙂 To kick things off, here's a screenshot of what the current scheme looks like: That said, if the basic idea/system here looks ok, we could also merge this pre-styling-bikeshedding so that bikeshedding can occur concurrently with usage in |
CI failure seems to be because tests are expected which is ... entirely reasonable. I just thought I'd wait for initial comments before adding tests. |
5368f89
to
5a46a57
Compare
Ideally, this and the Julia vscode extension would use the same formatting backend (calling out julia-vscode for special attention because it is the most popular Julia editing environment) I think this is the current source of truth for syntax highlighting in julia-vscode cc @pfitzseb If the approach in JuliaSyntaxHighlighting.jl is vastly simpler than the one in julia-vscode and julia-vscode can't depend on Julia for syntax highlighting, then I suppose we may have to keep then separate. Even then I would lean toward exactly mimicking the VSCode extension's formatting choices, at least at first. Also, stdlibs should have CI. Those aside, and this lgtm. I definitely support the overall direction of adding syntax highlighting as a stdlib. If REPL ever stops being a stdlib, then this can go with it. @vchuravy, are there any steps we should take to make this stdlib "free" or does that happen by default? |
The VS Code extension can additionally support highlighting provided by the language server, but that can't be the only source for highlighting. A simple regex based grammar is still required as a baseline (note that the repo you linked also powers syntax highlighting on GitHub). It's also worth noting that the textmate grammar emits more fine grained scopes than JuliaSyntaxHighlighting.jl does currently, e.g. Regarding the styling in that screenshot: Generally looks really good to me, but the |
Thanks, Sebastian. I'm not familiar with the VS Code extension, so I appreciate hearing from somebody who is when it's referenced.
I'll see if we can get relation-ness of operators from JuliaSyntax. Macro-specific highlighting seems like it could be possible, but might be something to work on after merging this initial version (and is something I think would be nice with
Could you elaborate on unfortunate? |
I'm not saying we should do that, FWIW. And if we do, not sure if it's worth looking at the scopes used in the textmate grammar, because those are very arbitrary and organically grown.
I'd want the |
Ah yes, this has actually slightly bugged me too. I'll give it another look. |
Oh, I see you actually referenced the type relation category, is that perhaps for |
Yes, it is. Generally, the textmate grammar has more specificity. If you scroll down a bit, you'll see But yeah, as I said before: I don't suggest following atom-language-julia's example here (at least when it comes to the actual implementation). |
@@ -4,9 +4,9 @@ STDLIBS_WITHIN_SYSIMG := \ | |||
|
|||
INDEPENDENT_STDLIBS := \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LilithHafner to answer your question. As long as the stdlib is here it is "free", but not yet upgrade-able.
Upgrade-able requires registering in the Registry and Pkg allowing it to update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Is there anything that should be done on the JuliaSyntaxHighlighting side of things to enable Pkg to allow it to upgrade?
Currently listed CI failures seem spurious (https://buildkite.com/julialang/julia-master/builds/29086), I'll try updating the branch to see if that changes. |
5a46a57
to
ec9b978
Compare
Ok, beyond the particular syntax highlighting rules (which I think we can discuss and refine further in the stdlib?), are there any larger aspects to this that need to be discussed/reviewed at this stage? |
Ironic combination of issues:
|
Having this as a standard library allows for syntax highlighting to be used in the Markdown and REPL standard libraries. As a bonus, this provides an easy and canonical way of obtaining syntax highlighted code across the ecosystem.
ec9b978
to
67f5e9b
Compare
I've just updated the stdlib to have some basic docs and tests. |
CI failure looks unrelated. |
I don't think there's anything holding this back now? Might anybody be able to spare the time to review this for merging? |
🥳 thanks a lot Lilith, it's great to see some movement on #50817 again 😀 |
Happily! Ideally the stdlib should have CI (JuliaLang/JuliaSyntaxHighlighting.jl#1), which I think is why I didn't merge this last time I glanced at it. However,
|
Yea, CI on the repo itself and a build of the docs would be nice to have, I just didn't think they were a barrier to merging. |
Having this as a standard library allows for syntax highlighting to be used in the Markdown and REPL standard libraries. As a bonus, this provides an easy and canonical way of obtaining syntax highlighted code across the ecosystem.
This is a pretty tiny library, at just ~150 lines, but a useful one.