unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#28598: 25.3; Errors in narrowed buffers in CC-mode
@ 2017-09-25  6:21 George Plymale II
  2017-09-25 17:51 ` John Wiegley
  0 siblings, 1 reply; 7+ messages in thread
From: George Plymale II @ 2017-09-25  6:21 UTC (permalink / raw)
  To: 28598

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#28598: 25.3; Errors in narrowed buffers in CC-mode
  2017-09-25  6:21 bug#28598: 25.3; Errors in narrowed buffers in CC-mode George Plymale II
@ 2017-09-25 17:51 ` John Wiegley
  2017-09-25 20:50   ` Alan Mackenzie
  2017-10-01 18:55   ` Alan Mackenzie
  0 siblings, 2 replies; 7+ messages in thread
From: John Wiegley @ 2017-09-25 17:51 UTC (permalink / raw)
  To: George Plymale II; +Cc: Alan Mackenzie, 28598

>>>>> "GP" == George Plymale <georgedp@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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#28598: 25.3; Errors in narrowed buffers in CC-mode
  2017-09-25 17:51 ` John Wiegley
@ 2017-09-25 20:50   ` Alan Mackenzie
  2017-09-26  1:14     ` George Plymale II
  2017-10-01 18:55   ` Alan Mackenzie
  1 sibling, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2017-09-25 20:50 UTC (permalink / raw)
  To: John Wiegley, George Plymale II; +Cc: 28598

Hello, John and George.

On Mon, Sep 25, 2017 at 10:51:00 -0700, John Wiegley wrote:
> >>>>> "GP" == George Plymale <georgedp@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).





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#28598: 25.3; Errors in narrowed buffers in CC-mode
  2017-09-25 20:50   ` Alan Mackenzie
@ 2017-09-26  1:14     ` George Plymale II
  0 siblings, 0 replies; 7+ messages in thread
From: George Plymale II @ 2017-09-26  1:14 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: jwiegley, 28598

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#28598: 25.3; Errors in narrowed buffers in CC-mode
  2017-09-25 17:51 ` John Wiegley
  2017-09-25 20:50   ` Alan Mackenzie
@ 2017-10-01 18:55   ` Alan Mackenzie
  2017-10-02 19:02     ` George Plymale II
  1 sibling, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2017-10-01 18:55 UTC (permalink / raw)
  To: George Plymale II, John Wiegley; +Cc: 28598

Hello, George and John.

On Mon, Sep 25, 2017 at 10:51:00 -0700, John Wiegley wrote:
> >>>>> "GP" == George Plymale <georgedp@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).





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#28598: 25.3; Errors in narrowed buffers in CC-mode
  2017-10-01 18:55   ` Alan Mackenzie
@ 2017-10-02 19:02     ` George Plymale II
  2017-10-30 17:37       ` Alan Mackenzie
  0 siblings, 1 reply; 7+ messages in thread
From: George Plymale II @ 2017-10-02 19:02 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: jwiegley, 28598

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#28598: 25.3; Errors in narrowed buffers in CC-mode
  2017-10-02 19:02     ` George Plymale II
@ 2017-10-30 17:37       ` Alan Mackenzie
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Mackenzie @ 2017-10-30 17:37 UTC (permalink / raw)
  To: George Plymale II; +Cc: jwiegley, 28598-done

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2017-10-30 17:37 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-25  6:21 bug#28598: 25.3; Errors in narrowed buffers in CC-mode George Plymale II
2017-09-25 17:51 ` John Wiegley
2017-09-25 20:50   ` Alan Mackenzie
2017-09-26  1:14     ` George Plymale II
2017-10-01 18:55   ` Alan Mackenzie
2017-10-02 19:02     ` George Plymale II
2017-10-30 17:37       ` Alan Mackenzie

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).