Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel <emacs-devel@gnu.org>,  Manuel Uberti
>>  <manuel.uberti@inventati.org>
>> Date: Sat, 12 Aug 2023 19:10:31 +0000
>> 
>> If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
>> package, from what I see.  From what I recall, the -ts-mode approach was
>> a compromise to add some basic support for Tree Sitter in Emacs 29, but
>> I am not sure if it was a final decision on the matter, because at least
>> from my perspective of following the tree sitter development from a
>> close distance, but also from user reports I have heard of since the
>> release of Emacs 29, the current approach is slightly confusing.  Adding
>> a -ts-mode to ELPA might be misinterpreted as a commitment to the
>> current trajectory, and I am not sure if that is intended.
>
> If you mean that the *-ts-modes could be a minor mode, then I believe
> we found that to be unworkable, except in very rare cases where the
> major mode supporting the same language is very thin and has only a
> couple of simple mode-specific features.  Otherwise, the very
> different way of doing font-lock, indentation, imenu, etc. means that
> basically all the features must be reimplemented anew, and in many
> cases make no sense at all.  So a minor mode is not TRT here.

This was my understanding as well, and while I understand it from a
technical perspective, I have a hunch there must be a tolerable
alternative with a better user interface.

Perhaps this is a point at which the approach at which the major-mode
abstraction breaks down and has to be rethought?  There have been
instances of alternative major modes for different languages in the past
(cperl, perl; js, js2, js3) that have found one way or another to
co-exist, but seeing how this is becoming more and more common, it would
be nice to have some consistent and unified way of expressing these
kinds of alternatives.

> The aspects of these modes that are not yet firmly decided are how to
> activate/deactivate them in a way that would be convenient and simple.
> But I don't think we will be removing the *-ts-modes as major modes,
> no.

I get that we wouldn't want to remove them, out of backwards
compatibility, but is the plan to write more ...-ts-mode major modes?