GNU bug report logs - #59251
29.0.50; Fix-some-inconsistencies-in-ts-modes

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59251 in the body.
You can then email your comments to 59251 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Theodor Thornhill <theo <at> thornhill.no>
To: bug-gnu-emacs <at> gnu.org
Cc: casouri <at> gmail.com
Subject: 29.0.50; Fix-some-inconsistencies-in-ts-modes
Date: Sun, 13 Nov 2022 21:42:19 +0100

[Message part 1 (text/plain, inline)]

Hi Yuan!

I've make some changes to my *-ts-modes, and would appreciate a second
opinion as well as a push to the feature/tree-sitter branch :-)

I've extracted some of the relevant mode-init variables into defcustoms
so that users can tweak their behavior.  It also seems I forgot some
electric indent configs in some of the other files, so I added that
aswell.

BTW, should we do the same thing we did with js-mode - add a js-ts-mode
and don't change the js.el file at all?  We could either go the same
route as c-ts-mode, where we define both c and c++ in the same file, or
keep them separate.  What do you think?

Theo

[0001-Fix-some-inconsistencies-in-ts-modes.patch (text/x-diff, attachment)]

Message #8 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Theodor Thornhill <theo <at> thornhill.no>
To: 59251 <at> debbugs.gnu.org
Subject: Re: bug#59251: Acknowledgement (29.0.50;
 Fix-some-inconsistencies-in-ts-modes)
Date: Sun, 13 Nov 2022 23:16:44 +0100

[Message part 1 (text/plain, inline)]

Added a few more finishes.

Theo

[0001-Fix-some-inconsistencies-in-ts-modes.patch (text/x-diff, attachment)]

Message #11 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Theodor Thornhill <theo <at> thornhill.no>
To: 59251 <at> debbugs.gnu.org
Subject: Re: bug#59251: Acknowledgement (29.0.50;
 Fix-some-inconsistencies-in-ts-modes)
Date: Mon, 14 Nov 2022 00:01:47 +0100

[Message part 1 (text/plain, inline)]

Theodor Thornhill <theo <at> thornhill.no> writes:

> Added a few more finishes.

Aaand another.  Last one for now.  I promise...

Theo

[0001-Fix-some-inconsistencies-in-ts-modes.patch (text/x-diff, attachment)]

Message #14 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59251 <at> debbugs.gnu.org
Subject: Re: bug#59251: Acknowledgement (29.0.50;
 Fix-some-inconsistencies-in-ts-modes)
Date: Sun, 13 Nov 2022 16:51:52 -0800

> On Nov 13, 2022, at 3:01 PM, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
> 
> Theodor Thornhill <theo <at> thornhill.no> writes:
> 
>> Added a few more finishes.
> 
> Aaand another.  Last one for now.  I promise…

Cool! Some comments:

+(defcustom c-ts-mode-font-lock-feature-list
+  '((comment preprocessor operator constant string literal keyword)
+    (type definition expression statement)
+    ())
+  "Language constructs to font-lock.
+
+See `treesit-font-lock-feature-list' for description of how to
+use this variable.  Supported features are as defined in
+`c-ts-mode--font-lock-settings'."
+  :version "29.1"
+  :type 'list
+  :safe 'listp
+  :group 'c)
+

I think Stefan M’s opinion is to make feature-list private, and let users add/remove features. Right now they can add/remove features with treesit-recompute-feature-list. I guess we can keep them as defvar’s for now, so people as the option to redefine this list should they want to. (One argument against having them as custom options is that, if a user sets it as a custom option, they will miss out on future changes to this variable.)


+  (setq-local comment-style c-ts-mode-comment-style)

Why don’t we let users set comment style themselves? Does cc-mode have a similar variable?

Yuan

Message #17 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Theodor Thornhill <theo <at> thornhill.no>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 59251 <at> debbugs.gnu.org
Subject: Re: bug#59251: Acknowledgement (29.0.50;
 Fix-some-inconsistencies-in-ts-modes)
Date: Mon, 14 Nov 2022 08:06:31 +0100

[Message part 1 (text/plain, inline)]

Yuan Fu <casouri <at> gmail.com> writes:

