> Date: Fri, 18 Nov 2022 22:54:49 +0100 > From: Jostein Kjønigsen <jostein@secure.kjonigsen.net> > > I know this has been said before, by people which by far has been > contributing much more than me... But I > still don't think it's a good idea to replace the implementation in existing > major-modes with tree-sitter > implementations, nor selectively activate tree-sitter in major-modes prone to > inhetitence and derivation. > > 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. > > While for the sake of brevity, I'll not diving deeply into this particular > thing, I will say this: A new tree-sitter > based major-mode free of compatibility concerns allowed us to create entirely > new major-modes fixing most > of our existing bugs, faster than we before would be able to fix a single > bug. My personal view is that mixing > existing major-modes with tree-sitter represents absolutely the worst of all > worlds. It maintains all existing > complexities, provides us with very few benefits, and at the same time adds > complexities we didn't use to > have. To me, that's a net negative. > > Somewhat surprising to me, I see this is a somewhat controversial point of > view and not as clear cut a > matter as I would have expected it to be. I realize and respect that final > decisions in these matter might take > some time to mature. Time which given our current approach detracts from the > momentum tree-sitter has > been having. You are looking at this from the POV of developing these features. But we have another vantage point to consider: that of our users. >From their POV, we cannot replace existing modes with completely new and separate implementations, we must provide a migration path which will allow users to decide when and whether they want to switch to the tree-sitter based implementation. This will also allow us to improve the tree-sitter support of the modes by collecting user feedback sooner rather than later. So we decided to have a hybrid approach: in some modes to provide separate implementations, and in others to provide optional features that users can selectively switch on. > Instead of waiting for "every" major-mode to be re-implemented into a > tree-sitter derivative in the > feature/tree-sitter branch before we merge... How about we just accept the > current "core" tree-sitter > implementation as good enough, and consider merging that to git master as is. Here you are preaching to the choir, since the decision to merge soon was already made. And it cannot be otherwise, since the time of cutting the emacs-29 release branch is closing up, and we said 2 months ago that we intend to release Emacs 29 with tree-sitter support.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4