Submit to GNU ELPA

[phil-s]

Hi. Thanks for this; it sounds neat.

It aims to be the foundation for a new breed of Emacs packages that understand code structurally.

TODOs
Submit to MELPA.

With the above in mind, please do consider putting this in GNU ELPA so that all package authors can use it? It would be a shame to limit its usefulness as a dependency to MELPA packages only.

[ubolonton]

I want to submit it to MELPA first, since it's easier, but eventually I'll submit to both.

[shackra]

@ubolonton why is it easier?

OH, I see why. https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

a package author would depend on some Emacs maintainer to push through any package to GNU ELPA, having those extra steps makes things hard indeed.

[Ergus]

Adding a package to elpa is not a difficult process at all. The slow step is usually to collect the Copyright Assignment for all the developers who contributed to the package. But the process itself is actually very simple (just send a couple of emails).

https://www.gnu.org/software/emacs/manual/html_node/emacs/Copyright-Assignment.html

But after that, it is very simple; and the maintainers offer their help if you need it, either to submit to elpa or anything else. If you need any help, feel free to email emacs-devel@gnu.org and/or join to the mailing list.

BTW: Very recently it was added also the non-gnu repository for packages that is not possible to collect the copyright. Joining to Elpa is still preferred, but some huge packages like magit it is virtually impossible to coordinate all the developers to do the assignment process.

[shackra]

@ubolonton coming back to this, I did all the paper work to give the copyright assignment to the FSF so this project can be included in GNU ELPA. What about you? People that make non-trivial contributions should make their paper work so later pushing this to GNU ELPA becomes legally trivial.

[leungbk]

This seems like the kind of project that ought to be included in Emacs core once it's stabilized; the last thing Emacs needs is a deeper chasm between the OOB and the batteries-included experiences. But I've heard that the Rust toolchain is distributed under terms incompatible with Emacs' license. If that's the case, is it still eligible for Elpa?

People that make non-trivial contributions should make their paper work so later pushing this to GNU ELPA becomes legally trivial.

I heard the other day that use-package being merged into core is presently stalled because they're waiting on only a couple of people who haven't submitted their papers. So it's better to enforce this kind of thing sooner rather than later for Elpa.

[leungbk]

Putting aside the need for contributors to sign the papers, the Emacs maintainers are averse to stuff released under "pushover" licenses. This is a problem since Rust requires LLVM, which is released under one such license.

It seems to me that including this in Elpa would, at minimum, require that we develop our own clean-room + non-Rust tool for compiling the grammars, since tree-sitter-cli is written in Rust. It might also be necessary to write our own highlighting queries since we don't presently own the copyright assignment to the highlighting queries in this repo. I am not a legal expert, so I can't be sure of this. What do you think @ubolonton @shackra?

[shackra]

Putting aside the need for contributors to sign the papers, the Emacs maintainers are averse to stuff released under "pushover" licenses. This is a problem since Rust requires LLVM, which is released under one such license.

It seems to me that including this in Elpa would, at minimum, require that we develop our own clean-room + non-Rust tool for compiling the grammars, since tree-sitter-cli is written in Rust. It might also be necessary to write our own grammars since we don't presently own the copyright assignment to the grammars in this repo. I am not a legal expert, so I can't be sure of this. What do you think @ubolonton @shackra?

We aren't releasing Rust to Elpa or anything, anything compiled with Rust —or LLVM for that matter— don't inherit its licensing anymore that a piece of code compiled with GCC has.

I'm not a lawyer neither, but that's how I intuitively see it.

[leungbk]

anything compiled with Rust —or LLVM for that matter— don't inherit its licensing anymore that a piece of code compiled with GCC has.

Of the two concerns I brought up in my last post, the first one (which is what I think you were responding to here) was more of a political dispute among the maintainers than a legal dispute (which is what my second concern was, though having to write our own queries isn't necessarily that bad)---I don't disagree that LLVM-compiled stuff need not be released under the same license as LLVM itself. There shouldn't be a legal reason that the FSF cannot accept an emacs-tree-sitter that uses Rust.

I suspect that what some of the Emacs maintainers fear is that by requiring (say) LLVM in core Emacs, they are promoting software released under pushover licenses, which has the effect of indirectly helping anyone who wants to snarf LLVM code for their own proprietary software. Whenever this hypothetical Emacs exposes an LLVM-related bug, there is likely to be someone who reports it upstream and helps the LLVM project, as well as those who use its code in proprietary stuff. The FSF seems to view this as a net loss for freedom.

[Ergus]

Hi:

I didn't see this discussion before... I just opened an issue (feel free to close it).

There is no legal/licensing issue integrating tree-sitter with emacs, actually it has been discussed very recently in the develop mailing list and is of much interest of the developers to have smarter experience with lsp and tree-sitter integration in the near future.

Look: https://lists.gnu.org/archive/html/emacs-devel/2021-06/threads.html

The thread: cc-mode fontification feels random.

The addition of this package to elpa and your potential integration/help/contribution into the development to add tree-sitter support in vanilla y very desired. Adding this package to Elpa is a very good first step.

Your help may benefit very much as it will be possible to add/improve/fix emacs internal features you probably need for the package. Or, if you prefer, integrate the package directly in the display engine which may be more efficient. It looks like Eli and Stefan are interested on this so they will help for sure if you want.

[shackra]

@ubolonton you were ping'd here https://lists.gnu.org/archive/html/emacs-devel/2021-06/msg00177.html