Missing features in c-ts-mode

Missing features in c-ts-mode

[Eli Zaretskii]

There's a couple of useful features that are currently missing from
c/c++-ts-mode:

  M-a and M-e (go to beginning/end of statement)
  electric # (aligns # to the left unless it's in a comment or a string)

Can we add these, please?

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

> There's a couple of useful features that are currently missing from
> c/c++-ts-mode:
>
>   M-a and M-e (go to beginning/end of statement)
>   electric # (aligns # to the left unless it's in a comment or a string)
>
> Can we add these, please?

Isn't M-a and M-e available on master?

I'll look into electric #. For emacs-29 or master?

Theo

Re: Missing features in c-ts-mode

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: emacs-devel@gnu.org
> Date: Wed, 15 Feb 2023 19:29:20 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There's a couple of useful features that are currently missing from
> > c/c++-ts-mode:
> >
> >   M-a and M-e (go to beginning/end of statement)
> >   electric # (aligns # to the left unless it's in a comment or a string)
> >
> > Can we add these, please?
> 
> Isn't M-a and M-e available on master?

Maybe, I didn't look there, sorry.  If they work there, then this one
is fine.

> I'll look into electric #. For emacs-29 or master?

If it is simple and safe enough, emacs-29.

Thanks.

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 15 Feb 2023 19:29:20 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > There's a couple of useful features that are currently missing from
>> > c/c++-ts-mode:
>> >
>> >   M-a and M-e (go to beginning/end of statement)
>> >   electric # (aligns # to the left unless it's in a comment or a string)
>> >
>> > Can we add these, please?
>> 
>> Isn't M-a and M-e available on master?
>
> Maybe, I didn't look there, sorry.  If they work there, then this one
> is fine.
>

They should be there, but they may need tweaking.  Let me know if they
behave unexpectedly.

>> I'll look into electric #. For emacs-29 or master?
>
> If it is simple and safe enough, emacs-29.
>
> Thanks.

No worries :-)

Theo

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Theodor Thornhill <theo@thornhill.no> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Theodor Thornhill <theo@thornhill.no>
>>> Cc: emacs-devel@gnu.org
>>> Date: Wed, 15 Feb 2023 19:29:20 +0100
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > There's a couple of useful features that are currently missing from
>>> > c/c++-ts-mode:
>>> >
>>> >   M-a and M-e (go to beginning/end of statement)
>>> >   electric # (aligns # to the left unless it's in a comment or a string)
>>> >
>>> > Can we add these, please?
>>> 
>>> Isn't M-a and M-e available on master?
>>
>> Maybe, I didn't look there, sorry.  If they work there, then this one
>> is fine.
>>
>
> They should be there, but they may need tweaking.  Let me know if they
> behave unexpectedly.
>
>>> I'll look into electric #. For emacs-29 or master?
>>
>> If it is simple and safe enough, emacs-29.
>>
>> Thanks.
>
> No worries :-)
>
> Theo

This patch adds some support for this- but I'm not really satisfied yet.
It will electrically indent if you've typed "#i", or if you insert "#"
before say, "if".  The reason it behaves this way right now is that the
parser returns an (ERROR (ERROR)) node when only # is inserted.  I'll
see if I can find some workaround for it.


diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 020f2642ac2..29e917a2aee 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -785,7 +785,13 @@ c-ts-base-mode
 
   ;; Electric
   (setq-local electric-indent-chars
-              (append "{}():;," electric-indent-chars))
+              (append "{}():;,#" electric-indent-chars))
+
+  (setq-local electric-indent-functions
+              (list
+               (lambda (c) (save-excursion
+                        (forward-char -1)
+                        (looking-back "#" nil)))))
 
   ;; Imenu.
   (setq-local treesit-simple-imenu-settings

Re: Missing features in c-ts-mode

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: casouri@gmail.com, emacs-devel@gnu.org
> Date: Wed, 15 Feb 2023 20:31:33 +0100
> 
> This patch adds some support for this- but I'm not really satisfied yet.
> It will electrically indent if you've typed "#i", or if you insert "#"
> before say, "if".  The reason it behaves this way right now is that the
> parser returns an (ERROR (ERROR)) node when only # is inserted.  I'll
> see if I can find some workaround for it.

Thank you for working on this.

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: casouri@gmail.com, emacs-devel@gnu.org
>> Date: Wed, 15 Feb 2023 20:31:33 +0100
>> 
>> This patch adds some support for this- but I'm not really satisfied yet.
>> It will electrically indent if you've typed "#i", or if you insert "#"
>> before say, "if".  The reason it behaves this way right now is that the
>> parser returns an (ERROR (ERROR)) node when only # is inserted.  I'll
>> see if I can find some workaround for it.
>
> Thank you for working on this.


Ok so I found a way which will probably work well.  I just need to
figure out if there are any other cases where we get the (ERROR (ERROR))
pattern.  If not I'll add some tests and also this:

diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 020f2642ac2..a60c464093e 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -219,6 +219,7 @@ c-ts-mode--indent-styles
 MODE is either `c' or `cpp'."
   (let ((common
          `(((parent-is "translation_unit") point-min 0)
+           ((query "(ERROR (ERROR)) @indent") point-min 0)
            ((node-is ")") parent 1)
            ((node-is "]") parent-bol 0)
            ((node-is "else") parent-bol 0)
@@ -785,7 +786,7 @@ c-ts-base-mode
 
   ;; Electric
   (setq-local electric-indent-chars
-              (append "{}():;," electric-indent-chars))
+              (append "{}():;,#" electric-indent-chars))
 
   ;; Imenu.
   (setq-local treesit-simple-imenu-settings

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Theodor Thornhill <theo@thornhill.no> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Theodor Thornhill <theo@thornhill.no>
>>> Cc: casouri@gmail.com, emacs-devel@gnu.org
>>> Date: Wed, 15 Feb 2023 20:31:33 +0100
>>> 
>>> This patch adds some support for this- but I'm not really satisfied yet.
>>> It will electrically indent if you've typed "#i", or if you insert "#"
>>> before say, "if".  The reason it behaves this way right now is that the
>>> parser returns an (ERROR (ERROR)) node when only # is inserted.  I'll
>>> see if I can find some workaround for it.
>>
>> Thank you for working on this.

Now done.  I believe the fix was small enough to go to emacs-29, so just
pushed.  What would be the best way to create a test that would emulate
this behavior?

I tried

```
Code:
  (lambda ()
    (c-ts-mode)
    (self-insert-command 1 "#"))

Point-Char: |

Name: Electric pound indents to column 0

=-=
int
main (void)
{
  |
  return 0;
}
=-=
int
main (void)
{
#|
  return 0;
}
=-=-=
```

But that didn't run the electric indent afaict.

Theo

Re: Missing features in c-ts-mode

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: casouri@gmail.com, emacs-devel@gnu.org
> Date: Thu, 16 Feb 2023 20:14:26 +0100
> 
> >> Thank you for working on this.
> 
> Now done.  I believe the fix was small enough to go to emacs-29, so just
> pushed.

Thanks, it LGTM.

> What would be the best way to create a test that would emulate
> this behavior?

Did you look how test/lisp/electric-tests.el does that?

Re: Missing features in c-ts-mode

[Theodor Thornhill]

On 16 February 2023 21:38:03 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: casouri@gmail.com, emacs-devel@gnu.org
>> Date: Thu, 16 Feb 2023 20:14:26 +0100
>> 
>> >> Thank you for working on this.
>> 
>> Now done.  I believe the fix was small enough to go to emacs-29, so just
>> pushed.
>
>Thanks, it LGTM.
>
>> What would be the best way to create a test that would emulate
>> this behavior?
>
>Did you look how test/lisp/electric-tests.el does that?

No, thanks, will take a look!

Re: Missing features in c-ts-mode

[Ergus]

Hi Theodor:

Sorry to bother, but I have a question about commit:

f1f571e Add electric indent for preproc directives

c-mode had by default the [0] indentation for #preprocesor directives,
but there are some use cases where that behavior is not desired (i.e
#pragma).

Actually there are even multi-line pragmas when using OpenMP

int main()
{
     #pragma parallel for first private(x) \
         shared(y) etc
     for (...) {
         ....
     }
}

In this case the pragma in column zero is very confusing. Alan added a
new mode (c-toggle-cpp-indent-to-body) which worked around this issue a
few years ago. I don't if it is possible to enable similar behavior with
your change? Is is?

Best,
Ergus




On Thu, Feb 16, 2023 at 08:14:26PM +0100, Theodor Thornhill wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Theodor Thornhill <theo@thornhill.no>
>>>> Cc: casouri@gmail.com, emacs-devel@gnu.org
>>>> Date: Wed, 15 Feb 2023 20:31:33 +0100
>>>>
>>>> This patch adds some support for this- but I'm not really satisfied yet.
>>>> It will electrically indent if you've typed "#i", or if you insert "#"
>>>> before say, "if".  The reason it behaves this way right now is that the
>>>> parser returns an (ERROR (ERROR)) node when only # is inserted.  I'll
>>>> see if I can find some workaround for it.
>>>
>>> Thank you for working on this.
>
>Now done.  I believe the fix was small enough to go to emacs-29, so just
>pushed.  What would be the best way to create a test that would emulate
>this behavior?
>
>I tried
>
>```
>Code:
>  (lambda ()
>    (c-ts-mode)
>    (self-insert-command 1 "#"))
>
>Point-Char: |
>
>Name: Electric pound indents to column 0
>
>=-=
>int
>main (void)
>{
>  |
>  return 0;
>}
>=-=
>int
>main (void)
>{
>#|
>  return 0;
>}
>=-=-=
>```
>
>But that didn't run the electric indent afaict.
>
>Theo
>

Re: Missing features in c-ts-mode

[Eli Zaretskii]

> Date: Fri, 17 Feb 2023 09:29:35 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com, emacs-devel@gnu.org
> 
> Hi Theodor:
> 
> Sorry to bother, but I have a question about commit:
> 
> f1f571e Add electric indent for preproc directives
> 
> c-mode had by default the [0] indentation for #preprocesor directives,
> but there are some use cases where that behavior is not desired (i.e
> #pragma).
> 
> Actually there are even multi-line pragmas when using OpenMP
> 
> int main()
> {
>      #pragma parallel for first private(x) \
>          shared(y) etc
>      for (...) {
>          ....
>      }
> }
> 
> In this case the pragma in column zero is very confusing. Alan added a
> new mode (c-toggle-cpp-indent-to-body) which worked around this issue a
> few years ago. I don't if it is possible to enable similar behavior with
> your change? Is is?

We could perhaps have a similar toggle in c-ts-mode.  Theo, can you
have a look?  Btw, the fact that this is off by default IMO speaks
volumes about the importance of the feature.

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Ergus <spacibba@aol.com> writes:

> Hi Theodor:
>
> Sorry to bother, but I have a question about commit:
>
> f1f571e Add electric indent for preproc directives
>
> c-mode had by default the [0] indentation for #preprocesor directives,
> but there are some use cases where that behavior is not desired (i.e
> #pragma).
>
> Actually there are even multi-line pragmas when using OpenMP
>
> int main()
> {
>      #pragma parallel for first private(x) \
>          shared(y) etc
>      for (...) {
>          ....
>      }
> }
>
> In this case the pragma in column zero is very confusing. Alan added a
> new mode (c-toggle-cpp-indent-to-body) which worked around this issue a
> few years ago. I don't if it is possible to enable similar behavior with
> your change? Is is?
>
> Best,
> Ergus
>

It's absolutely possible, but IMO that sounds like an improvement for
emacs 30, maybe?  Just create a bug-report and I can take it from there?

Theo

Re: Missing features in c-ts-mode

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com, emacs-devel@gnu.org
> Date: Fri, 17 Feb 2023 10:56:28 +0100
> 
> >      #pragma parallel for first private(x) \
> >          shared(y) etc
> >      for (...) {
> >          ....
> >      }
> > }
> >
> > In this case the pragma in column zero is very confusing. Alan added a
> > new mode (c-toggle-cpp-indent-to-body) which worked around this issue a
> > few years ago. I don't if it is possible to enable similar behavior with
> > your change? Is is?
> >
> > Best,
> > Ergus
> >
> 
> It's absolutely possible, but IMO that sounds like an improvement for
> emacs 30, maybe?

It depends on how simple and safe the change will be.  But yes, I'm
okay with delaying this to Emacs 30 if the addition is complex enough.

Thanks.

Re: Missing features in c-ts-mode

[Ergus]

Hi Eli and Theo:

Yes, I know that the feature is not very "popular" to be enabled by
default, but for parallel programming models based on pragmas (OpenMP,
OmpSs, OpenACC) it is very important.

Many people in my previous work moved to some other editor after years
using emacs due to these apparently "small" details. Every time they
wanted to indent a portion of code (i.e they added an if around it), all
the pragmas moved out of their place and needed manual fix.

On that moment I commented with Alan the possibility to make #pragma a
syntactc symbol which we could control its indentation like anything
else in c-mode (with +, ++, -, 0 or [0]). But he said that it required
too many changes to implement that and offered this "toggle" solution
good enough for me.

I will open the feature request in a moment, but just wanted to comment
the alternative solution more consistent and without an extra mode;
because maybe that way may be simpler now in the new mode??

Best,
Ergus

On Fri, Feb 17, 2023 at 02:20:59PM +0200, Eli Zaretskii wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com, emacs-devel@gnu.org
>> Date: Fri, 17 Feb 2023 10:56:28 +0100
>>
>> >      #pragma parallel for first private(x) \
>> >          shared(y) etc
>> >      for (...) {
>> >          ....
>> >      }
>> > }
>> >
>> > In this case the pragma in column zero is very confusing. Alan added a
>> > new mode (c-toggle-cpp-indent-to-body) which worked around this issue a
>> > few years ago. I don't if it is possible to enable similar behavior with
>> > your change? Is is?
>> >
>> > Best,
>> > Ergus
>> >
>>
>> It's absolutely possible, but IMO that sounds like an improvement for
>> emacs 30, maybe?
>
>It depends on how simple and safe the change will be.  But yes, I'm
>okay with delaying this to Emacs 30 if the addition is complex enough.
>
>Thanks.
>

Re: Missing features in c-ts-mode

[Theodor Thornhill]

On 17 February 2023 17:37:47 CET, Ergus <spacibba@aol.com> wrote:
>Hi Eli and Theo:
>
>Yes, I know that the feature is not very "popular" to be enabled by
>default, but for parallel programming models based on pragmas (OpenMP,
>OmpSs, OpenACC) it is very important.
>
>Many people in my previous work moved to some other editor after years
>using emacs due to these apparently "small" details. Every time they
>wanted to indent a portion of code (i.e they added an if around it), all
>the pragmas moved out of their place and needed manual fix.
>
>On that moment I commented with Alan the possibility to make #pragma a
>syntactc symbol which we could control its indentation like anything
>else in c-mode (with +, ++, -, 0 or [0]). But he said that it required
>too many changes to implement that and offered this "toggle" solution
>good enough for me.
>
>I will open the feature request in a moment, but just wanted to comment
>the alternative solution more consistent and without an extra mode;
>because maybe that way may be simpler now in the new mode??
>
>Best,
>Ergus
>
>On Fri, Feb 17, 2023 at 02:20:59PM +0200, Eli Zaretskii wrote:
>>> From: Theodor Thornhill <theo@thornhill.no>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com, emacs-devel@gnu.org
>>> Date: Fri, 17 Feb 2023 10:56:28 +0100
>>> 
>>> >      #pragma parallel for first private(x) \
>>> >          shared(y) etc
>>> >      for (...) {
>>> >          ....
>>> >      }
>>> > }
>>> >
>>> > In this case the pragma in column zero is very confusing. Alan added a
>>> > new mode (c-toggle-cpp-indent-to-body) which worked around this issue a
>>> > few years ago. I don't if it is possible to enable similar behavior with
>>> > your change? Is is?
>>> >
>>> > Best,
>>> > Ergus
>>> >
>>> 
>>> It's absolutely possible, but IMO that sounds like an improvement for
>>> emacs 30, maybe?
>> 
>> It depends on how simple and safe the change will be.  But yes, I'm
>> okay with delaying this to Emacs 30 if the addition is complex enough.
>> 
>> Thanks.
>> 

Would this mean you'd want all preproc directives configurable, or only some in particular? I think a defcustom for either/or is doable for Emacs 29, but for granular control we'd need to think a bit more.

c-ts-mode-preproc-indent-to-body?

Re: Missing features in c-ts-mode

[Ergus]

On Fri, Feb 17, 2023 at 06:34:34PM +0100, Theodor Thornhill wrote:
>
>
>On 17 February 2023 17:37:47 CET, Ergus <spacibba@aol.com> wrote:
>>Hi Eli and Theo:
>>
>>Yes, I know that the feature is not very "popular" to be enabled by
>>default, but for parallel programming models based on pragmas (OpenMP,
>>OmpSs, OpenACC) it is very important.
>>
>>Many people in my previous work moved to some other editor after years
>>using emacs due to these apparently "small" details. Every time they
>>wanted to indent a portion of code (i.e they added an if around it), all
>>the pragmas moved out of their place and needed manual fix.
>>
>>On that moment I commented with Alan the possibility to make #pragma a
>>syntactc symbol which we could control its indentation like anything
>>else in c-mode (with +, ++, -, 0 or [0]). But he said that it required
>>too many changes to implement that and offered this "toggle" solution
>>good enough for me.
>>
>>I will open the feature request in a moment, but just wanted to comment
>>the alternative solution more consistent and without an extra mode;
>>because maybe that way may be simpler now in the new mode??
>>
>>Best,
>>Ergus
>>
>>On Fri, Feb 17, 2023 at 02:20:59PM +0200, Eli Zaretskii wrote:
>>>> From: Theodor Thornhill <theo@thornhill.no>
>>>> Cc: Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com, emacs-devel@gnu.org
>>>> Date: Fri, 17 Feb 2023 10:56:28 +0100
>>>>
>>>> >      #pragma parallel for first private(x) \
>>>> >          shared(y) etc
>>>> >      for (...) {
>>>> >          ....
>>>> >      }
>>>> > }
>>>> >
>>>> > In this case the pragma in column zero is very confusing. Alan added a
>>>> > new mode (c-toggle-cpp-indent-to-body) which worked around this issue a
>>>> > few years ago. I don't if it is possible to enable similar behavior with
>>>> > your change? Is is?
>>>> >
>>>> > Best,
>>>> > Ergus
>>>> >
>>>>
>>>> It's absolutely possible, but IMO that sounds like an improvement for
>>>> emacs 30, maybe?
>>>
>>> It depends on how simple and safe the change will be.  But yes, I'm
>>> okay with delaying this to Emacs 30 if the addition is complex enough.
>>>
>>> Thanks.
>>>
>
>Would this mean you'd want all preproc directives configurable, or only
>some in particular? I think a defcustom for either/or is doable for
>Emacs 29, but for granular control we'd need to think a bit more.
>
>c-ts-mode-preproc-indent-to-body?


Hi Theo:

AFAIK only #pragmas have this behavior, so I think a custom for #pragmas
may be enough if the alternative becomes complex or complicated.

I commented the initial problem as it was just in case tree-sitter
already have all the spices to go for the general solution in a
"simpler" way, with a consistent syntax and without an extra
defcustom/toggle-mode.

Maybe there is a point in between like treat #pragmas as a different
kind of directive than preproc (which they actually are BTW, #pragmas
are not exactly preprocesor directives, but hints for the compiler
itself).

In that case the user could write something more or less like:
  ((node-is "pragma") parent 1)
  ((node-is "pragma") no-indent)

in the indent-style.

WDYT?

Re: Missing features in c-ts-mode

[Theodor Thornhill]

On 17 February 2023 19:02:28 CET, Ergus <spacibba@aol.com> wrote:
>On Fri, Feb 17, 2023 at 06:34:34PM +0100, Theodor Thornhill wrote:
>> 
>> 
>> On 17 February 2023 17:37:47 CET, Ergus <spacibba@aol.com> wrote:
>>> Hi Eli and Theo:
>>> 
>>> Yes, I know that the feature is not very "popular" to be enabled by
>>> default, but for parallel programming models based on pragmas (OpenMP,
>>> OmpSs, OpenACC) it is very important.
>>> 
>>> Many people in my previous work moved to some other editor after years
>>> using emacs due to these apparently "small" details. Every time they
>>> wanted to indent a portion of code (i.e they added an if around it), all
>>> the pragmas moved out of their place and needed manual fix.
>>> 
>>> On that moment I commented with Alan the possibility to make #pragma a
>>> syntactc symbol which we could control its indentation like anything
>>> else in c-mode (with +, ++, -, 0 or [0]). But he said that it required
>>> too many changes to implement that and offered this "toggle" solution
>>> good enough for me.
>>> 
>>> I will open the feature request in a moment, but just wanted to comment
>>> the alternative solution more consistent and without an extra mode;
>>> because maybe that way may be simpler now in the new mode??
>>> 
>>> Best,
>>> Ergus
>>> 
>>> On Fri, Feb 17, 2023 at 02:20:59PM +0200, Eli Zaretskii wrote:
>>>>> From: Theodor Thornhill <theo@thornhill.no>
>>>>> Cc: Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com, emacs-devel@gnu.org
>>>>> Date: Fri, 17 Feb 2023 10:56:28 +0100
>>>>> 
>>>>> >      #pragma parallel for first private(x) \
>>>>> >          shared(y) etc
>>>>> >      for (...) {
>>>>> >          ....
>>>>> >      }
>>>>> > }
>>>>> >
>>>>> > In this case the pragma in column zero is very confusing. Alan added a
>>>>> > new mode (c-toggle-cpp-indent-to-body) which worked around this issue a
>>>>> > few years ago. I don't if it is possible to enable similar behavior with
>>>>> > your change? Is is?
>>>>> >
>>>>> > Best,
>>>>> > Ergus
>>>>> >
>>>>> 
>>>>> It's absolutely possible, but IMO that sounds like an improvement for
>>>>> emacs 30, maybe?
>>>> 
>>>> It depends on how simple and safe the change will be.  But yes, I'm
>>>> okay with delaying this to Emacs 30 if the addition is complex enough.
>>>> 
>>>> Thanks.
>>>> 
>> 
>> Would this mean you'd want all preproc directives configurable, or only
>> some in particular? I think a defcustom for either/or is doable for
>> Emacs 29, but for granular control we'd need to think a bit more.
>> 
>> c-ts-mode-preproc-indent-to-body?
>
>
>Hi Theo:
>
>AFAIK only #pragmas have this behavior, so I think a custom for #pragmas
>may be enough if the alternative becomes complex or complicated.
>
>I commented the initial problem as it was just in case tree-sitter
>already have all the spices to go for the general solution in a
>"simpler" way, with a consistent syntax and without an extra
>defcustom/toggle-mode.
>
>Maybe there is a point in between like treat #pragmas as a different
>kind of directive than preproc (which they actually are BTW, #pragmas
>are not exactly preprocesor directives, but hints for the compiler
>itself).
>
>In that case the user could write something more or less like:
> ((node-is "pragma") parent 1)
> ((node-is "pragma") no-indent)
>
>in the indent-style.
>
>WDYT?
>

Yep! Is there any particular style? Would pragmas be indented from the parent scope, and the next line after it be at the same level as the pragma? 

Theo

Re: Missing features in c-ts-mode

[Ergus]

On Fri, Feb 17, 2023 at 07:10:28PM +0100, Theodor Thornhill wrote:
>
>
>On 17 February 2023 19:02:28 CET, Ergus <spacibba@aol.com> wrote:
>
>Yep! Is there any particular style? Would pragmas be indented from the parent scope, and the next line after it be at the same level as the pragma?
>
>Theo
>

Hi:

Yes, pragmas will be generally indented from the parent scope,
continuation lines are usually in the same level or one level more,

And then everything continues as usual:

These are the common use cases I know so far:

// outline pragmas
#pragma bla
int myfunction1()
{...}

int main()
{
     // inline pragmas for functions
     #pragma bla bla
     somefunction1()

     // inline pragmas for function with continuation one level more
     #pragma bla bla\
         the continuation of pragma
     somefunction2()

     // inline pragma for a block of code
     #pragma bla2
     {
         this is a block as usual

         // nested pragma
         #pragma mynestedpragma
         bla()
     }
}

Best and thanks,
Ergus

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Ergus <spacibba@aol.com> writes:

> On Fri, Feb 17, 2023 at 07:10:28PM +0100, Theodor Thornhill wrote:
>>
>>
>>On 17 February 2023 19:02:28 CET, Ergus <spacibba@aol.com> wrote:
>>
>>Yep! Is there any particular style? Would pragmas be indented from the parent scope, and the next line after it be at the same level as the pragma?
>>
>>Theo
>>
>
> Hi:
>
> Yes, pragmas will be generally indented from the parent scope,
> continuation lines are usually in the same level or one level more,
>
> And then everything continues as usual:
>
> These are the common use cases I know so far:
>
> // outline pragmas
> #pragma bla
> int myfunction1()
> {...}
>
> int main()
> {
>      // inline pragmas for functions
>      #pragma bla bla
>      somefunction1()
>
>      // inline pragmas for function with continuation one level more
>      #pragma bla bla\
>          the continuation of pragma
>      somefunction2()
>
>      // inline pragma for a block of code
>      #pragma bla2
>      {
>          this is a block as usual
>
>          // nested pragma
>          #pragma mynestedpragma
>          bla()
>      }
> }
>
> Best and thanks,
> Ergus

Great, thanks!  I think I have a good idea about what you want, and I'll
see if I can come up with something.

Theo

Re: Missing features in c-ts-mode

[Felix]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: casouri@gmail.com, emacs-devel@gnu.org
>> Date: Wed, 15 Feb 2023 20:31:33 +0100
>>
>> This patch adds some support for this- but I'm not really satisfied yet.
>> It will electrically indent if you've typed "#i", or if you insert "#"
>> before say, "if".  The reason it behaves this way right now is that the
>> parser returns an (ERROR (ERROR)) node when only # is inserted.  I'll
>> see if I can find some workaround for it.
>
> Thank you for working on this.


I don't know if it's ok to reuse/extend this thread,
but another feature that doesn't work in c-ts-mode is
c-toggle-comment-style.
Initially the mode uses /* */ style comments.
If after c-toggle-comment-style, commenting anything leads to:

'comment-or-uncomment-region: Args out of range: "", 0, 1'

Re: Missing features in c-ts-mode

[Eli Zaretskii]

> From: Felix <felix.dick@web.de>
> Cc: Theodor Thornhill <theo@thornhill.no>, casouri@gmail.com,
>  emacs-devel@gnu.org
> Date: Wed, 15 Feb 2023 21:31:25 +0100
> 
> I don't know if it's ok to reuse/extend this thread,
> but another feature that doesn't work in c-ts-mode is
> c-toggle-comment-style.
> Initially the mode uses /* */ style comments.
> If after c-toggle-comment-style, commenting anything leads to:
> 
> 'comment-or-uncomment-region: Args out of range: "", 0, 1'

Please report this as a bug.  c-ts-mode should have its own command
for this; invoking c-toggle-comment-style will always cause trouble in
this situation and should probably signal an error if invoked not in
c-mode or its descendant.

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Felix <felix.dick@web.de>
>> Cc: Theodor Thornhill <theo@thornhill.no>, casouri@gmail.com,
>>  emacs-devel@gnu.org
>> Date: Wed, 15 Feb 2023 21:31:25 +0100
>> 
>> I don't know if it's ok to reuse/extend this thread,
>> but another feature that doesn't work in c-ts-mode is
>> c-toggle-comment-style.
>> Initially the mode uses /* */ style comments.
>> If after c-toggle-comment-style, commenting anything leads to:
>> 
>> 'comment-or-uncomment-region: Args out of range: "", 0, 1'
>
> Please report this as a bug.  c-ts-mode should have its own command
> for this; invoking c-toggle-comment-style will always cause trouble in
> this situation and should probably signal an error if invoked not in
> c-mode or its descendant.


Yes, it needs its own command.  Thanks!

Theo

Re: Missing features in c-ts-mode

[Felix]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Felix <felix.dick@web.de>
>> Cc: Theodor Thornhill <theo@thornhill.no>, casouri@gmail.com,
>>  emacs-devel@gnu.org
>> Date: Wed, 15 Feb 2023 21:31:25 +0100
>>
>> I don't know if it's ok to reuse/extend this thread,
>> but another feature that doesn't work in c-ts-mode is
>> c-toggle-comment-style.
>> Initially the mode uses /* */ style comments.
>> If after c-toggle-comment-style, commenting anything leads to:
>>
>> 'comment-or-uncomment-region: Args out of range: "", 0, 1'
>
> Please report this as a bug.  c-ts-mode should have its own command
> for this; invoking c-toggle-comment-style will always cause trouble in
> this situation and should probably signal an error if invoked not in
> c-mode or its descendant.


Done in bug-report 61550.

Re: Missing features in c-ts-mode

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: casouri@gmail.com, emacs-devel@gnu.org
> Date: Wed, 15 Feb 2023 20:18:32 +0100
> 
> >> Isn't M-a and M-e available on master?
> >
> > Maybe, I didn't look there, sorry.  If they work there, then this one
> > is fine.
> >
> 
> They should be there, but they may need tweaking.  Let me know if they
> behave unexpectedly.

Hmm... they behave...strangely.

Visit dispnew.c, turn on c-ts-mode, then go to line 174.  Type M-a and
watch in disbelief where it goes.  Same surprise if you type M-e.
Conclusion: preprocessor directives seem to drive this feature crazy.

OK, so let's find a place without cpp directives.  Go to line 368:

static void
adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y, struct dim dim)
{
  int i;
  int new_rows;
  bool marginal_areas_changed_p = 0;
  bool tab_line_changed_p = 0;  <<<<<<<<<<<<<<<<<<<<
  bool tab_line_p = 0;

Position point in the middle of the line and press M-a -- point goes
to the first non-blank character of the line: good.  Now type M-a
again -- point goes to the first non-blank character of the _previous_
line: why?

Now go to line 382:

  if (w)
    {
      window_box (w, ANY_AREA, 0, 0, &window_width, &window_height);

      tab_line_p = window_wants_tab_line (w);
      tab_line_changed_p = tab_line_p != matrix->tab_line_p; <<<<<<<<<<<<<<<

      header_line_p = window_wants_header_line (w);
      header_line_changed_p = header_line_p != matrix->header_line_p;
    }
  matrix->tab_line_p = tab_line_p;

Position point anywhere inside that line and press M-a -- point goes
to the "if" that encloses this block: why?  Moreover, if you go to the
first line _after_ the braces, the one which begins with "matrix->",
and press M-a, point still goes to that "if": why?

C-M-f also appears broken: I cannot get it to move from an opening
brace to the matching closing brace -- instead, it goes to the closing
parenthesis of some inner expression.  For example, try C-M-f here:

  else
    {
      /* If MATRIX->pool is null, MATRIX is responsible for managing
	 its own memory.  It is a window matrix for window-based redisplay.
	 Allocate glyph memory from the heap.  */
      if (dim.width > matrix->matrix_w
	  || new_rows
	  || tab_line_changed_p
	  || header_line_changed_p
	  || marginal_areas_changed_p)
	{
	  struct glyph_row *row = matrix->rows;

Place point at the opening brace after "else" and type "C-M-f" --
point goes to the closing paren after "marginal_areas_changed_p".

So this "needs work", I'd say ;-)

Re: Missing features in c-ts-mode

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: casouri@gmail.com, emacs-devel@gnu.org
>> Date: Wed, 15 Feb 2023 20:18:32 +0100
>> 
>> >> Isn't M-a and M-e available on master?
>> >
>> > Maybe, I didn't look there, sorry.  If they work there, then this one
>> > is fine.
>> >
>> 
>> They should be there, but they may need tweaking.  Let me know if they
>> behave unexpectedly.
>
> Hmm... they behave...strangely.
>
> Visit dispnew.c, turn on c-ts-mode, then go to line 174.  Type M-a and
> watch in disbelief where it goes.  Same surprise if you type M-e.
> Conclusion: preprocessor directives seem to drive this feature crazy.
>

Hmm, I cannot find any preproc directives there, but I think I
understand what you mean anyway.

> OK, so let's find a place without cpp directives.  Go to line 368:
>
> static void
> adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y, struct dim dim)
> {
>   int i;
>   int new_rows;
>   bool marginal_areas_changed_p = 0;
>   bool tab_line_changed_p = 0;  <<<<<<<<<<<<<<<<<<<<
>   bool tab_line_p = 0;
>
> Position point in the middle of the line and press M-a -- point goes
> to the first non-blank character of the line: good.  Now type M-a
> again -- point goes to the first non-blank character of the _previous_
> line: why?

Likely because that is the beginning of the "first" previous node
covered by the regexp.  Is that unexpected?

>
> Now go to line 382:
>
>   if (w)
>     {
>       window_box (w, ANY_AREA, 0, 0, &window_width, &window_height);
>
>       tab_line_p = window_wants_tab_line (w);
>       tab_line_changed_p = tab_line_p != matrix->tab_line_p; <<<<<<<<<<<<<<<
>
>       header_line_p = window_wants_header_line (w);
>       header_line_changed_p = header_line_p != matrix->header_line_p;
>     }
>   matrix->tab_line_p = tab_line_p;
>
> Position point anywhere inside that line and press M-a -- point goes
> to the "if" that encloses this block: why?  Moreover, if you go to the
> first line _after_ the braces, the one which begins with "matrix->",
> and press M-a, point still goes to that "if": why?
>
> C-M-f also appears broken: I cannot get it to move from an opening
> brace to the matching closing brace -- instead, it goes to the closing
> parenthesis of some inner expression.  For example, try C-M-f here:
>
>   else
>     {
>       /* If MATRIX->pool is null, MATRIX is responsible for managing
> 	 its own memory.  It is a window matrix for window-based redisplay.
> 	 Allocate glyph memory from the heap.  */
>       if (dim.width > matrix->matrix_w
> 	  || new_rows
> 	  || tab_line_changed_p
> 	  || header_line_changed_p
> 	  || marginal_areas_changed_p)
> 	{
> 	  struct glyph_row *row = matrix->rows;
>

Yeah, this is the same bug as in a different bug report, bug#61374.  I
didn't get to it yet, apologies!

> Place point at the opening brace after "else" and type "C-M-f" --
> point goes to the closing paren after "marginal_areas_changed_p".
>
> So this "needs work", I'd say ;-)


Hehe yeah. Thanks!  I'll check if just tweaking the regexps is enough,
but likely we need something more in the code dealing with this
too. Thanks for the detailed report though, now I have some clear
expectations to devise tests from.

Theo

Re: Missing features in c-ts-mode

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: casouri@gmail.com, emacs-devel@gnu.org
> Date: Wed, 15 Feb 2023 21:21:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Visit dispnew.c, turn on c-ts-mode, then go to line 174.  Type M-a and
> > watch in disbelief where it goes.  Same surprise if you type M-e.
> > Conclusion: preprocessor directives seem to drive this feature crazy.
> >
> 
> Hmm, I cannot find any preproc directives there, but I think I
> understand what you mean anyway.

The directives are "#ifdef GLYPH_DEBUG" on line 129 and the matching
#endif on line 234.  All that portion of dispnew.c is under that cpp
conditional.

> > static void
> > adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y, struct dim dim)
> > {
> >   int i;
> >   int new_rows;
> >   bool marginal_areas_changed_p = 0;
> >   bool tab_line_changed_p = 0;  <<<<<<<<<<<<<<<<<<<<
> >   bool tab_line_p = 0;
> >
> > Position point in the middle of the line and press M-a -- point goes
> > to the first non-blank character of the line: good.  Now type M-a
> > again -- point goes to the first non-blank character of the _previous_
> > line: why?
> 
> Likely because that is the beginning of the "first" previous node
> covered by the regexp.  Is that unexpected?

It was unexpected to some extent.  But I see that other
beginning-of-SOMETHING commands to the same, so perhaps it's just me.
Let's forget about this part, I probably need to adjust my
expectations.

> > Position point anywhere inside that line and press M-a -- point goes
> > to the "if" that encloses this block: why?  Moreover, if you go to the
> > first line _after_ the braces, the one which begins with "matrix->",
> > and press M-a, point still goes to that "if": why?
> >
> > C-M-f also appears broken: I cannot get it to move from an opening
> > brace to the matching closing brace -- instead, it goes to the closing
> > parenthesis of some inner expression.  For example, try C-M-f here:
> >
> >   else
> >     {
> >       /* If MATRIX->pool is null, MATRIX is responsible for managing
> > 	 its own memory.  It is a window matrix for window-based redisplay.
> > 	 Allocate glyph memory from the heap.  */
> >       if (dim.width > matrix->matrix_w
> > 	  || new_rows
> > 	  || tab_line_changed_p
> > 	  || header_line_changed_p
> > 	  || marginal_areas_changed_p)
> > 	{
> > 	  struct glyph_row *row = matrix->rows;
> >
> 
> Yeah, this is the same bug as in a different bug report, bug#61374.  I
> didn't get to it yet, apologies!

No need to be sorry: this is the master branch, so everything there
takes a back seat for now, and emacs-29 is the most important.

> Hehe yeah. Thanks!  I'll check if just tweaking the regexps is enough,
> but likely we need something more in the code dealing with this
> too. Thanks for the detailed report though, now I have some clear
> expectations to devise tests from.

Thanks.