bug#636: Please fix before the release of 23.1

bug#636: Please fix before the release of 23.1

[Glenn Morris]

More info from

http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00416.html

Ulrich Mueller wrote:

> The problem goes away if I revert the following change:
>
> 2008-06-27  Alan Mackenzie  <acm@muc.de>
>
> 	* progmodes/cc-defs.el (c-emacs-features): New feature
> 	'argumentative-bod-function.
>
> --- progmodes/cc-defs.el	6 May 2008 07:18:12 -0000	1.57
> +++ progmodes/cc-defs.el	27 Jun 2008 21:12:46 -0000	1.58
> @@ -1440,6 +1440,14 @@
>  			 '1-bit)
>  		       list)))
>  
> +    ;; In Emacs >= 23, beginning-of-defun will passes its parameter to
> +    ;; beginning-of-defun-function.  Assume end-of-defun does the same.
> +    (let ((beginning-of-defun-function
> +	   (lambda (&optional arg)
> +	     (not (eq arg nil)))))
> +      (if (beginning-of-defun 1)
> +	  (setq list (cons 'argumentative-bod-function list))))
> +
>      (let ((buf (generate-new-buffer " test"))
>  	  parse-sexp-lookup-properties
>  	  parse-sexp-ignore-comments
> @@ -1539,6 +1547,9 @@
>  
>  '8-bit              8 bit syntax entry flags (XEmacs style).
>  '1-bit              1 bit syntax entry flags (Emacs style).
> +'argumentative-bod-function         beginning-of-defun passes ARG through
> +                    to a non-null beginning-of-defun-function.  It is assumed
> +		    the end-of-defun does the same thing.
>  'syntax-properties  It works to override the syntax for specific characters
>  		    in the buffer with the 'syntax-table property.  It's
>  		    always set - CC Mode no longer works in emacsen without

bug#636: Please fix before the release of 23.1

[Chong Yidong]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Sun, 10 Aug 2008, I wrote:
>
>> ,----[ test.el ]
>> | (progn
>> |   (require 'cc-mode))
>> `----
>
>> $ emacs -Q test.el
>> M-x eval-buffer
>
>> This will result in an error: Invalid read syntax: ")"
>
> The problem goes away if I revert the following change:
>
> 2008-06-27  Alan Mackenzie  <acm@muc.de>
>
> 	* progmodes/cc-defs.el (c-emacs-features): New feature
> 	'argumentative-bod-function.

Thanks for pinpointing this.

In fact, it's apparently not a problem with cc-mode, but with Emacs.
Here's a stripped-down recipe:

1. Create a file foo.el in your lisp path with the following contents:

(defconst foo
  (let ((beginning-of-defun-function
	 (lambda (&optional arg)
	   (not (eq arg nil)))))
    (progn
      (beginning-of-defun 1))))

(provide 'foo)

2. Byte-compile it (M-x byte-compile-file RET).

3. Create a file test.el with the following contents:

(progn
  (require 'foo))

4. emacs test.el

5. M-x eval-buffer

Debugger entered--Lisp error: (invalid-read-syntax ")")
  eval-buffer()  ; Reading at buffer position 25
  call-interactively(eval-buffer t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)


I don't know what causes this bug, though.  Anyone?

bug#636: Please fix before the release of 23.1

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> (defconst foo
>   (let ((beginning-of-defun-function
> 	 (lambda (&optional arg)
> 	   (not (eq arg nil)))))
>     (progn
>       (beginning-of-defun 1))))

By the way, replacing `progn' with `save-excursion' makes the bug go
away (this makes cc-def.el work too).  Why?  I don't know.

bug#636: Please fix before the release of 23.1

[ＯＦＦＩＣＥ ZERO]

Do not send any mail1!
no thank you



----- Original Message ----- 
From: "Chong Yidong" <cyd@stupidchicken.com>
To: "Ulrich Mueller" <ulm@gentoo.org>
Cc: <emacs-devel@gnu.org>; <636@emacsbugs.donarmstrong.com>; "Michael Olson" 
<mwolson@gnu.org>; "Alan Mackenzie" <acm@muc.de>
Sent: Monday, August 11, 2008 7:18 AM
Subject: bug#636: Please fix before the release of 23.1


> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> (defconst foo
>>   (let ((beginning-of-defun-function
>> (lambda (&optional arg)
>>    (not (eq arg nil)))))
>>     (progn
>>       (beginning-of-defun 1))))
>
> By the way, replacing `progn' with `save-excursion' makes the bug go
> away (this makes cc-def.el work too).  Why?  I don't know.
>
>
>
> 

bug#636: Please fix before the release of 23.1

[ＯＦＦＩＣＥ ZERO]

Do not send any mail1!
no thank you



----- Original Message ----- 
From: "Chong Yidong" <cyd@stupidchicken.com>
To: "Ulrich Mueller" <ulm@gentoo.org>
Cc: "Michael Olson" <mwolson@gnu.org>; <636@emacsbugs.donarmstrong.com>; 
"Alan Mackenzie" <acm@muc.de>; <emacs-devel@gnu.org>
Sent: Monday, August 11, 2008 7:15 AM
Subject: bug#636: Please fix before the release of 23.1


> Ulrich Mueller <ulm@gentoo.org> writes:
>
>>>>>>> On Sun, 10 Aug 2008, I wrote:
>>
>>> ,----[ test.el ]
>>> | (progn
>>> |   (require 'cc-mode))
>>> `----
>>
>>> $ emacs -Q test.el
>>> M-x eval-buffer
>>
>>> This will result in an error: Invalid read syntax: ")"
>>
>> The problem goes away if I revert the following change:
>>
>> 2008-06-27  Alan Mackenzie  <acm@muc.de>
>>
>> * progmodes/cc-defs.el (c-emacs-features): New feature
>> 'argumentative-bod-function.
>
> Thanks for pinpointing this.
>
> In fact, it's apparently not a problem with cc-mode, but with Emacs.
> Here's a stripped-down recipe:
>
> 1. Create a file foo.el in your lisp path with the following contents:
>
> (defconst foo
>  (let ((beginning-of-defun-function
> (lambda (&optional arg)
>    (not (eq arg nil)))))
>    (progn
>      (beginning-of-defun 1))))
>
> (provide 'foo)
>
> 2. Byte-compile it (M-x byte-compile-file RET).
>
> 3. Create a file test.el with the following contents:
>
> (progn
>  (require 'foo))
>
> 4. emacs test.el
>
> 5. M-x eval-buffer
>
> Debugger entered--Lisp error: (invalid-read-syntax ")")
>  eval-buffer()  ; Reading at buffer position 25
>  call-interactively(eval-buffer t nil)
>  execute-extended-command(nil)
>  call-interactively(execute-extended-command nil nil)
>
>
> I don't know what causes this bug, though.  Anyone?
>
>
>
> 

bug#636: Please fix before the release of 23.1

[ＯＦＦＩＣＥ ZERO]

Do not send any mail  !
no thank you




----- Original Message ----- 
From: "Glenn Morris" <rgm@gnu.org>
To: <636@emacsbugs.donarmstrong.com>
Sent: Monday, August 11, 2008 3:55 AM
Subject: bug#636: Please fix before the release of 23.1


>
> More info from
>
> http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00416.html
>
> Ulrich Mueller wrote:
>
>> The problem goes away if I revert the following change:
>>
>> 2008-06-27  Alan Mackenzie  <acm@muc.de>
>>
>> * progmodes/cc-defs.el (c-emacs-features): New feature
>> 'argumentative-bod-function.
>>
>> --- progmodes/cc-defs.el 6 May 2008 07:18:12 -0000 1.57
>> +++ progmodes/cc-defs.el 27 Jun 2008 21:12:46 -0000 1.58
>> @@ -1440,6 +1440,14 @@
>>  '1-bit)
>>         list)))
>>
>> +    ;; In Emacs >= 23, beginning-of-defun will passes its parameter to
>> +    ;; beginning-of-defun-function.  Assume end-of-defun does the same.
>> +    (let ((beginning-of-defun-function
>> +    (lambda (&optional arg)
>> +      (not (eq arg nil)))))
>> +      (if (beginning-of-defun 1)
>> +   (setq list (cons 'argumentative-bod-function list))))
>> +
>>      (let ((buf (generate-new-buffer " test"))
>>    parse-sexp-lookup-properties
>>    parse-sexp-ignore-comments
>> @@ -1539,6 +1547,9 @@
>>
>>  '8-bit              8 bit syntax entry flags (XEmacs style).
>>  '1-bit              1 bit syntax entry flags (Emacs style).
>> +'argumentative-bod-function         beginning-of-defun passes ARG 
>> through
>> +                    to a non-null beginning-of-defun-function.  It is 
>> assumed
>> +     the end-of-defun does the same thing.
>>  'syntax-properties  It works to override the syntax for specific 
>> characters
>>      in the buffer with the 'syntax-table property.  It's
>>      always set - CC Mode no longer works in emacsen without
>
>
>
> 

bug#636: Info received (bug#636: Please fix before the release of 23.1)

[ＯＦＦＩＣＥ ZERO]

Do not send me any mail !
No thank you　！！

----- Original Message ----- 
From: "Emacs bug Tracking System" <don@donarmstrong.com>
To: "ＯＦＦＩＣＥ　ZERO" <hi-oh230@air.ocn.ne.jp>
Sent: Monday, August 11, 2008 10:00 AM
Subject: bug#636: Info received (bug#636: Please fix before the release of 
23.1)



Thank you for the additional information you have supplied regarding
this bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Emacs Bugs <bug-gnu-emacs@gnu.org>

If you wish to submit further information on this problem, please
send it to 636@emacsbugs.donarmstrong.com, as before.

Please do not send mail to don@donarmstrong.com unless you wish
to report a problem with the Bug-tracking system.


-- 
636: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=636
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems 

bug#636: Info received (bug#636: Please fix before the release of 23.1)

[ＯＦＦＩＣＥ ZERO]

Do not send me any mail !
No thank you　！！

----- Original Message ----- 
From: "Emacs bug Tracking System" <don@donarmstrong.com>
To: "ＯＦＦＩＣＥ　ZERO" <hi-oh230@air.ocn.ne.jp>
Sent: Monday, August 11, 2008 10:00 AM
Subject: bug#636: Info received (bug#636: Please fix before the release of 
23.1)



Thank you for the additional information you have supplied regarding
this bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Emacs Bugs <bug-gnu-emacs@gnu.org>

If you wish to submit further information on this problem, please
send it to 636@emacsbugs.donarmstrong.com, as before.

Please do not send mail to don@donarmstrong.com unless you wish
to report a problem with the Bug-tracking system.


-- 
636: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=636
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems 

bug#636: Please fix before the release of 23.1

[Ulrich Mueller]

>>>>> On Sun, 10 Aug 2008, Chong Yidong wrote:

> Thanks for pinpointing this.

> In fact, it's apparently not a problem with cc-mode, but with Emacs.
> Here's a stripped-down recipe:

> 1. Create a file foo.el in your lisp path with the following contents:

> (defconst foo
>   (let ((beginning-of-defun-function
> 	 (lambda (&optional arg)
> 	   (not (eq arg nil)))))
>     (progn
>       (beginning-of-defun 1))))

> (provide 'foo)

Calling beginning-of-defun will move point, right?

And since beginning-of-defun-function is essentially defined as a
no-op, point will just be moved to the beginning-of-line. (In fact,
eval-buffer on foo.el results in an infinite loop.)

> By the way, replacing `progn' with `save-excursion' makes the bug go
> away (this makes cc-def.el work too). Why? I don't know.

Indeed. If we agree that the bug is in cc-defs.el, then the following
patch should fix it:

--- progmodes/cc-defs.el	27 Jun 2008 21:12:46 -0000	1.58
+++ progmodes/cc-defs.el	11 Aug 2008 07:11:04 -0000
@@ -1445,7 +1445,7 @@
     (let ((beginning-of-defun-function
 	   (lambda (&optional arg)
 	     (not (eq arg nil)))))
-      (if (beginning-of-defun 1)
+      (if (save-excursion (beginning-of-defun 1))
 	  (setq list (cons 'argumentative-bod-function list))))
 
     (let ((buf (generate-new-buffer " test"))

Ulrich

bug#636: Please fix before the release of 23.1

[Alan Mackenzie]

Hi, Ulrich and Yidong!

Thanks for CC'ing me in on this one.

On Mon, Aug 11, 2008 at 09:18:55AM +0200, Ulrich Mueller wrote:
> >>>>> On Sun, 10 Aug 2008, Chong Yidong wrote:

> > In fact, it's apparently not a problem with cc-mode, but with Emacs.
> > Here's a stripped-down recipe:

> > 1. Create a file foo.el in your lisp path with the following contents:

> > (defconst foo
> >   (let ((beginning-of-defun-function
> > 	 (lambda (&optional arg)
> > 	   (not (eq arg nil)))))
> >     (progn
> >       (beginning-of-defun 1))))

> > (provide 'foo)

> Calling beginning-of-defun will move point, right?

> And since beginning-of-defun-function is essentially defined as a
> no-op, point will just be moved to the beginning-of-line. (In fact,
> eval-buffer on foo.el results in an infinite loop.)

> > By the way, replacing `progn' with `save-excursion' makes the bug go
> > away (this makes cc-def.el work too). Why? I don't know.

> Indeed. If we agree that the bug is in cc-defs.el, then the following
> patch should fix it:

> --- progmodes/cc-defs.el	27 Jun 2008 21:12:46 -0000	1.58
> +++ progmodes/cc-defs.el	11 Aug 2008 07:11:04 -0000
> @@ -1445,7 +1445,7 @@
>      (let ((beginning-of-defun-function
>  	   (lambda (&optional arg)
>  	     (not (eq arg nil)))))
> -      (if (beginning-of-defun 1)
> +      (if (save-excursion (beginning-of-defun 1))
>  	  (setq list (cons 'argumentative-bod-function list))))

>      (let ((buf (generate-new-buffer " test"))

I protest against this "fix".  :-)  Not against the fix as such (though
it is somewhat ugly, and would need some comments), just that the bug it
fixes is not understood.  Therefore, it is NOT a fix.  It is still a bug,
which will cause pain somewhere else.

> Ulrich

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#636: Please fix before the release of 23.1

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> it is somewhat ugly, and would need some comments), just that the bug it
> fixes is not understood.

It's pretty simple.  You are moving point while load/eval-buffer/etc. is
reading the buffer, where reading the buffer always means reading from
point.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#636: Please fix before the release of 23.1

[Michael Olson]

Ulrich Mueller <ulm@gentoo.org> writes:

> Indeed. If we agree that the bug is in cc-defs.el, then the following
> patch should fix it:
>
> --- progmodes/cc-defs.el	27 Jun 2008 21:12:46 -0000	1.58
> +++ progmodes/cc-defs.el	11 Aug 2008 07:11:04 -0000
> @@ -1445,7 +1445,7 @@
>      (let ((beginning-of-defun-function
>  	   (lambda (&optional arg)
>  	     (not (eq arg nil)))))
> -      (if (beginning-of-defun 1)
> +      (if (save-excursion (beginning-of-defun 1))
>  	  (setq list (cons 'argumentative-bod-function list))))
>
>      (let ((buf (generate-new-buffer " test"))

This patch fixes the problem for me as well.  It's interesting that
evaluating a top-level defconst definition can screw up the
byte-compiler though ... would it make sense for the byte-compiler to
automatically do a save-excursion around the processing of each
top-level form in a given file?

-- 
|       Michael Olson  |  FSF Associate Member #652     |
| http://mwolson.org/  |  Hobbies: Lisp, HCoop          |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'

bug#636: Please fix before the release of 23.1

[Chong Yidong]

Ulrich Mueller <ulm@gentoo.org> writes:

>> (defconst foo
>>   (let ((beginning-of-defun-function
>> 	 (lambda (&optional arg)
>> 	   (not (eq arg nil)))))
>>     (progn
>>       (beginning-of-defun 1))))
>
>> (provide 'foo)
>
> Calling beginning-of-defun will move point, right?
>
> And since beginning-of-defun-function is essentially defined as a
> no-op, point will just be moved to the beginning-of-line. (In fact,
> eval-buffer on foo.el results in an infinite loop.)

Aha, I see.

So the question is, should we make the change to cc-defs.el, or (as
suggested by Michael Olson) make the byte-compiler wrap around each
variable definition with `save-excursion'?

Even with the latter solution, incorrectly written elisp in variable
definitions can still create problems.  For example, `save-excursion'
won't save us if the elisp runs `kill-buffer'.

This indicates that we fix cc-defs.el, and leave the rest of Emacs
alone.

bug#636: Please fix before the release of 23.1

[Alan Mackenzie]

Hi, Andreas

On Mon, Aug 11, 2008 at 10:54:59AM +0200, Andreas Schwab wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > it is somewhat ugly, and would need some comments), just that the bug
> > it fixes is not understood.

> It's pretty simple.  You are moving point while load/eval-buffer/etc.
> is reading the buffer, where reading the buffer always means reading
> from point.

Ah!  I missed that, because it wasn't me (in the capacity of CC Mode
maintainer) that moved point.

Thanks!

> Andreas.

> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

bug#636: Please fix before the release of 23.1

[Alan Mackenzie]

Hi, everybody!

On Mon, Aug 11, 2008 at 12:30:04PM -0400, Chong Yidong wrote:
> Ulrich Mueller <ulm@gentoo.org> writes:

> >> (defconst foo
> >>   (let ((beginning-of-defun-function
> >> 	 (lambda (&optional arg)
> >> 	   (not (eq arg nil)))))
> >>     (progn
> >>       (beginning-of-defun 1))))

> >> (provide 'foo)

> > Calling beginning-of-defun will move point, right?

> > And since beginning-of-defun-function is essentially defined as a
> > no-op, point will just be moved to the beginning-of-line. (In fact,
> > eval-buffer on foo.el results in an infinite loop.)

> Aha, I see.

> So the question is, should we make the change to cc-defs.el, or (as
> suggested by Michael Olson) make the byte-compiler wrap around each
> variable definition with `save-excursion'?

The way I see it, it's a bug in `beginning-of-defun'.  The docstring
says that a non-nil `beginning-of-defun-function' finds the pertinent
place, but beginning-of-defun then moves point somewhere else.  I HATE
things that are ostensibly "helpful", but in reality are dumbing down,
and mainly just foul things up.

I would be in favour of NOT moving point after a BOD-function has done
its work.  However, I wouldn't campaign too hard about it, because ....

CC Mode should remain compatible with lots of Emacsen, including 21.n.
That means I'll have to modify CC Mode anyway.  So I will.

> Even with the latter solution, incorrectly written elisp in variable
> definitions can still create problems.  For example, `save-excursion'
> won't save us if the elisp runs `kill-buffer'.

Hey, that's an idea!  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).