Comments (22)
We’ve just integrated highlights.scm
-based syntax highlighting for Gleam! You may notice slightly faster page load times.
from tree-sitter-gleam.
👋🏻 GitHubber here. We’ve added Gleam support to our roadmap. I can’t make guarantees as to a timeframe, unfortunately, but we’re on the case!
from tree-sitter-gleam.
We'll need tags.scm
queries (see elixir-lang/tree-sitter-elixir#18 and tree-sitter/tree-sitter#1649). Otherwise I think this parser is in great shape :)
I can take a look at adding these, I bet it wouldn't be too tough given how the nodes are structured
from tree-sitter-gleam.
Hi @lpil! Sorry for the delay. As @the-mikedavis said, the parser is in pretty good shape. I have a few items on my shortlist:
- Move
corpus
undertest
(I think this can just be done with no further changes; just an organization item) - Rename
type_constructor*
todata_constructor*
; it's a misnomer as-is
New one:
And also tags.scm
, but it looks like @the-mikedavis got that one 😁
Somewhat related, but I think we should move the canonical version of this repository to under the github.com/gleam-lang organization once those are done, but before we ask for it to be used with GitHub.
I'll post updates here; I'm hoping to get my shortlist done this evening 😁
from tree-sitter-gleam.
@patrickt Great news!
Thanks! I’m glad you’re enjoying it and I’m grateful for your patience.
Though to me it doesn't look quite right. We have lost syntax highlighting for types and constructors, and labels and arguments are two different colours now.
As regards type names, that is technically correct. @type
is defined to map to an smi
CSS class, that in dark mode is meant to map to an uncolored face (see also Java interfaces, which do the same). This is true also for @property
, which, if you prefer argument labels to be highlighted the same as arguments, might not be the right choice. Given that argument labels are a pretty common construct, we could perhaps add a new @property.label
class, if you think it’s too jarring. However, all other things being equal, our team would prefer to keep these highlighted differently so as to be consistent with highlighting for languages that have this distinction such as Swift.
With respect to constructors, I think those should be mapped to the @constructor
highlight, which doesn’t appear to be mentioned in highlights.scm
, so I think that should be fixable on your end.
The orange module names stand out a lot more than I think is ideal too. In this snippet I think they are not very important but they are very bold. Previously they were white, like variables.
I agree it’s pretty loud. Unfortunately, we don’t have any facilities for grammars to direct the manner in which things are highlighted: on our end, it’s basically just a map from highlighting classes to CSS classes (closed-source, unfortunately, though I can give a subject-to-change summary of what is done should you need it). I think it would be cool to allow highlighting grammars to suggest how emphatically or subtly a given class should be highlighted, but that would be a long-term project (as would making the module highlighting a little less punchy, given that we’d have to get input from design, plan for the various colorblindness modes, etc etc). Note that Elixir module names are also highlighted thusly, so at least we’re consistent in our gaudiness. :)
If you’d prefer for us to go back to the old highlighting queries, that’s not a problem on our end (though you will notice some marginally longer page load times).
from tree-sitter-gleam.
Oh, I see that the comment-in-string bug is fixed. I can bump that today.
from tree-sitter-gleam.
Hey @lpil, sorry for the delay! The repository is now at a good point to transition ownership to under the gleam-lang org. Whether you want to fork it to that org or clone-and-push a copy is totally up to you! Once it's over there, I'd love if you could add myself and @the-mikedavis as maintainers of the project, and it should also be ready to provide to GitHub for integration
from tree-sitter-gleam.
Ah, I didn't even think about GitHub having an official mechanism for this!
from tree-sitter-gleam.
FWIW, the general non-highlighting of types (and data constructors/names, which we treat as types for better or for worse) appears to be an issue on GitHub's side. Those use the @type
highlight name, which tree-sitter-rust uses as well (our matching, for comparison), and works well in the tree-sitter based Emacs mode:
We also verify this in some of our highlighting tests.
The "comment in string" bug is real and affects environments other than GitHub. I'll try to run that down this evening.
from tree-sitter-gleam.
The new highlighting queries have been bumped in production.
from tree-sitter-gleam.
I remember transferring a repo to be a bit strange when working on tree-sitter-iex
. Iirc I transferred it to José and then José transferred it to the elixir-lang organization, and doing that way you keep the git history, stars and prs/issues
from tree-sitter-gleam.
To give a small update on this, the string/comment parsing issue appears to be an artifact of parsing strings as non-terminal nodes/tokens, which means that any field in extras
(whitespace, comments) should be able to appear before any child node of the string node.
To counter this, I tried wrapping the string child nodes with token.immediate
, whose documentation states:
Usually, whitespace (and any other extras, such as comments) is optional before each token. This function means that the token will only match if there is no whitespace.
It may truly be specific to whitespace, because it had no effect.
My approach looks like this:
string: ($) =>
seq(
'"',
repeat(choice($.escape_sequence, $.quoted_content)),
token.immediate('"')
),
escape_sequence: ($) => token.immediate(/\\[efnrt\"\\]/),
quoted_content: ($) => token.immediate(/(?:[^\\\"]|\\[^efnrt\"\\])+/),
FWIW, tree-sitter-rust's approach is very similar:
string_literal: $ => seq(
alias(/b?"/, '"'),
repeat(choice(
$.escape_sequence,
$._string_content
)),
token.immediate('"')
),
// ...
escape_sequence: $ => token.immediate(
seq('\\',
choice(
/[^xu]/,
/u[0-9a-fA-F]{4}/,
/u{[0-9a-fA-F]+}/,
/x[0-9a-fA-F]{2}/
)
)),
A notable difference, however, is that tree-sitter-rust's _string_content
anonymous node is implemented as an external scanner, whereas our equivalent (quoted_content
) is implemented in the tree-sitter DSL. I'll attempt to make it an external scanner to see if that makes a difference.
from tree-sitter-gleam.
I forgot to address the property vs argument bit. The TL;DR is
- Labels and the arguments they label aren't the same syntactically, so I believe that there should be an option to highlight them differently. Personally, I find having them highlighted differently to aid readability.
- The same parsing logic and AST nodes are used for arguments to data constructors and arguments to functions. The use of the "property" highlight was born from the former as "property" seemed to fit "the fields of a record/struct" better than anything else.
I'm happy to change what highlight is applied to labels and also to differentiate the highlight for data constructor argument labels vs function argument labels if desired (though I'm not especially fond of that idea), but I do believe that labels and the arguments they point to should be able to be highlighted differently.
from tree-sitter-gleam.
Hi @patrickt , is there a process for updating the grammar on GitHub? Thank you
from tree-sitter-gleam.
All sounds fab to me!
from tree-sitter-gleam.
Hey @lpil! Just wondering if we've reached out to the team at GitHub about adding tree-sitter-gleam functionality to their platform. If not we can cc them here
from tree-sitter-gleam.
Amazing, thank you @patrickt !!
from tree-sitter-gleam.
@patrickt Great news! Though to me it doesn't look quite right. We have lost syntax highlighting for types and constructors, and labels and arguments are two different colours now.
The orange module names stand out a lot more than I think is ideal too. In this snippet I think they are not very important but they are very bold. Previously they were white, like variables.
Is this something we can fix on our end?
from tree-sitter-gleam.
Found a few more places in which syntax highlighting is broken:
Type definitions are no longer highlighted
Strings with //
in them break highlighting
from tree-sitter-gleam.
https://github.com/github/linguist/tree/master/vendor/grammars
I think we may be able to update this here!
from tree-sitter-gleam.
I think the new tree-sitter highlighting/analysis is separate from the linguist configurations and is probably closed-source for now. The grammars in linguist are textmate grammars (regex-based) I believe - for example the Elixir one points at https://github.com/elixir-editors/elixir-tmbundle/blob/b01fffc49179bdec936ca19b53ba4fc7c51a2cc0/Syntaxes/Elixir.tmLanguage although Elixir is highlighted/analyzed with tree-sitter
from tree-sitter-gleam.
Ah boo, I misread and thought they had moved the tree sitters into this repo as well.
from tree-sitter-gleam.
Related Issues (20)
- Add child nodes for the contents of a string? HOT 1
- Add visibility and opacity modifiers
- refactor named nodes within bit-string options? HOT 1
- Function name sometimes not highlighted HOT 1
- Parsing fails after float ending with `.`
- Highlighting broken in gleam/test/language HOT 8
- Update for Gleam v0.24's <> operator HOT 3
- would it be possible to have names tagged for consnt/fn on the future (as types are now) ? HOT 1
- Update for new `use` feature
- Support scientific notation for floats HOT 1
- Support `panic` and `let assert` HOT 4
- use expressions now support patterns
- Parser changes HOT 2
- Add support for annotating argument in use() syntax HOT 2
- Indentation with case statements HOT 5
- New attribute syntax
- New external type syntax
- New todo and panic message syntax
- `#is-not? local` query cannot extend inference to multiple nodes HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tree-sitter-gleam.