Highlight (some) regular expressions using another grammar #11
Comments
No an issue is fine. I don't even get notifications from discussions lol. This is a good idea. Clojure uses java flavored regular expressions. I'm not sure how much they are different from that grammar. If it is it might be worth forking and calling it |
|
I don't have the various flavors loaded into my head lately [1]. If I had to guess without looking too closely, I think this is likely to be some JavaScript flavor (or subset of one). I also don't know / recall whether the various Clojure dialects all support the same regex syntax. Perhaps this might come in handy eventually. [1] Mostly working with PEGs in another language ;) |
|
Came across this content among Lapce's files: |
This grammar is bundled in nixos by default and seems good enough for java regular expressions (the grammar probably supports more features than java, idk). Should address issue #11
This grammar is bundled in nixos by default and seems good enough for java regular expressions. It is also maintained under the tree-sitter github org so is "official". In order to property identify the #" and closing " characters we have to parse them with the clojure grammar (in case the regex grammar is not available) and again with the regex grammar as part of the actual pattern. This could be avoided if either the clojure grammar captured a node for the inner contents of the regex literal, or the treesit-range-settings supported some kind of offest argument like the neovim tree-sitter mechanisms do. Should address issue #11
|
Thanks for the heads up! Hope to take a look soon. |
|
Ok, I gave it a try. I see about capturing
|
|
On a side note, may be it's worth requesting that tree-sitter-regex get added to tree-sitter-module? |
This grammar is bundled in nixos by default and seems good enough for java regular expressions. It is also maintained under the tree-sitter github org so is "official". In order to property identify the #" and closing " characters we have to parse them with the clojure grammar (in case the regex grammar is not available) and again with the regex grammar as part of the actual pattern. This could be avoided if either the clojure grammar captured a node for the inner contents of the regex literal, or the treesit-range-settings supported some kind of offest argument like the neovim tree-sitter mechanisms do. Should address issue #11
This grammar is bundled in nixos by default and seems good enough for java regular expressions. It is also maintained under the tree-sitter github org so is "official". In order to property identify the #" and closing " characters we have to parse them with the clojure grammar (in case the regex grammar is not available) and again with the regex grammar as part of the actual pattern. This could be avoided if either the clojure grammar captured a node for the inner contents of the regex literal, or the treesit-range-settings supported some kind of offest argument like the neovim tree-sitter mechanisms do. Should address issue #11
This grammar is bundled in nixos by default and seems good enough for java regular expressions. It is also maintained under the tree-sitter github org so is "official". In order to property identify the #" and closing " characters we have to parse them with the clojure grammar (in case the regex grammar is not available) and again with the regex grammar as part of the actual pattern. This could be avoided if either the clojure grammar captured a node for the inner contents of the regex literal, or the treesit-range-settings supported some kind of offest argument like the neovim tree-sitter mechanisms do. Should address issue #11 I think that multiple parsers per buffer may be too buggy to use right now. There are situations where no regex will be present on in a buffer, but the entire buffer will be highlighted as a regular expression. This functionality probably needs upstream work in Emacs before we can merge this into the main branch of clojure-ts-mode
|
@rrudakov Perhaps we can apply your learnings from the |
I think the biggest issue here is to find a proper grammar. The grammar mentioned in the discussion supports PCRE2, POSIX and JavaScript regexps, I'm not sure that any of those is fully compatible with Java regexps. One difference I can think of is using of double backslashes in Java. If we find a grammar, adding a new parser and syntax highlighting is pretty straightforward. |
|
I think PCRE2 will work well for our case, as if I recall correctly Java's regular expressions were derived from Perl 5. We'll have to check this, though. |
it works pretty well. We need to decide what do we want to highlight and which faces to use for different elements (I'm not a designer and I'm not a regex expert :) ). The possibilities for syntax highlighting are endless (see the syntax tree on the right buffer). |
With dark color scheme. |
|
There is also an issue in Emacs. When local parsers are used, It's reported to Emacs bug tracker: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77848 |
This looks good to me. I was going to suggest to focus on match groups, character classes, escapes, anchors and modifiers and I guess that's what you did. |
The bug is fixed on Emacs master. On Emacs 30 the |
I saw the following bit in the emacs-devel archives:
As an idea for "somewhere down the line", perhaps it would be interesting to consider the following...
Since tree-sitter-clojure can recognize regex literals, may be one could apply an appropriate regular expression grammar to highlight the portions within the double quotes.
I don't know how close this grammar is to Clojure's flavor of regex, but may be it or some appropriate modification to it (or something that inherits from it) might be used for the task.
For reference, the part of the manual being referred to in the quote above can be see in
.texiform here. I didn't manage to find an HTML version. If you've got a recent enough Emacs from the emacs-29 branch, the info may be viewable from within emacs. Worked for me anyway...Ah sorry. May be I should have made this in the Discussions area?
The text was updated successfully, but these errors were encountered: