GNU bug report logs -
#33163
Adding a " in c++-mode fills the whole file with red
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 33163 in the body.
You can then email your comments to 33163 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#33163; Package
emacs.
(Fri, 26 Oct 2018 14:06:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Konstantin Kharlamov <hi-angel <at> yandex.ru>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 26 Oct 2018 14:06:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This long-standing problem appears occasionally, and only disappears if you kill the buffer completely, then reopen the file. I never got to report it because I never could find steps to reproduce it… until now :) Nvm the non-sense code, I reduced testcase as far as I managed.
# Steps to reproduce:
1. Save the following text in `test.cpp`
int main() {
puts(It's");
auto foo = []()-> void { };
puts("It's");
}
2. Open `emacs -Q ./test.cpp`
3. Now, the text lacks a quote in the first `puts(It's");`. Add it so it looks like `puts("It's");`. Essentially, if you'd compile it with g++, it lacks any syntax error besides `puts` being undeclared.
# Expected
The line with `auto foo…` is not red.
# Actual
The line with `auto foo…` (in particular) becomes red.
# Additional information
Emacs version GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-10-01, build with -flto.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:
bug#33163; Package
emacs,cc-mode.
(Sun, 28 Oct 2018 10:50:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 33163 <at> debbugs.gnu.org (full text, mbox):
In article <mailman.2795.1540562775.1284.bug-gnu-emacs <at> gnu.org> you wrote:
> This long-standing problem appears occasionally, and only disappears if
> you kill the buffer completely, then reopen the file. I never got to
> report it because I never could find steps to reproduce it… until now
> :) Nvm the non-sense code, I reduced testcase as far as I managed.
> # Steps to reproduce:
> 1. Save the following text in `test.cpp`
> int main() {
> puts(It's");
> auto foo = []()-> void { };
> puts("It's");
> }
> 2. Open `emacs -Q ./test.cpp`
> 3. Now, the text lacks a quote in the first `puts(It's");`. Add it so
> it looks like `puts("It's");`. Essentially, if you'd compile it with
> g++, it lacks any syntax error besides `puts` being undeclared.
> # Expected
> The line with `auto foo…` is not red.
> # Actual
> The line with `auto foo…` (in particular) becomes red.
Thanks for taking the trouble to report this bug. Thanks even more for
condensing it down to a minimal test case.
The following patch should fix it. Would you please apply the patch,
recompile .../lisp/progmodes/cc-mode.el, load the new file in to your
Emacs (or restart Emacs), then try it out on your real C++ code. Then
please let me know whether it's working or not, and if not, how it's
going wrong. Thanks!
> # Additional information
> Emacs version GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
> Version 3.22.30) of 2018-10-01, build with -flto.
diff -r 2f7029fa229d cc-mode.el
--- a/cc-mode.el Sun Oct 14 20:01:07 2018 +0000
+++ b/cc-mode.el Sun Oct 28 10:20:38 2018 +0000
@@ -1216,21 +1216,21 @@
(if (eq beg-literal-type 'string)
(setq c-new-BEG (min (car beg-limits) c-new-BEG))))
- ((< c-new-END (point-max))
- (goto-char (1+ c-new-END)) ; might be a newline.
+ ((< end (point-max))
+ (goto-char (1+ end)) ; might be a newline.
;; In the following regexp, the initial \n caters for a newline getting
;; joined to a preceding \ by the removal of what comes between.
(re-search-forward "[\n\r]?\\(\\\\\\(.\\|\n\\|\r\\)\\|[^\\\n\r]\\)*"
nil t)
;; We're at an EOLL or point-max.
- (setq c-new-END (min (1+ (point)) (point-max)))
- (goto-char c-new-END)
- (if (equal (c-get-char-property (1- (point)) 'syntax-table) '(15))
- (if (memq (char-before) '(?\n ?\r))
+ (setq c-new-END (max c-new-END (min (1+ (point)) (point-max))))
+ (if (equal (c-get-char-property (point) 'syntax-table) '(15))
+ (if (memq (char-after) '(?\n ?\r))
;; Normally terminated invalid string.
- (progn
+ (let ((eoll-1 (point)))
+ (forward-char)
(backward-sexp)
- (c-clear-char-property (1- c-new-END) 'syntax-table)
+ (c-clear-char-property eoll-1 'syntax-table)
(c-clear-char-property (point) 'syntax-table))
;; Opening " at EOB.
(c-clear-char-property (1- (point)) 'syntax-table))
@@ -1238,7 +1238,7 @@
;; Opening " on last line of text (without EOL).
(c-clear-char-property (point) 'syntax-table))))
- (t (goto-char c-new-END)
+ (t (goto-char end) ; point-max
(if (c-search-backward-char-property 'syntax-table '(15) c-new-BEG)
(c-clear-char-property (point) 'syntax-table))))
@@ -1327,9 +1327,9 @@
(while (progn
(setq s (parse-partial-sexp (point) c-new-END nil
nil s 'syntax-table))
- (and (not (nth 3 s))
- (< (point) c-new-END)
- (not (memq (char-before) c-string-delims)))))
+ (and (< (point) c-new-END)
+ (or (not (nth 3 s))
+ (not (memq (char-before) c-string-delims))))))
;; We're at the start of a string.
(memq (char-before) c-string-delims)))
(if (c-unescaped-nls-in-string-p (1- (point)))
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:
bug#33163; Package
emacs,cc-mode.
(Sun, 28 Oct 2018 11:22:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 33163 <at> debbugs.gnu.org (full text, mbox):
On 10/28/18 1:49 PM, Alan Mackenzie wrote:
> In article <mailman.2795.1540562775.1284.bug-gnu-emacs <at> gnu.org> you wrote:
>> This long-standing problem appears occasionally, and only disappears if
>> you kill the buffer completely, then reopen the file. I never got to
>> report it because I never could find steps to reproduce it… until now
>> :) Nvm the non-sense code, I reduced testcase as far as I managed.
>
>> # Steps to reproduce:
>
>> 1. Save the following text in `test.cpp`
>> int main() {
>> puts(It's");
>> auto foo = []()-> void { };
>> puts("It's");
>> }
>> 2. Open `emacs -Q ./test.cpp`
>> 3. Now, the text lacks a quote in the first `puts(It's");`. Add it so
>> it looks like `puts("It's");`. Essentially, if you'd compile it with
>> g++, it lacks any syntax error besides `puts` being undeclared.
>
>> # Expected
>
>> The line with `auto foo…` is not red.
>
>> # Actual
>
>> The line with `auto foo…` (in particular) becomes red.
>
> Thanks for taking the trouble to report this bug. Thanks even more for
> condensing it down to a minimal test case.
>
> The following patch should fix it. Would you please apply the patch,
> recompile .../lisp/progmodes/cc-mode.el, load the new file in to your
> Emacs (or restart Emacs), then try it out on your real C++ code. Then
> please let me know whether it's working or not, and if not, how it's
> going wrong. Thanks!
Thank you for the quick patch! I tried to do some editing and
navigating, and all seems well. More real testing I can only do on
Monday, so I guess I'll reply somewhere on Monday evening.
>
>> # Additional information
>
>> Emacs version GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
>> Version 3.22.30) of 2018-10-01, build with -flto.
>
>
>
> diff -r 2f7029fa229d cc-mode.el
> --- a/cc-mode.el Sun Oct 14 20:01:07 2018 +0000
> +++ b/cc-mode.el Sun Oct 28 10:20:38 2018 +0000
> @@ -1216,21 +1216,21 @@
> (if (eq beg-literal-type 'string)
> (setq c-new-BEG (min (car beg-limits) c-new-BEG))))
>
> - ((< c-new-END (point-max))
> - (goto-char (1+ c-new-END)) ; might be a newline.
> + ((< end (point-max))
> + (goto-char (1+ end)) ; might be a newline.
> ;; In the following regexp, the initial \n caters for a newline getting
> ;; joined to a preceding \ by the removal of what comes between.
> (re-search-forward "[\n\r]?\\(\\\\\\(.\\|\n\\|\r\\)\\|[^\\\n\r]\\)*"
> nil t)
> ;; We're at an EOLL or point-max.
> - (setq c-new-END (min (1+ (point)) (point-max)))
> - (goto-char c-new-END)
> - (if (equal (c-get-char-property (1- (point)) 'syntax-table) '(15))
> - (if (memq (char-before) '(?\n ?\r))
> + (setq c-new-END (max c-new-END (min (1+ (point)) (point-max))))
> + (if (equal (c-get-char-property (point) 'syntax-table) '(15))
> + (if (memq (char-after) '(?\n ?\r))
> ;; Normally terminated invalid string.
> - (progn
> + (let ((eoll-1 (point)))
> + (forward-char)
> (backward-sexp)
> - (c-clear-char-property (1- c-new-END) 'syntax-table)
> + (c-clear-char-property eoll-1 'syntax-table)
> (c-clear-char-property (point) 'syntax-table))
> ;; Opening " at EOB.
> (c-clear-char-property (1- (point)) 'syntax-table))
> @@ -1238,7 +1238,7 @@
> ;; Opening " on last line of text (without EOL).
> (c-clear-char-property (point) 'syntax-table))))
>
> - (t (goto-char c-new-END)
> + (t (goto-char end) ; point-max
> (if (c-search-backward-char-property 'syntax-table '(15) c-new-BEG)
> (c-clear-char-property (point) 'syntax-table))))
>
> @@ -1327,9 +1327,9 @@
> (while (progn
> (setq s (parse-partial-sexp (point) c-new-END nil
> nil s 'syntax-table))
> - (and (not (nth 3 s))
> - (< (point) c-new-END)
> - (not (memq (char-before) c-string-delims)))))
> + (and (< (point) c-new-END)
> + (or (not (nth 3 s))
> + (not (memq (char-before) c-string-delims))))))
> ;; We're at the start of a string.
> (memq (char-before) c-string-delims)))
> (if (c-unescaped-nls-in-string-p (1- (point)))
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:
bug#33163; Package
emacs,cc-mode.
(Mon, 29 Oct 2018 18:48:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 33163 <at> debbugs.gnu.org (full text, mbox):
Thank you, so, I've used the patch today for working with a code, and
everything seemed to be well :)
Tested-by: Konstantin Kharlamov <hi-angel <at> yandex.ru>
On 10/28/18 2:21 PM, Konstantin Kharlamov wrote:
> On 10/28/18 1:49 PM, Alan Mackenzie wrote:
>> In article <mailman.2795.1540562775.1284.bug-gnu-emacs <at> gnu.org> you
>> wrote:
>>> This long-standing problem appears occasionally, and only disappears if
>>> you kill the buffer completely, then reopen the file. I never got to
>>> report it because I never could find steps to reproduce it… until now
>>> :) Nvm the non-sense code, I reduced testcase as far as I managed.
>>
>>> # Steps to reproduce:
>>
>>> 1. Save the following text in `test.cpp`
>>> int main() {
>>> puts(It's");
>>> auto foo = []()-> void { };
>>> puts("It's");
>>> }
>>> 2. Open `emacs -Q ./test.cpp`
>>> 3. Now, the text lacks a quote in the first `puts(It's");`. Add it so
>>> it looks like `puts("It's");`. Essentially, if you'd compile it with
>>> g++, it lacks any syntax error besides `puts` being undeclared.
>>
>>> # Expected
>>
>>> The line with `auto foo…` is not red.
>>
>>> # Actual
>>
>>> The line with `auto foo…` (in particular) becomes red.
>>
>> Thanks for taking the trouble to report this bug. Thanks even more for
>> condensing it down to a minimal test case.
>>
>> The following patch should fix it. Would you please apply the patch,
>> recompile .../lisp/progmodes/cc-mode.el, load the new file in to your
>> Emacs (or restart Emacs), then try it out on your real C++ code. Then
>> please let me know whether it's working or not, and if not, how it's
>> going wrong. Thanks!
>
> Thank you for the quick patch! I tried to do some editing and
> navigating, and all seems well. More real testing I can only do on
> Monday, so I guess I'll reply somewhere on Monday evening.
>
>>
>>> # Additional information
>>
>>> Emacs version GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
>>> Version 3.22.30) of 2018-10-01, build with -flto.
>>
>>
>>
>> diff -r 2f7029fa229d cc-mode.el
>> --- a/cc-mode.el Sun Oct 14 20:01:07 2018 +0000
>> +++ b/cc-mode.el Sun Oct 28 10:20:38 2018 +0000
>> @@ -1216,21 +1216,21 @@
>> (if (eq beg-literal-type 'string)
>> (setq c-new-BEG (min (car beg-limits) c-new-BEG))))
>> - ((< c-new-END (point-max))
>> - (goto-char (1+ c-new-END)) ; might be a newline.
>> + ((< end (point-max))
>> + (goto-char (1+ end)) ; might be a newline.
>> ;; In the following regexp, the initial \n caters for a
>> newline getting
>> ;; joined to a preceding \ by the removal of what comes between.
>> (re-search-forward
>> "[\n\r]?\\(\\\\\\(.\\|\n\\|\r\\)\\|[^\\\n\r]\\)*"
>> nil t)
>> ;; We're at an EOLL or point-max.
>> - (setq c-new-END (min (1+ (point)) (point-max)))
>> - (goto-char c-new-END)
>> - (if (equal (c-get-char-property (1- (point)) 'syntax-table) '(15))
>> - (if (memq (char-before) '(?\n ?\r))
>> + (setq c-new-END (max c-new-END (min (1+ (point)) (point-max))))
>> + (if (equal (c-get-char-property (point) 'syntax-table) '(15))
>> + (if (memq (char-after) '(?\n ?\r))
>> ;; Normally terminated invalid string.
>> - (progn
>> + (let ((eoll-1 (point)))
>> + (forward-char)
>> (backward-sexp)
>> - (c-clear-char-property (1- c-new-END) 'syntax-table)
>> + (c-clear-char-property eoll-1 'syntax-table)
>> (c-clear-char-property (point) 'syntax-table))
>> ;; Opening " at EOB.
>> (c-clear-char-property (1- (point)) 'syntax-table))
>> @@ -1238,7 +1238,7 @@
>> ;; Opening " on last line of text (without EOL).
>> (c-clear-char-property (point) 'syntax-table))))
>> - (t (goto-char c-new-END)
>> + (t (goto-char end) ; point-max
>> (if (c-search-backward-char-property 'syntax-table '(15) c-new-BEG)
>> (c-clear-char-property (point) 'syntax-table))))
>> @@ -1327,9 +1327,9 @@
>> (while (progn
>> (setq s (parse-partial-sexp (point) c-new-END nil
>> nil s 'syntax-table))
>> - (and (not (nth 3 s))
>> - (< (point) c-new-END)
>> - (not (memq (char-before) c-string-delims)))))
>> + (and (< (point) c-new-END)
>> + (or (not (nth 3 s))
>> + (not (memq (char-before)
>> c-string-delims))))))
>> ;; We're at the start of a string.
>> (memq (char-before) c-string-delims)))
>> (if (c-unescaped-nls-in-string-p (1- (point)))
>>
>>
Reply sent
to
Alan Mackenzie <acm <at> muc.de>:
You have taken responsibility.
(Tue, 30 Oct 2018 12:02:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Konstantin Kharlamov <hi-angel <at> yandex.ru>:
bug acknowledged by developer.
(Tue, 30 Oct 2018 12:02:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 33163-done <at> debbugs.gnu.org (full text, mbox):
Hello, Konstantin
On Mon, Oct 29, 2018 at 21:46:50 +0300, Konstantin Kharlamov wrote:
> Thank you, so, I've used the patch today for working with a code, and
> everything seemed to be well :)
> Tested-by: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Thanks for the testing. I've committed the patch to all the usual
places, and I'm closing the bug.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:
bug#33163; Package
emacs,cc-mode.
(Mon, 26 Nov 2018 10:57:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 33163-done <at> debbugs.gnu.org (full text, mbox):
FTR: since then I've encountered a likewise problem a few times more,
except now it only happens with lines `#include "file.h"`. I haven't
manage yet to get a minimal reproducible example, but I thought it's
worth mentioning here, just in case you might have an offhand insight.
On 30.10.2018 15:01, Alan Mackenzie wrote:
> Hello, Konstantin
>
> On Mon, Oct 29, 2018 at 21:46:50 +0300, Konstantin Kharlamov wrote:
>> Thank you, so, I've used the patch today for working with a code, and
>> everything seemed to be well :)
>
>> Tested-by: Konstantin Kharlamov <hi-angel <at> yandex.ru>
>
> Thanks for the testing. I've committed the patch to all the usual
> places, and I'm closing the bug.
>
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 24 Dec 2018 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 173 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.