>> On Nov 13, 2022, at 3:01 PM, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
>> 
>> Theodor Thornhill <theo <at> thornhill.no> writes:
>> 
>>> Added a few more finishes.
>> 
>> Aaand another.  Last one for now.  I promise…
>
> Cool! Some comments:
>
> +(defcustom c-ts-mode-font-lock-feature-list
> +  '((comment preprocessor operator constant string literal keyword)
> +    (type definition expression statement)
> +    ())
> +  "Language constructs to font-lock.
> +
> +See `treesit-font-lock-feature-list' for description of how to
> +use this variable.  Supported features are as defined in
> +`c-ts-mode--font-lock-settings'."
> +  :version "29.1"
> +  :type 'list
> +  :safe 'listp
> +  :group 'c)
> +
>
> I think Stefan M’s opinion is to make feature-list private, and let
> users add/remove features. Right now they can add/remove features with
> treesit-recompute-feature-list. I guess we can keep them as defvar’s
> for now, so people as the option to redefine this list should they
> want to. (One argument against having them as custom options is that,
> if a user sets it as a custom option, they will miss out on future
> changes to this variable.)
>
>
> +  (setq-local comment-style c-ts-mode-comment-style)
>
> Why don’t we let users set comment style themselves? Does cc-mode have a similar variable?
>

You have a point.  Simplified the patch.

Theo

[0001-Fix-some-inconsistencies-in-ts-modes.patch (text/x-diff, attachment)]

Message #20 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59251 <at> debbugs.gnu.org, done-59251 <at> debbugs.gnu.org
Subject: Re: bug#59251: Acknowledgement (29.0.50;
 Fix-some-inconsistencies-in-ts-modes)
Date: Mon, 14 Nov 2022 01:25:09 -0800

> On Nov 13, 2022, at 11:06 PM, Theodor Thornhill <theo <at> thornhill.no> wrote:
> 
> Yuan Fu <casouri <at> gmail.com> writes:
> 
>>> On Nov 13, 2022, at 3:01 PM, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
>>> 
>>> Theodor Thornhill <theo <at> thornhill.no> writes:
>>> 
>>>> Added a few more finishes.
>>> 
>>> Aaand another.  Last one for now.  I promise…
>> 
>> Cool! Some comments:
>> 
>> +(defcustom c-ts-mode-font-lock-feature-list
>> +  '((comment preprocessor operator constant string literal keyword)
>> +    (type definition expression statement)
>> +    ())
>> +  "Language constructs to font-lock.
>> +
>> +See `treesit-font-lock-feature-list' for description of how to
>> +use this variable.  Supported features are as defined in
>> +`c-ts-mode--font-lock-settings'."
>> +  :version "29.1"
>> +  :type 'list
>> +  :safe 'listp
>> +  :group 'c)
>> +
>> 
>> I think Stefan M’s opinion is to make feature-list private, and let
>> users add/remove features. Right now they can add/remove features with
>> treesit-recompute-feature-list. I guess we can keep them as defvar’s
>> for now, so people as the option to redefine this list should they
>> want to. (One argument against having them as custom options is that,
>> if a user sets it as a custom option, they will miss out on future
>> changes to this variable.)
>> 
>> 
>> +  (setq-local comment-style c-ts-mode-comment-style)
>> 
>> Why don’t we let users set comment style themselves? Does cc-mode have a similar variable?
>> 
> 
> You have a point.  Simplified the patch.
> 
> Theo
> 
> <0001-Fix-some-inconsistencies-in-ts-modes.patch>

Thanks, merged and pushed.

Yuan

Message #23 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59251 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: Re: bug#59251: 29.0.50; Fix-some-inconsistencies-in-ts-modes
Date: Mon, 14 Nov 2022 20:59:34 +0200

> Cc: casouri <at> gmail.com
> Date: Sun, 13 Nov 2022 21:42:19 +0100
> From:  Theodor Thornhill via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> BTW, should we do the same thing we did with js-mode - add a js-ts-mode
> and don't change the js.el file at all?  We could either go the same
> route as c-ts-mode, where we define both c and c++ in the same file, or
> keep them separate.  What do you think?

