From: Philip Kaludercic <philipk@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: jostein@secure.kjonigsen.net, casouri@gmail.com,
emacs-devel@gnu.org, theo@thornhill.no, jostein@kjonigsen.net
Subject: Re: Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance)
Date: Sat, 19 Nov 2022 12:15:10 +0000 [thread overview]
Message-ID: <87fsef3zu9.fsf@posteo.net> (raw)
In-Reply-To: <83pmdj89cf.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Nov 2022 13:36:16 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: jostein@secure.kjonigsen.net, casouri@gmail.com, emacs-devel@gnu.org,
>> theo@thornhill.no, jostein@kjonigsen.net
>> Date: Sat, 19 Nov 2022 10:46:41 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > From where I stand, it makes very little sense to release Emacs 29
>> > with tree-sitter support that is limited to primitives and some
>> > minimal Lisp glue on top of that. Tree-sitter was added to Emacs to
>> > allow major modes provide better support for editing program source
>> > code, so having tree-sitter "support" in Emacs 29 that didn't include
>> > at least several major modes using it would be disappointing at best.
>> > It would mean we ourselves have no idea how to make major modes use
>> > the feature. Moreover, adding those few major modes on the branch
>> > exposed several deficiencies in the original design and
>> > implementation, and required changes to make the integration better;
>> > releasing Emacs 29 with those issues unresolved (and unknown) would
>> > require significant, sometimes incompatible changes in the future,
>> > which is another reason why it would be wrong.
>> >
>> > Basically, my firm belief is that adding to Emacs infrastructure
>> > without user-level applications built on that infrastructure is wrong
>> > and runs the risk of producing features that are not used or need deep
>> > surgery before they become useful. We should avoid doing that as much
>> > as possible.
>>
>> My question is, do these user-level applications have to be distributed
>> along with Emacs, or could they be made to be "explicitly" opt-in by
>> installing them from ELPA.
>
> It depends, the decision should be on a case by case basis, IMO. For
> functionality that is part of what we want Emacs to have, yes, it
> should be distributed with Emacs.
>
>> In-core appears to usually bring a commitment to maintain a library,
>> and deprecating can take years. If Emacs 29 lays the technical
>> foundations, the low-level API for treesitter to work, we can have
>> packages on ELPA experiment with the higher-level abstractions.
>> Whatever is the most successful approach, can be added to Emacs
>> later on.
>
> Emacs cannot come without support for important programming languages,
> that would make no sense. If we want to move towards tree-sitter as
> the basis for some aspects of such major modes, we must have this in
> core. Having such important parts of Emacs in ELPA when we don't have
> a way of bundling ELPA packages with an Emacs release tarball means a
> deficiency in released versions of Emacs, so we should not go that
> way.
>
> I don't see why what was done on the branch with introducing
> tree-sitter capabilities into major modes should be considered
> "experiments", let alone not "successful". What parts of that
> concretely do you think belong to these categories, and why?
>
> More generally, why should we be afraid of including new stuff in
> Emacs, and instead designate it "experimental" and put it on ELPA? We
> never did that in the past, and I don't see why would we want that now
> or in the future. ELPA is not a platform for "experiments" in Emacs
> development; the master branch and the feature branches are that
> platform.
>
>> >> As an aside: This might also be a good opportunity to clean up some of
>> >> the current major mode implementations and make them more consistent.
>> >> The issue with custom options to enable tree-sitter for every major mode
>> >> has revealed an inherent duplication of features. There are other
>> >> inconsistencies, especially regarding bindings for equivalent operations
>> >> (e.g. in interpreted language with a repl, how to load function into the
>> >> current session: Lisp, Prolog, Python all differ in minor details).
>> >
>> > Cleaning up major modes is a Good Thing that needs no opportunities.
>> > We should do that whenever we know and agree how.
>>
>> Fair enough, but just as above I think these kinds of experiments are
>> better made outside of the core, in ELPA, to avoid committing to
>> mistakes. If it works out, it can be added.
>
> No, we should do that on feature branches, not on ELPA. Certainly so
> for changes that require changes on the C level.
>
> Again, ELPA is not a place where we should develop Emacs.
>
>> >> The current branch has major modes, should these be deleted before
>> >> merging?
>> >
>> > Definitely not! These modes are there because we want Emacs 29 to
>> > have them, and we want users to use them and report back.
>>
>> IIUC these modes aren't ripe yet, or at least aren't satisfying
>> replacements for the existing modes.
>
> What concretely isn't ripe?
Jostein said:
Me and Theodor faced these same issues with "our" C# and TypeScript
major-modes, and the only "clean" way we agreed we could make this
work was to create wholly new implementations. I can come up with many
good, objective reasons for this, but I think Theodor has already
represented this view fairly well.
> And please note that Emacs 29 won't be released tomorrow or the next
> week. We have the whole release cycle ahead of us to figure out what
> is not yet ripe for a release and either fix that or (in extreme
> cases) remove that from Emacs. I see no reason to make these
> decisions today. We used the feature branch for initial shakeup and
> stabilization, and we now think the tree-sitter support is mature
> enough to let more people use it and provide their feedback.
Naturally, I didn't understand this to be a discussion on an immediate
decision.
>> If tree-sitter were not to be merged for that reason, that would
>> delay the ability to use tree-sitter on a widespread basis for at
>> least another release. My proposal above would make it possible,
>> and encourage users to report on their experience, while allowing
>> for the flexibility to make the right decisions in the long term.
>
> If that was your reasoning, then I think you are three steps ahead of
> where we are, and you are trying to find solutions for problems that
> don't necessarily exist. We should see what concrete problems are
> left after the merge, and take it from there. We have ample time for
> figuring that out and fixing whatever will need fixing.
You are right, I'll have to test the branch more seriously.
next prev parent reply other threads:[~2022-11-19 12:15 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 20:45 Tree-sitter and major mode inheritance Yuan Fu
2022-11-18 21:54 ` Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance) Jostein Kjønigsen
2022-11-18 22:34 ` Philip Kaludercic
2022-11-18 22:58 ` Yuan Fu
2022-11-18 23:36 ` Stefan Monnier
2022-11-19 7:09 ` Philip Kaludercic
2022-11-19 14:07 ` Standardized access to a REPL (was: Suggesting that feature/tree-sitter be merged) Stefan Monnier
2022-11-19 15:03 ` Standardized access to a REPL Philip Kaludercic
2022-11-19 16:07 ` Stefan Monnier
2022-11-19 16:10 ` Philip Kaludercic
2022-11-19 16:18 ` Eli Zaretskii
2022-11-19 22:31 ` Stefan Monnier
2022-11-20 9:25 ` Philip Kaludercic
2022-11-19 8:29 ` Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance) Eli Zaretskii
2022-11-19 10:46 ` Philip Kaludercic
2022-11-19 11:36 ` Eli Zaretskii
2022-11-19 12:15 ` Philip Kaludercic [this message]
2022-11-19 13:05 ` Eli Zaretskii
2022-11-19 21:34 ` Dmitry Gutov
2022-11-18 22:52 ` Yuan Fu
2022-11-19 5:21 ` Theodor Thornhill
2022-11-19 18:35 ` Eli Zaretskii
2022-11-19 18:46 ` Theodor Thornhill
2022-11-19 18:51 ` Eli Zaretskii
2022-11-19 18:59 ` Theodor Thornhill
2022-11-19 7:36 ` Stefan Kangas
2022-11-19 8:09 ` Eli Zaretskii
2022-11-19 11:25 ` Stefan Kangas
2022-11-19 11:49 ` Theodor Thornhill
2022-11-19 12:03 ` Eli Zaretskii
2022-11-19 8:16 ` Eli Zaretskii
2022-11-19 9:41 ` Tree-sitter and major mode inheritance Yuan Fu
2022-11-19 10:26 ` Eli Zaretskii
2022-11-19 10:29 ` Po Lu
2022-11-19 15:19 ` Stefan Monnier
2022-11-19 17:17 ` Yuan Fu
2022-11-19 17:52 ` Eli Zaretskii
2022-11-19 21:45 ` Yuan Fu
2022-11-20 7:05 ` Eli Zaretskii
2022-11-20 0:38 ` Po Lu
2022-11-19 21:39 ` Dmitry Gutov
2022-11-19 21:49 ` Yuan Fu
2022-11-19 22:03 ` Dmitry Gutov
2022-11-19 22:36 ` Dmitry Gutov
2022-11-19 23:36 ` Yuan Fu
2022-11-19 23:42 ` Dmitry Gutov
2022-11-20 7:28 ` Eli Zaretskii
2022-11-20 13:22 ` Dmitry Gutov
2022-11-20 14:49 ` Eli Zaretskii
2022-11-20 15:24 ` Dmitry Gutov
2022-11-20 7:11 ` Eli Zaretskii
2022-11-20 9:19 ` Yuan Fu
2022-11-20 10:02 ` Eli Zaretskii
2022-11-20 22:57 ` Yuan Fu
2022-11-20 7:05 ` Eli Zaretskii
2022-11-20 17:12 ` Dmitry Gutov
2022-11-20 17:34 ` Eli Zaretskii
2022-11-20 6:51 ` Eli Zaretskii
2022-11-20 12:45 ` Dmitry Gutov
2022-11-20 14:42 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fsef3zu9.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jostein@kjonigsen.net \
--cc=jostein@secure.kjonigsen.net \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).