GNU bug report logs - #23818
25.0.95.3: c-beginning-of-defun misbehaviour

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 23818 in the body.
You can then email your comments to 23818 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: Rolf Ade <rolf <at> pointsman.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.95.3: c-beginning-of-defun misbehaviour
Date: Wed, 22 Jun 2016 02:19:21 +0200

The same in 24.5 and 25.0.95.3:

emacs -Q

Open some random emtpy buffer foo.c, put it in c-mode (M-x c-mode) and
insert the following C code:

#define DBG(x) x

DBG(
static void __dbgAttr () {
    /* something */
}
)

int main (void) 
{
    int i;
    i++;
    i++;
    return i;
}

int foo () 
{
    int i;
    i++;
    i++;
    return 1;
}


Put the point inside function main and C-M-home (or M-x
c-beginning-of-defun). Instead of the beginning of main() the point is
here:

_P_DBG(
...

Far away from

_P_int main(void)
...


This isn't "unbalanced braces in preprocessor statements are
horrendously difficult to parse" as in bug #23775, there are no
unbalanced braces everywhere. It's that some code above the code of a
syntactical correct function disturbs c-beginning-of-defun in finding
the beginning of the function.

Put the point into or at the end of function foo, do C-M-home and you
are at the beginning of function foo. Do C-M-home again, and you are not
at the beginning of main, but of the beginning of DBG.

Remove the DBG(). Now C-M-home works, even if the point is inside or the
end of main().

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

From: Alan Mackenzie <acm <at> muc.de>
To: 23818 <at> debbugs.gnu.org
Cc: Rolf Ade <rolf <at> pointsman.de>
Subject: Re: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour
Date: 22 Jun 2016 08:54:29 -0000

Hello, Rolf.

Thanks for the bug report.  I can reproduce it.

I will work on it in the coming hours and days.

-- 
Alan Mackenzie (Nuremberg, Germany).


In article <mailman.1962.1466554808.1216.bug-gnu-emacs <at> gnu.org> you wrote:

> The same in 24.5 and 25.0.95.3:

> emacs -Q

> Open some random emtpy buffer foo.c, put it in c-mode (M-x c-mode) and
> insert the following C code:

> #define DBG(x) x

> DBG(
> static void __dbgAttr () {
>     /* something */
> }
> )

> int main (void) 
> {
>     int i;
>     i++;
>     i++;
>     return i;
> }

> int foo () 
> {
>     int i;
>     i++;
>     i++;
>     return 1;
> }


> Put the point inside function main and C-M-home (or M-x
> c-beginning-of-defun). Instead of the beginning of main() the point is
> here:

> _P_DBG(
> ...

> Far away from

> _P_int main(void)
> ...


> This isn't "unbalanced braces in preprocessor statements are
> horrendously difficult to parse" as in bug #23775, there are no
> unbalanced braces everywhere. It's that some code above the code of a
> syntactical correct function disturbs c-beginning-of-defun in finding
> the beginning of the function.

> Put the point into or at the end of function foo, do C-M-home and you
> are at the beginning of function foo. Do C-M-home again, and you are not
> at the beginning of main, but of the beginning of DBG.

> Remove the DBG(). Now C-M-home works, even if the point is inside or the
> end of main().

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: rolf <at> pointsman.de, 23818 <at> debbugs.gnu.org
Subject: Re: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour
Date: Wed, 22 Jun 2016 18:14:27 +0300

> Date: 22 Jun 2016 08:54:29 -0000
> From: Alan Mackenzie <acm <at> muc.de>
> Cc: Rolf Ade <rolf <at> pointsman.de>
> 
> Thanks for the bug report.  I can reproduce it.
> 
> I will work on it in the coming hours and days.

I don't understand how can CC Mode reliably distinguish the example in
the report from a function that returns a pointer to a function (in
which case what the current code does is correct).

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

From: Alan Mackenzie <acm <at> muc.de>
To: 23818 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour
Date: 24 Jun 2016 14:43:33 -0000

Hello, Eli.

In article <mailman.2009.1466608581.1216.bug-gnu-emacs <at> gnu.org> you wrote:
>> Date: 22 Jun 2016 08:54:29 -0000
>> From: Alan Mackenzie <acm <at> muc.de>
>> Cc: Rolf Ade <rolf <at> pointsman.de>

[ .... ]

> I don't understand how can CC Mode reliably distinguish the example in
> the report from a function that returns a pointer to a function (in
> which case what the current code does is correct).

The solution to the bug involves, in part, configuring CC Mode so that it
knows that "DBG" is a "macro with semicolon".  The other part of the
solution involves testing for such macros at the pertinent spot in
c-beginning-of-decl-1.

See my direct reply to the OP (not yet written).

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Rolf Ade <rolf <at> pointsman.de>
Cc: 23818 <at> debbugs.gnu.org
Subject: Re: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour
Date: 24 Jun 2016 15:02:34 -0000

Hello, Rolf

In article <mailman.1962.1466554808.1216.bug-gnu-emacs <at> gnu.org> you wrote:

> The same in 24.5 and 25.0.95.3:

> emacs -Q

> Open some random emtpy buffer foo.c, put it in c-mode (M-x c-mode) and
> insert the following C code:

> #define DBG(x) x

> DBG(
> static void __dbgAttr () {
>     /* something */
> }
> )

> int main (void) 
> {
>     int i;
>     i++;
>     i++;
>     return i;
> }

> int foo () 
> {
>     int i;
>     i++;
>     i++;
>     return 1;
> }


> Put the point inside function main and C-M-home (or M-x
> c-beginning-of-defun). Instead of the beginning of main() the point is
> here:

> _P_DBG(
> ...

> Far away from

> _P_int main(void)
> ...

Thank you for the bug report, and thanks even more for making it a nice
concise easy to work with example.

> This isn't "unbalanced braces in preprocessor statements are
> horrendously difficult to parse" as in bug #23775, there are no
> unbalanced braces everywhere. It's that some code above the code of a
> syntactical correct function disturbs c-beginning-of-defun in finding
> the beginning of the function.

There are two things here.  The first is that you must configure "DBG" as
a "macro with a semicolon", as detailed in the CC Mode manual, page
"Macros with ;".  For example, you could put the following into your
c-mode-common-hook:

    (setq c-macro-names-with-semicolon '("DBG"))
    (c-make-macro-with-semi-re)

.  That would set up that macro for all your C files.  c-mode-common-hook
is more precisely described on pages "Configuration Basics" and "CC
Hooks" in the CC Mode manual.

The second part of the fix is an actual bug where the software fails to
check for "macros with semicolons" at a critical point.  For that, could
you install the following patch, please, then byte-compile cc-engine.el:



diff -r 4c8ccaedfd6a cc-engine.el
--- a/cc-engine.el	Fri Jun 24 13:06:30 2016 +0000
+++ b/cc-engine.el	Fri Jun 24 14:55:30 2016 +0000
@@ -9135,7 +9135,8 @@
 		(/= last-stmt-start (point))
 		(progn
 		  (c-backward-syntactic-ws lim)
-		  (not (memq (char-before) '(?\; ?} ?: nil))))
+		  (not (or (memq (char-before) '(?\; ?} ?: nil))
+			   (c-at-vsemi-p))))
 		(save-excursion
 		  (backward-char)
 		  (not (looking-at "\\s(")))


If you want any help with applying the patch, or byte compiling, or
setting up a hook, etc., feel free to send me a private email.

[ .... ]

When you've done all this, could you please confirm that it fixes the
problem so I can close the bug, or tell me what's still buggy.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Rolf Ade <rolf <at> pointsman.de>
To: 23818 <at> debbugs.gnu.org
Subject: Re: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour
Date: Wed, 29 Jun 2016 02:57:12 +0200

Hello Alan,

sorry for replying late, was off road.

Am 06/24/2016 05:02 PM, Alan Mackenzie wrote:
> [...]
> There are two things here.  The first is that you must configure "DBG" as
> a "macro with a semicolon", as detailed in the CC Mode manual, page
> "Macros with ;".  For example, you could put the following into your
> c-mode-common-hook:
>
>      (setq c-macro-names-with-semicolon '("DBG"))
>      (c-make-macro-with-semi-re)
>
> [...]
> The second part of the fix is an actual bug where the software fails to
> check for "macros with semicolons" at a critical point.  For that, could
> you install the following patch, please, then byte-compile cc-engine.el:
>
>
>
> diff -r 4c8ccaedfd6a cc-engine.el
> --- a/cc-engine.el	Fri Jun 24 13:06:30 2016 +0000
> +++ b/cc-engine.el	Fri Jun 24 14:55:30 2016 +0000
> @@ -9135,7 +9135,8 @@
>   		(/= last-stmt-start (point))
>   		(progn
>   		  (c-backward-syntactic-ws lim)
> -		  (not (memq (char-before) '(?\; ?} ?: nil))))
> +		  (not (or (memq (char-before) '(?\; ?} ?: nil))
> +			   (c-at-vsemi-p))))
>   		(save-excursion
>   		  (backward-char)
>   		  (not (looking-at "\\s(")))
>

Did so. Patched, byte-compiled, evaluated the configuration in a emacs
-Q: Yes, this works now as expected. With the example file and with
the real case out of the wild
(http://core.tcl.tk/tdom/artifact/2cf83fbbaefad3ef?ln=3268-3362), from
which I stripped my reported example down. Much more pleasant, now.
Thanks.


I wasn't aware of chapter 12 "Customizing Macros" of the cc mode
manual, in some sense I obviously expected that to "just work".

Since I now have looked into chapter 12 of the manual I must say I
also naive expected that to 'just' work ...

Probably this should all work a completetly other way. As

emacs -Q
M-: (require 'cc-mode) RET
C-h v c-macro-names-with-semicolon RET

suggests. The last paragraph reads:

"Note that currently (2008-11-04) this variable is a prototype,
and is likely to disappear or change its form soon."

That docstring may need revisiting.

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

From: Rolf Ade <rolf <at> pointsman.de>
To: 23818 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>
Subject: Re: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour
Date: Tue, 08 Aug 2017 23:42:36 +0200

Hi Alan,

while searching for something else I saw it bug is still open. It's
fixed and good, but just not closed. (Somehow, the following exchanges
about this bug landed in bug#23775.) Clean up and mark as done.

rolf


Rolf Ade <rolf <at> pointsman.de> writes:

> Hello Alan,
>
> sorry for replying late, was off road.
>
> Am 06/24/2016 05:02 PM, Alan Mackenzie wrote:
>> [...]
>> There are two things here.  The first is that you must configure "DBG" as
>> a "macro with a semicolon", as detailed in the CC Mode manual, page
>> "Macros with ;".  For example, you could put the following into your
>> c-mode-common-hook:
>>
>>      (setq c-macro-names-with-semicolon '("DBG"))
>>      (c-make-macro-with-semi-re)
>>
>> [...]
>> The second part of the fix is an actual bug where the software fails to
>> check for "macros with semicolons" at a critical point.  For that, could
>> you install the following patch, please, then byte-compile cc-engine.el:
>>
>>
>>
>> diff -r 4c8ccaedfd6a cc-engine.el
>> --- a/cc-engine.el	Fri Jun 24 13:06:30 2016 +0000
>> +++ b/cc-engine.el	Fri Jun 24 14:55:30 2016 +0000
>> @@ -9135,7 +9135,8 @@
>>   		(/= last-stmt-start (point))
>>   		(progn
>>   		  (c-backward-syntactic-ws lim)
>> -		  (not (memq (char-before) '(?\; ?} ?: nil))))
>> +		  (not (or (memq (char-before) '(?\; ?} ?: nil))
>> +			   (c-at-vsemi-p))))
>>   		(save-excursion
>>   		  (backward-char)
>>   		  (not (looking-at "\\s(")))
>>
>
> Did so. Patched, byte-compiled, evaluated the configuration in a emacs
> -Q: Yes, this works now as expected. With the example file and with
> the real case out of the wild
> (http://core.tcl.tk/tdom/artifact/2cf83fbbaefad3ef?ln=3268-3362), from
> which I stripped my reported example down. Much more pleasant, now.
> Thanks.
>
>
> I wasn't aware of chapter 12 "Customizing Macros" of the cc mode
> manual, in some sense I obviously expected that to "just work".
>
> Since I now have looked into chapter 12 of the manual I must say I
> also naive expected that to 'just' work ...
>
> Probably this should all work a completetly other way. As
>
> emacs -Q
> M-: (require 'cc-mode) RET
> C-h v c-macro-names-with-semicolon RET
>
> suggests. The last paragraph reads:
>
> "Note that currently (2008-11-04) this variable is a prototype,
> and is likely to disappear or change its form soon."
>
> That docstring may need revisiting.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Rolf Ade <rolf <at> pointsman.de>
Cc: 23818-done <at> debbugs.gnu.org
Subject: Re: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour
Date: Sun, 13 Aug 2017 13:17:18 +0000

Hello, Rolf

On Tue, Aug 08, 2017 at 23:42:36 +0200, Rolf Ade wrote:

> Hi Alan,

> while searching for something else I saw it bug is still open. It's
> fixed and good, but just not closed. (Somehow, the following exchanges
> about this bug landed in bug#23775.) Clean up and mark as done.

Yes, there was a bit of confusion back then.  Sorry about that.

With this Email, I'm closing bug #23818.  Thanks for the reminder.

> rolf

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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