GNU bug report logs - #28598
25.3; Errors in narrowed buffers in CC-mode

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 28598 in the body.
You can then email your comments to 28598 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: George Plymale II <georgie <at> southernohio.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.3; Errors in narrowed buffers in CC-mode
Date: Mon, 25 Sep 2017 02:21:25 -0400

The inception of this bug report can be found at:
https://github.com/josteink/csharp-mode/issues/119

For those too lazy to follow the link, here's the gist: When I press
`RET' at the beginning or end of a narrowed buffer in CC-mode, I see
errors like this:

c-determine-limit: Args out of range: #<buffer dired.c>, 1, 1564

A full backtrace yields something like this:

Debugger entered--Lisp error: (args-out-of-range #<buffer dired.c> 1 1564)
  parse-partial-sexp(1 1564)
  c-determine-limit(500)
  c-guess-basic-syntax()
  c-indent-line()
  indent-according-to-mode()
  electric-indent-post-self-insert-function()
  self-insert-command(1)
  newline(nil 1)
  funcall-interactively(newline nil 1)
  call-interactively(newline nil nil)
  command-execute(newline)
  
As you can see from the filename there, the file I was testing this with
was dired.c from the very Emacs source tree (although I have now tested
with various header files, other C files, and of course, C# files).

I initially tested this on a macOS system, but now I have also tested
this on Ubuntu and I see the same issue occurring on both systems (which
are both using Emacs 25.3).

I also noticed that this issue does not occur in Emacs 24.

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

From: John Wiegley <jwiegley <at> gmail.com>
To: George Plymale II <georgedp <at> orbitalimpact.com>
Cc: Alan Mackenzie <acm <at> muc.de>, 28598 <at> debbugs.gnu.org
Subject: Re: bug#28598: 25.3; Errors in narrowed buffers in CC-mode
Date: Mon, 25 Sep 2017 10:51:00 -0700

>>>>> "GP" == George Plymale <georgedp <at> orbitalimpact.com> writes:

GP> For those too lazy to follow the link, here's the gist: When I press `RET'
GP> at the beginning or end of a narrowed buffer in CC-mode, I see errors like
GP> this:

GP> c-determine-limit: Args out of range: #<buffer dired.c>, 1, 1564

Alan, do you have any thoughts on this one?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Alan Mackenzie <acm <at> muc.de>
To: John Wiegley <jwiegley <at> gmail.com>,
 George Plymale II <georgedp <at> orbitalimpact.com>
Cc: 28598 <at> debbugs.gnu.org
Subject: Re: bug#28598: 25.3; Errors in narrowed buffers in CC-mode
Date: Mon, 25 Sep 2017 20:50:57 +0000

Hello, John and George.

On Mon, Sep 25, 2017 at 10:51:00 -0700, John Wiegley wrote:
> >>>>> "GP" == George Plymale <georgedp <at> orbitalimpact.com> writes:

> GP> For those too lazy to follow the link, here's the gist: When I press `RET'
> GP> at the beginning or end of a narrowed buffer in CC-mode, I see errors like
> GP> this:

> GP> c-determine-limit: Args out of range: #<buffer dired.c>, 1, 1564

> Alan, do you have any thoughts on this one?

Thanks for the heads up, John.

With the help of George's backtrace, I can see exactly what's happening,
where, and why.

The fixing of the bug will involve carefully defining conditions which
must hold when a function (c-determine-limit) is called, and amending it
on the assumption those conditions hold.

Give me a day or two, it's a bit late at the moment here in Germany.

> -- 
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: George Plymale II <georgie <at> southernohio.net>
To: Alan Mackenzie <acm <at> muc.de>
Cc: jwiegley <at> gmail.com, 28598 <at> debbugs.gnu.org
Subject: Re: bug#28598: 25.3; Errors in narrowed buffers in CC-mode
Date: Mon, 25 Sep 2017 21:14:29 -0400

Thanks a lot for tackling this issue, Alan! Let me know if you need any
more info.

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

From: Alan Mackenzie <acm <at> muc.de>
To: George Plymale II <georgedp <at> orbitalimpact.com>,
 John Wiegley <jwiegley <at> gmail.com>
Cc: 28598 <at> debbugs.gnu.org
Subject: Re: bug#28598: 25.3; Errors in narrowed buffers in CC-mode
Date: Sun, 1 Oct 2017 18:55:49 +0000

Hello, George and John.

On Mon, Sep 25, 2017 at 10:51:00 -0700, John Wiegley wrote:
> >>>>> "GP" == George Plymale <georgedp <at> orbitalimpact.com> writes:

> GP> For those too lazy to follow the link, here's the gist: When I press `RET'
> GP> at the beginning or end of a narrowed buffer in CC-mode, I see errors like
> GP> this:

> GP> c-determine-limit: Args out of range: #<buffer dired.c>, 1, 1564

> Alan, do you have any thoughts on this one?

George, would you try the following patch, please?  The file
cc-engine.el is in ..../emacs-25.3/lisp/progmodes.  After applying the
patch, it is sufficient merely to recompile cc-engine.el.  If you want
any help with the patching/recompiling process, feel free to send me
private email.

The bug which you tripped over is already (almost) fixed in the emacs-26
branch of the git repository.  It is expected to be released some months
from now.

In the meantime, this patch should solve the problems in Emacs 25.3.
Please let me know if it doesn't.



--- cc-engine.20171001.eeel	2017-04-14 15:02:47.000000000 +0000
+++ cc-engine.el	2017-10-01 17:14:49.185254672 +0000
@@ -4682,18 +4682,29 @@
   ;; This doesn't preserve point.
   (let* ((pos (max (- start try-size) (point-min)))
 	 (base (c-state-semi-safe-place pos))
-	 (s (parse-partial-sexp base pos)))
-    (if (or (nth 4 s) (nth 3 s))	; comment or string
-	(nth 8 s)
+	 (s (save-restriction
+	      (widen)
+	      (parse-partial-sexp base pos)))
+	 (cand (if (or (nth 4 s) (nth 3 s)) ; comment or string
+		   (nth 8 s)
+		 pos)))
+    (if (>= cand (point-min))
+	cand
+      (parse-partial-sexp pos start nil nil s 'syntax-table)
       (point))))
 
 (defun c-determine-limit (how-far-back &optional start try-size)
-  ;; Return a buffer position HOW-FAR-BACK non-literal characters from START
-  ;; (default point).  This is done by going back further in the buffer then
-  ;; searching forward for literals.  The position found won't be in a
-  ;; literal.  We start searching for the sought position TRY-SIZE (default
-  ;; twice HOW-FAR-BACK) bytes back from START.  This function must be fast.
-  ;; :-)
+  ;; Return a buffer position HOW-FAR-BACK non-literal characters from
+  ;; START (default point).  The starting position, either point or
+  ;; START may not be in a comment or string.
+  ;;
+  ;; The position found will not be before POINT-MIN and won't be in a
+  ;; literal.
+  ;;
+  ;; We start searching for the sought position TRY-SIZE (default
+  ;; twice HOW-FAR-BACK) bytes back from START.
+  ;;
+  ;; This function must be fast.  :-)
   (save-excursion
     (let* ((start (or start (point)))
 	   (try-size (or try-size (* 2 how-far-back)))
@@ -4715,7 +4726,8 @@
 		 'syntax-table))	; stop-comment
 
 	;; Gather details of the non-literal-bit - starting pos and size.
-	(setq size (- (if (or (nth 4 s) (nth 3 s))
+	(setq size (- (if (or (and (nth 4 s) (not (eq (nth 7 s) 'syntax-table)))
+			      (nth 3 s))
 			  (nth 8 s)
 			(point))
 		      pos))
@@ -4723,7 +4735,8 @@
 	    (setq stack (cons (cons pos size) stack)))
 
 	;; Move forward to the end of the comment/string.
-	(if (or (nth 4 s) (nth 3 s))
+	(if (or (and (nth 4 s) (not (eq (nth 7 s) 'syntax-table)))
+		(nth 3 s))
 	    (setq s (parse-partial-sexp
 		     (point)
 		     start
@@ -4747,6 +4760,8 @@
 	(+ (car elt) (- count how-far-back)))
        ((eq base (point-min))
 	(point-min))
+       ((> base (- start try-size)) ; Can only happen if we hit point-min.
+	(car elt))
        (t
 	(c-determine-limit (- how-far-back count) base try-size))))))
 

> -- 
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: George Plymale II <georgie <at> southernohio.net>
To: Alan Mackenzie <acm <at> muc.de>
Cc: jwiegley <at> gmail.com, 28598 <at> debbugs.gnu.org
Subject: Re: bug#28598: 25.3; Errors in narrowed buffers in CC-mode
Date: Mon, 02 Oct 2017 15:02:36 -0400

Hi, Alan.

Thanks for making this patch. After applying it to my Emacs source tree
and recompiling Emacs, the issue seems to be gone as far as I can
tell. I have also tested the patched version with C# files (as well as C
files, obviously) and everything seems okay.

Hopefully Emacs 26 will come out soon and fix this issue, among many
others that I'm excited to see fixed.

Thanks.

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

From: Alan Mackenzie <acm <at> muc.de>
To: George Plymale II <georgie <at> southernohio.net>
Cc: jwiegley <at> gmail.com, 28598-done <at> debbugs.gnu.org
Subject: Re: bug#28598: 25.3; Errors in narrowed buffers in CC-mode
Date: Mon, 30 Oct 2017 17:37:55 +0000

Hello, George.

On Mon, Oct 02, 2017 at 15:02:36 -0400, George Plymale II wrote:
> Hi, Alan.

> Thanks for making this patch. After applying it to my Emacs source tree
> and recompiling Emacs, the issue seems to be gone as far as I can
> tell. I have also tested the patched version with C# files (as well as C
> files, obviously) and everything seems okay.

> Hopefully Emacs 26 will come out soon and fix this issue, among many
> others that I'm excited to see fixed.

I've committed the fix to Emacs's emacs-26 branch, and I'm closing the
bug.

> Thanks.

Thank you, too!

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