Hey everyone.
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.
At this point poor Yuan Fu here has spent quite a bit of time and
effort getting a core tree-sitter interface into Emacs. I would
really hate to see all that effort be for nothing, because we end
up conflating a creating a core tree-sitter feature with how this
feature should best be employed in subsequent major-modes.
So in the name of pragmatism, I propose a compromise of sorts.
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.
This will allow us to land one important mile-stone, while giving us the head-room to further discuss how we should best implement/reimplement/"upgrade" existing major-modes to take advantage of tree-sitter.
It will also allow third-party packages to make use of
tree-sitter in Emacs core instead coming up with its own
implementation, beginning a defacto standardization of this new
API (which I may note already has a competing implementation in
MELPA).
That is to say: We should land the core library, with holding it
hostage to all its possible consumers being implemented.
How about it? Are there any good arguments for NOT merging
feature/tree-sitter at this point? :)
So I’m trying to merge css-ts-mode with css-mode. Scss-mode inherits css-mode, but if user enables tree-sitter for css-mode, scss-mode will inherit all that tree-sitter setup, and lose all the native css setup. Then if a user doesn’t want to enable tree-sitter in scss-mode, too bad: scss-mode breaks. Essentially scss-mode needs to be able to control which parts of css-mode’s setup it wants to inherit—native setup or tree-sitter setup—regardless of whether css-mode enables tree-sitter or not. I wonder if we can do something like this: css-mode | +---------+-----+-----------+ | | | css-native-mode css-ts-mode scss-mode | +----+------------+ | | scss-native-mode scss-ts-mode css-mode: a virtual mode, only sets up basic things that both native and tree-sitter mode needs, like comment-start. css-native-mode: native setup css-ts-mode: tree-sitter setup scss-mode: a virtual mode, inherits css-mode scss-native-mode: native setup scss-ts-mode: tree-sitter setup And user could use major-mode-remap-alist to choose which mode they want: (css-mode . css-ts-mode) for enabling tree-sitter (css-mode . css-native-mode) for not enabling tree-sitter This could also used for other modes, like c-mode: c-mode, c-native-mode (cc-mode), c-ts-mode. Yuan