Skip to content
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

[question] future plans #7

Closed
yyoncho opened this issue Sep 3, 2019 · 4 comments
Closed

[question] future plans #7

yyoncho opened this issue Sep 3, 2019 · 4 comments

Comments

@yyoncho
Copy link

yyoncho commented Sep 3, 2019

After implementing highlights what are your plans for the emacs-tree-sitter?

I am particularly interested in implementing operations over the AST in the spirit of smartparens/paredit.

@ubolonton
Copy link
Collaborator

In addition to highlighting, I want to first focus on packaging, so it can be distributed without requiring others to build from source.

After that, I'm thinking about making a new language major mode that relies entirely on tree-sitter (instead of regexes), both as an experimentation, and as a reference for others to start using tree-sitter. My first choice right now would be a replacement for terraform-mode, with code navigation (using tree-sitter to build a project-wide index).

I am particularly interested in implementing operations over the AST in the spirit of smartparens/paredit.

This is a cool idea, but I think trying to make a generic implementation right away is pretty hard. For each non-Lisp language, the types of node that these smart operations should act on would be different, and the set of interesting operations may be different as well. In addition to some core logic, there would be language-specific stuff (which may be made to be declarative, similar to how Atom uses CSS to map nodes to highlighting classes). IMO, experimenting with language-specific structural editing modes first will make it easier to define a generalized core.

@yyoncho
Copy link
Author

yyoncho commented Sep 7, 2019

For each non-Lisp language, the types of node that these smart operations should act on would be different, and the set of interesting operations may be different as well. In addition to some core logic, there would be language-specific stuff (which may be made to be declarative, similar to how Atom uses CSS to map nodes to highlighting classes). IMO, experimenting with language-specific structural editing modes first will make it easier to define a generalized core.

Yes, this is exactly what I am looking for. If you don't mind I would like to put some effort into that. Please let me know whether you want that to be part of this project/repo or in a separate one.

@yyoncho
Copy link
Author

yyoncho commented Sep 7, 2019

After that, I'm thinking about making a new language major mode that relies entirely on tree-sitter (instead of regexes), both as an experimentation, and as a reference for others to start using tree-sitter.

I think that at some point there could be a generic mode which uses tree-sitter for highlighting and language server for semantic highlights.

See emacs-lsp/lsp-mode#999

@yyoncho yyoncho closed this as completed Sep 7, 2019
@ubolonton
Copy link
Collaborator

If you don't mind I would like to put some effort into that.

Yeah sure, that would be great!

Please let me know whether you want that to be part of this project/repo or in a separate one.

I think a separate repo is better, as it would have more freedom for experimentation. Just let me know if you need help with the APIs, or have suggestions on adding more core functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants