Tree-sitter-elisp Alternatives
Similar projects and alternatives to tree-sitter-elisp
-
-
SurveyJS
JavaScript Form Builder with No-Code UI & Built-In JSON Schema Editor. Keep full control over the data you collect and tailor the form builder’s entire look and feel to your users’ needs. SurveyJS works with React, Angular, Vue 3, and is compatible with any backend or auth system. Learn more.
-
-
-
-
-
-
emacs-package-dev-handbook
An Emacs package development handbook. Built with Emacs, by Emacs package developers, for Emacs package developers.
-
Stream
Stream - Scalable APIs for Chat, Feeds, Moderation, & Video. Stream helps developers build engaging apps that scale to millions with performant and flexible Chat, Feeds, Moderation, and Video APIs and SDKs powered by a global edge network and enterprise-grade infrastructure.
tree-sitter-elisp discussion
tree-sitter-elisp reviews and mentions
-
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.
Stats
Wilfred/tree-sitter-elisp is an open source project licensed under MIT License which is an OSI approved license.
The primary programming language of tree-sitter-elisp is JavaScript.