GNU bug report logs -
#20240
25.0.50; CC Mode broken fontification and commenting
Previous Next
Reported by: Mark Oteiza <mvoteiza <at> udel.edu>
Date: Wed, 1 Apr 2015 10:52:01 UTC
Severity: normal
Tags: fixed
Found in version 25.0.50
Fixed in version 25.1
Done: Mark Oteiza <mvoteiza <at> udel.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20240 in the body.
You can then email your comments to 20240 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#20240
; Package
emacs
.
(Wed, 01 Apr 2015 10:52:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mark Oteiza <mvoteiza <at> udel.edu>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 01 Apr 2015 10:52:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From emacs -Q:
1. C-x C-f foo.c RET
2. Insert: { RET }
3. Select the first line and M-;
Only `/* ` is inserted at the beginning of the buffer, which is wrong.
4. Undo: C-/
The braces remain fontified as comments.
In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
of 2015-03-31 on logos
Repository revision: 8d1d8fc474bd9ed22cbe8b80125c8ce89dc62b57
Configured using:
`configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --without-gconf --with-x-toolkit=lucid
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
--param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
Important settings:
value of $LC_COLLATE: C
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org
:
bug#20240
; Package
emacs,cc-mode
.
(Wed, 01 Apr 2015 19:22:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 20240 <at> debbugs.gnu.org (full text, mbox):
Hello, Mark.
In article <mailman.3120.1427885528.31049.bug-gnu-emacs <at> gnu.org> you wrote:
>>From emacs -Q:
> 1. C-x C-f foo.c RET
> 2. Insert: { RET }
> 3. Select the first line and M-;
> Only `/* ` is inserted at the beginning of the buffer, which is wrong.
It actually signals an error at that point, which is indeed wrong.
I've just committed a fix to the Emacs repository. Could you please update
your sources, rebuild, and confirm that the fix works, please.
Thanks for taking the trouble to report this bug.
> 4. Undo: C-/
> The braces remain fontified as comments.
> In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
> of 2015-03-31 on logos
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org
:
bug#20240
; Package
emacs,cc-mode
.
(Wed, 01 Apr 2015 20:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
Alan Mackenzie <acm <at> muc.de> writes:
> In article <mailman.3120.1427885528.31049.bug-gnu-emacs <at> gnu.org> you wrote:
>>>From emacs -Q:
>
>> 1. C-x C-f foo.c RET
>> 2. Insert: { RET }
>> 3. Select the first line and M-;
>
>> Only `/* ` is inserted at the beginning of the buffer, which is wrong.
>
> It actually signals an error at that point, which is indeed wrong.
Ah, I missed it then, thanks.
> I've just committed a fix to the Emacs repository. Could you please update
> your sources, rebuild, and confirm that the fix works, please.
>
> Thanks for taking the trouble to report this bug.
You're welcome. You fixed the example I gave, but as it turns out my
example was too minimal. Hopefully this is better: uncommenting the
commented line in the following will signal a jit-lock error
int main(void) {
for(;;) {
/* return 0; */
}
}
Repeating M-; on that line, eventually I get `return 0;` uncommented but
fontified as a comment.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org
:
bug#20240
; Package
emacs,cc-mode
.
(Fri, 03 Apr 2015 20:53:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 20240 <at> debbugs.gnu.org (full text, mbox):
Hello, Stefan and Mark.
In article <mailman.3163.1427918769.31049.bug-gnu-emacs <at> gnu.org> you wrote:
> Alan Mackenzie <acm <at> muc.de> writes:
>> In article <mailman.3120.1427885528.31049.bug-gnu-emacs <at> gnu.org> you wrote:
>>>>From emacs -Q:
>>
>>> 1. C-x C-f foo.c RET
>>> 2. Insert: { RET }
>>> 3. Select the first line and M-;
>>
>>> Only `/* ` is inserted at the beginning of the buffer, which is wrong.
>>
>> It actually signals an error at that point, which is indeed wrong.
> Ah, I missed it then, thanks.
>> I've just committed a fix to the Emacs repository. Could you please update
>> your sources, rebuild, and confirm that the fix works, please.
>>
>> Thanks for taking the trouble to report this bug.
> You're welcome. You fixed the example I gave, but as it turns out my
> example was too minimal. Hopefully this is better: uncommenting the
> commented line in the following will signal a jit-lock error
> int main(void) {
> for(;;) {
> /* return 0; */
> }
> }
> Repeating M-; on that line, eventually I get `return 0;` uncommented but
> fontified as a comment.
That is actually a different (though similar) bug.
Stefan, do you have any objections to the patch below, which widens the
buffer in jit-lock-after-change before setting the 'fontified text
properties? Mark's (latest) bug is happening because `comment-dwim' is
narrowing to an existing comment which isn't at BOL, and
jit-lock-after-change is erroring because it's trying to set the text
properties at col 0, but can't (because of the narrowing).
Like you said a while back, narrowing can cause problems.
diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index 0faabeb..d5651c6 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -650,12 +650,14 @@ will take place when text is fontified stealthily."
(let ((jit-lock-start start)
(jit-lock-end end))
(with-buffer-prepared-for-jit-lock
- (run-hook-with-args 'jit-lock-after-change-extend-region-functions
- start end old-len)
- ;; Make sure we change at least one char (in case of deletions).
- (setq jit-lock-end (min (max jit-lock-end (1+ start)) (point-max)))
- ;; Request refontification.
- (put-text-property jit-lock-start jit-lock-end 'fontified nil))
+ (save-restriction
+ (widen)
+ (run-hook-with-args 'jit-lock-after-change-extend-region-functions
+ start end old-len)
+ ;; Make sure we change at least one char (in case of deletions).
+ (setq jit-lock-end (min (max jit-lock-end (1+ start)) (point-max)))
+ ;; Request refontification.
+ (put-text-property jit-lock-start jit-lock-end 'fontified nil)))
;; Mark the change for deferred contextual refontification.
(when jit-lock-context-unfontify-pos
(setq jit-lock-context-unfontify-pos
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org
:
bug#20240
; Package
emacs,cc-mode
.
(Fri, 03 Apr 2015 22:10:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 20240 <at> debbugs.gnu.org (full text, mbox):
> - (run-hook-with-args 'jit-lock-after-change-extend-region-functions
> - start end old-len)
> - ;; Make sure we change at least one char (in case of deletions).
> - (setq jit-lock-end (min (max jit-lock-end (1+ start)) (point-max)))
> - ;; Request refontification.
> - (put-text-property jit-lock-start jit-lock-end 'fontified nil))
> + (save-restriction
> + (widen)
> + (run-hook-with-args 'jit-lock-after-change-extend-region-functions
> + start end old-len)
> + ;; Make sure we change at least one char (in case of deletions).
> + (setq jit-lock-end (min (max jit-lock-end (1+ start)) (point-max)))
> + ;; Request refontification.
> + (put-text-property jit-lock-start jit-lock-end 'fontified nil)))
Widening during the call to
jit-lock-after-change-extend-region-functions seems wrong. But I guess
there can be meaningful cases where
jit-lock-after-change-extend-region-functions could return positions
outside of the narrowed region, so I'd be OK with widening during the
subsequent `put-text-property'.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org
:
bug#20240
; Package
emacs,cc-mode
.
(Sat, 04 Apr 2015 10:46:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 20240 <at> debbugs.gnu.org (full text, mbox):
Hello, Stefan and Mark.
On Fri, Apr 03, 2015 at 06:09:12PM -0400, Stefan Monnier wrote:
> > - (run-hook-with-args 'jit-lock-after-change-extend-region-functions
> > - start end old-len)
> > - ;; Make sure we change at least one char (in case of deletions).
> > - (setq jit-lock-end (min (max jit-lock-end (1+ start)) (point-max)))
> > - ;; Request refontification.
> > - (put-text-property jit-lock-start jit-lock-end 'fontified nil))
> > + (save-restriction
> > + (widen)
> > + (run-hook-with-args 'jit-lock-after-change-extend-region-functions
> > + start end old-len)
> > + ;; Make sure we change at least one char (in case of deletions).
> > + (setq jit-lock-end (min (max jit-lock-end (1+ start)) (point-max)))
> > + ;; Request refontification.
> > + (put-text-property jit-lock-start jit-lock-end 'fontified nil)))
> Widening during the call to
> jit-lock-after-change-extend-region-functions seems wrong. But I guess
> there can be meaningful cases where
> jit-lock-after-change-extend-region-functions could return positions
> outside of the narrowed region, so I'd be OK with widening during the
> subsequent `put-text-property'.
Thanks. I've just committed that change.
Mark, would you please update your Emacs and build it again, then test
whether or not your bug has finally been fixed, then let us know. Then
I can close the bug. Thanks!
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org
:
bug#20240
; Package
emacs,cc-mode
.
(Sat, 04 Apr 2015 14:48:02 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
Alan Mackenzie <acm <at> muc.de> writes:
> Thanks. I've just committed that change.
>
> Mark, would you please update your Emacs and build it again, then test
> whether or not your bug has finally been fixed, then let us know. Then
> I can close the bug. Thanks!
Fixed. Thank you!
Added tag(s) fixed.
Request was from
Mark Oteiza <mvoteiza <at> udel.edu>
to
control <at> debbugs.gnu.org
.
(Thu, 27 Aug 2015 17:44:01 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 25.1, send any further explanations to
20240 <at> debbugs.gnu.org and Mark Oteiza <mvoteiza <at> udel.edu>
Request was from
Mark Oteiza <mvoteiza <at> udel.edu>
to
control <at> debbugs.gnu.org
.
(Thu, 27 Aug 2015 17:44:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 25 Sep 2015 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.