From my POV, it is best not to introduce new modes if that is
possible.  That way, we minimize confusion and allow users to adapt
more easily.  Only where the new mode is radically different from the
old one and cannot be easily be an optional addition to the old one,
is a completely new mode justified.

Message #26 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 59251 <at> debbugs.gnu.org, theo <at> thornhill.no
Subject: Re: bug#59251: Acknowledgement (29.0.50;
 Fix-some-inconsistencies-in-ts-modes)
Date: Mon, 14 Nov 2022 21:02:39 +0200

> Cc: 59251 <at> debbugs.gnu.org
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sun, 13 Nov 2022 16:51:52 -0800
> 
> +  (setq-local comment-style c-ts-mode-comment-style)
> 
> Why don’t we let users set comment style themselves? Does cc-mode have a similar variable?

It's a minor mode there, see "C-c C-k" (c-toggle-comment-style).

Message #29 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59251 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: Re: bug#59251: 29.0.50; Fix-some-inconsistencies-in-ts-modes
Date: Mon, 14 Nov 2022 20:12:29 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: casouri <at> gmail.com
>> Date: Sun, 13 Nov 2022 21:42:19 +0100
>> From:  Theodor Thornhill via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> BTW, should we do the same thing we did with js-mode - add a js-ts-mode
>> and don't change the js.el file at all?  We could either go the same
>> route as c-ts-mode, where we define both c and c++ in the same file, or
>> keep them separate.  What do you think?
>
> From my POV, it is best not to introduce new modes if that is
> possible.  That way, we minimize confusion and allow users to adapt
> more easily.  Only where the new mode is radically different from the
> old one and cannot be easily be an optional addition to the old one,
> is a completely new mode justified.

Then I think we should do something like one of the first suggestions I
made weeks ago - separate the inits so that as little as possible is
shared between them.  If we do that, then it would at least make sense
to merge css and javascript.

Message #32 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59251 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: Re: bug#59251: Acknowledgement (29.0.50;
 Fix-some-inconsistencies-in-ts-modes)
Date: Tue, 15 Nov 2022 14:22:38 +0200

> Cc: 59251 <at> debbugs.gnu.org
> Date: Mon, 14 Nov 2022 08:06:31 +0100
> From:  Theodor Thornhill via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > +  (setq-local comment-style c-ts-mode-comment-style)
> >
> > Why don’t we let users set comment style themselves? Does cc-mode have a similar variable?
> >
> 
> You have a point.  Simplified the patch.

This still makes it a fixed value that cannot be easily customized?
Or did I miss something?

Message #35 received at 59251 <at> debbugs.gnu.org (full text, mbox):

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59251 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: Re: bug#59251: Acknowledgement (29.0.50; Fix-some-inconsistencies-in-ts-modes)
Date: Tue, 15 Nov 2022 15:22:00 +0100

On 15 November 2022 13:22:38 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Cc: 59251 <at> debbugs.gnu.org
>> Date: Mon, 14 Nov 2022 08:06:31 +0100
>> From:  Theodor Thornhill via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> > +  (setq-local comment-style c-ts-mode-comment-style)
>> >
>> > Why don’t we let users set comment style themselves? Does cc-mode have a similar variable?
>> >
>> 
>> You have a point.  Simplified the patch.
>
>This still makes it a fixed value that cannot be easily customized?
>Or did I miss something?

You could set it through the defcustom that was included

Message #42 received at 59251-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 59251-done <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#59251: 29.0.50; Fix-some-inconsistencies-in-ts-modes
Date: Sun, 23 Feb 2025 01:32:37 +0000

Yuan Fu <casouri <at> gmail.com> writes:

> Thanks, merged and pushed.

It seems like this was never closed.  I'm therefore closing this bug
report.

Message #45 received at 59251-done <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 59251-done <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#59251: 29.0.50; Fix-some-inconsistencies-in-ts-modes
Date: Sat, 22 Feb 2025 21:16:19 -0800

> On Feb 22, 2025, at 5:32 PM, Stefan Kangas <stefankangas <at> gmail.com> wrote:
> 
> Yuan Fu <casouri <at> gmail.com> writes:
> 
>> Thanks, merged and pushed.
> 
> It seems like this was never closed.  I'm therefore closing this bug
> report.

Thanks Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.