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

tree-sitter support #494

Closed
wingyplus opened this issue Oct 17, 2022 · 8 comments
Closed

tree-sitter support #494

wingyplus opened this issue Oct 17, 2022 · 8 comments

Comments

@wingyplus
Copy link
Contributor

In upcoming emacs (29) they start supporting tree-sitter natively (not a separate package). It would be great if we supporting it. We already have tree-sitter-elixir https://github.com/elixir-lang/tree-sitter-elixir. And have someone already explore on tree-sitter emacs elixir-lang/tree-sitter-elixir#4 (comment).

@victorolinasc
Copy link
Contributor

I think all the current contributors of emacs-elixir agrees this is a mostly welcome addition. We plan to support that and @wkirschbaum has already started implementing a version of it.

Things to consider here currently (2022-10-19):

  • support is still a moving target with almost daily changes to the interface of tree-sitter in Emacs;
  • this is still a feature branch. That means it still isn't part of Emacs master and therefore, still not set for Emacs 29 (although clearly the maintainers want it to be merged);
  • we should always consider that tree-sitter, as it is currently planned, COULD not be enabled in an Emacs installation. That means we shouldn't, IMHO, remove current SMIE support.

Either way, this is certainly a great addition and will most likely provide a better developing experience.

@victorolinasc
Copy link
Contributor

Giving some update here.

  • the branch is merged and will soon be released on Emacs 29.1. This just means the API is more stable now.
  • the approach chosen by the Emacs maintainers is to have separate modes for each language. This means we will probably NOT update this mode in order to add tree-sitter
  • @wkirschbaum has an awesome implementation ready already for elixir-ts-mode. He might even propose it to core emacs for 30.
  • this mode MIGHT enter maintenance mode after Emacs 29.1 is released as it will be probably just the fallback mode and not the main mode anymore.
  • we should note about all this in an update to the README

This is my take here. Please, chime in with your comments if this seems like a fair plan.

Thanks you all!

@wkirschbaum
Copy link
Contributor

@victorolinasc elixir-ts-mode is already in core emacs, but only for 30. I actually started maintaining the mode on emacs core as an upstream.. I am also strongly considering adding a lightweight elixir-mode to core emacs later this year... but need to think about how and what this might mean.

elixir-ts-mode is in most popular support packages as well and should just work out of the box ( please log a bug if i missed one ).

@wkirschbaum
Copy link
Contributor

the idea is to get elixir work as close to out of the box as possible with emacs with stable features, then have perhaps this or another package with fancier stuff. 🤷🏻. i have a elixir-compile-mode i want to add somewhere, but not sure where yet.

@wkirschbaum
Copy link
Contributor

And I had some fun yesterday with Mitchell adding the credo language server to lsp-mode: emacs-lsp/lsp-mode#4068

@victorolinasc
Copy link
Contributor

That is awesome @wkirschbaum ! Thanks a lot for your work here :) I've been using elixir-ts-mode and it is shining. Much appreciated work here :)

I think we should, then, open an issue discussing a vision for Elixir in Emacs from here on out. My guess is that we think a bit alike here but it would be great to collect more feedback on how we should organize things in several projects.

It was suggested before to have a package that would:

  • add mix project awareness (how to detect if in a project, in an umbrella and so on)
  • add mix tasks calling
  • add exunit integration
  • add some specialized buffers (like xref, eprof and so on would be nice)
  • etc...

Wdyt? We should re-up #465 there with a comment :)

@wkirschbaum
Copy link
Contributor

@victorolinasc happy people are using it, lots to do still. specialized buffers would be nice.

@victorolinasc
Copy link
Contributor

I will be closing this issue for now. We might change the readme to reflect things discussed here. If anyone wants to write and open a PR it would be greatly appreciated.

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

No branches or pull requests

3 participants