tree-sitter-elisp
tree-sitter-markdown
tree-sitter-elisp | tree-sitter-markdown | |
---|---|---|
2 | 8 | |
53 | 363 | |
- | 5.2% | |
3.6 | 0.0 | |
12 months ago | about 1 month ago | |
C | C | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
tree-sitter-elisp
-
RMS – EmacsConf Talk
Here is the tree-sitter grammar of Elisp:
https://github.com/Wilfred/tree-sitter-elisp/blob/main/gramm... (approx. 200 lines)
and here is the grammar of JavaScript:
https://github.com/tree-sitter/tree-sitter-javascript/blob/m... (approx. 1200 lines)
JavaScript evolved into a language of similar complexity as Perl 5 (the corresponding tree sitter syntax table counts almost 2000 lines, currently).
-
EmacsConf 2022 Starting Now
> I like the multiprocess approach with standard protocols, despite its complexities, because it lets different editors share smarts.
Yes, the benefit LSP brings is putting editors/IDEs on equal footing with respect to a specific language. Also the multiplicative effect when the author of a new language provides a language server so nobody needs to switch their IDEs to try it out.
However, seeing how „straight forward“ a tree-sitter specific language grammar looks in practice (1) makes we wonder if by providing a TS grammar for a language would realize (almost) the same benefit. Based on such a grammar and TS’ selector engine figuring out a syntax highlighting scheme, code folder, a docstring or symbol scanner might not be such a huge endeavor any more as you described for ENSIME.
So, yeah, in the end LSP might be dead end at some point, especially because TS promises to be very fast and avoids any IPC. Performance seems to be the biggest problem of LSP clients in Emacs and probably other editors as well.
(1) https://github.com/Wilfred/tree-sitter-elisp/blob/main/gramm... — of course, the example being ELISP makes it look easier than said, if you compare it with the grammar of Perl5 that’s not yet finished unsurprisingly.
tree-sitter-markdown
-
How to pass environment variables to treesitter grammar
The markdown treesitter grammar accepts environment variables when building to tweak it's behavior. How can I pass these? Currently I am using
-
Project idea: port markdownlint to Rust
given the existence of tree sitter grammar for markdown, I think it’d be fairly easy to implement the linter on top of it.
-
New(ish) plugin: ts-vimdoc.nvim, generate vimdoc from your README.md for your plugin using tree-sitter
The original repo wasn't working since the move from ikatyang/tree-sitter-markdown to the new markdown parser by /u/deinemade/ MDeiml/tree-sitter-markdown so I kept maintaining it as a fork with the absolute basics just so I could generate the vimdoc for fzf-lua.
-
Any Markdown plugin for Neovim that you recommend?
The new parser https://github.com/MDeiml/tree-sitter-markdown is more stable. And should be installed by default, if not just run :TSInstall markdown
-
Tree-sitter for markdown
Looks like this scanner uses more of the parser generator features of tree-sitter: grammar.json is almost 11k lines of "definitely not easy to maintain (IMHO)" json. Where as ikatyang's version is a hand written parser. tree-sitter is not great for languages that are not deterministic. The benefits for ikatyang is that it is probably easier to maintain, the drawbacks are it can definitely crash neovim (sadly). For these types of syntax, a parser definitely needs to support look ahead and look behind, which tree-sitter does not support. This is just my not-so-computer-science-y theory.
- nvim-treesitter for markdown
-
Comment.nvim <3 Treesitter and some new [chef kiss] stuff
There have been big problems with treesitter Markdown, but the good news is that a brand new version is being worked on and looks like it is going to be awesome! https://github.com/MDeiml/tree-sitter-markdown
What are some alternatives?
emacs-ng - A new approach to Emacs - Including TypeScript, Threading, Async I/O, and WebRender.
vim-pandoc-syntax - pandoc markdown syntax, to be installed alongside vim-pandoc
tree-sitter-javascript - Javascript grammar for tree-sitter
mkdnflow.nvim - Fluent navigation and management of markdown notebooks
go-tree-sitter - Golang bindings for tree-sitter https://github.com/tree-sitter/tree-sitter
marksman - Write Markdown with code assist and intelligence in the comfort of your favourite editor.
tree-sitter-html - HTML grammar for Tree-sitter
nvim - 🍨 Soothing pastel theme for (Neo)vim
tree-sitter-comment - Tree-sitter grammar for comment tags like TODO, FIXME(user).
vimtex - VimTeX: A modern Vim and neovim filetype plugin for LaTeX files.
nvim-treesitter - Nvim Treesitter configurations and abstraction layer
vim-markdown - Markdown Vim Mode