bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Rolf Ade]

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().

bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Alan Mackenzie]

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@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().

bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Eli Zaretskii]

> Date: 22 Jun 2016 08:54:29 -0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Rolf Ade <rolf@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).

bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Alan Mackenzie]

Hello, Rolf

In article <mailman.1962.1466554808.1216.bug-gnu-emacs@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).

bug#23775: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Rolf Ade]

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.

bug#23775: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Alan Mackenzie]

Hello, Rolf.

On Wed, Jun 29, 2016 at 01:22:27AM +0200, Rolf Ade wrote:

> Hello Alan,

> sorry for replying late, was off road.

No problems.

> 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.

Thank you.

> 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.

Whoops!  It needed revisiting 7½ years ago, but better late than never!

I've committed the changes, to the CC Mode repository, the Emacs master
branch and the XEmacs package repository.  I'm going to close the bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23775: bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Alan Mackenzie]

Bug fixed in master branch.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Rolf Ade]

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.

bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Rolf Ade]

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@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.

bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Alan Mackenzie]

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).

bug#23818: 25.0.95.3: c-beginning-of-defun misbehaviour

[Alan Mackenzie]

Hello, Eli.

In article <mailman.2009.1466608581.1216.bug-gnu-emacs@gnu.org> you wrote:
>> Date: 22 Jun 2016 08:54:29 -0000
>> From: Alan Mackenzie <acm@muc.de>
>> Cc: Rolf Ade <rolf@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).