c-indent-line-or-region with 500 char

c-indent-line-or-region with 500 char

[Yasushi SHOJI]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

Hello,

I just found this odd behavior on my Emacs and I'd like to ask how to
fix it.  I'm attaching a.c with 500 chars in. Go to the very bottom of
the file and hitting the tab will move the cursors to the right. hitting the
tab key again moves it again. It just keeps going.

If you delete some char from the file, it stop behaving.

I can reproduce this with the following Emacs with `-q`.

 - Debian Sid's Emacs 1:25.2+1-11
 - The current tip of emacs-26 branch (ea624626)

Does anyone see the behavior?

Thanks,
-- 
           yashi

[-- Attachment #2: a.c.gz --]
[-- Type: application/gzip, Size: 102 bytes --]

Re: c-indent-line-or-region with 500 char

[Alan Mackenzie]

Hello, Yashi.

On Mon, Nov 26, 2018 at 22:19:15 +0900, Yasushi SHOJI wrote:
> Hello,

> I just found this odd behavior on my Emacs and I'd like to ask how to
> fix it.  I'm attaching a.c with 500 chars in. Go to the very bottom of
> the file and hitting the tab will move the cursors to the right. hitting the
> tab key again moves it again. It just keeps going.

> If you delete some char from the file, it stop behaving.

> I can reproduce this with the following Emacs with `-q`.

>  - Debian Sid's Emacs 1:25.2+1-11
>  - The current tip of emacs-26 branch (ea624626)

> Does anyone see the behavior?

Yes, this was one of these bugs which was fairly easy to diagnose, but
difficult to decide how to fix.  Thanks for taking the trouble to report
this.

Your file is actually 502 bytes long.  At some place in CC Mode, there
was a call to (c-beginning-of-statement-1 ...) with a search limit of
500 bytes.  This just failed to reach the # of the #define at the
beginning of the buffer, hence mis-analysed the text, leading to the
strange behaviour.

When a random byte is removed, this 500 limit was just big enough to
reach that # at the beginning of the buffer, hence analysed it
correctly, and the <tab> key worked properly.

The fix in the patch below amends c-beginning-of-statement-1 to detect
hitting the limit.  It should apply cleanly to the emacs-26 branch.

Could you please try out this patch (to
emacs/lisp/progmodes/cc-engine.el), byte compile cc-engine.el, try it
out on your real code, and confirm to me that it fixes the bug, or tell
me what's still not working.  If you want any help applying the patch or
byte compiling the file, feel free to send me private email.

Thanks again for the report!



diff -r 021672422937 cc-engine.el
--- a/cc-engine.el	Sat Nov 24 10:18:12 2018 +0000
+++ b/cc-engine.el	Sat Dec 08 13:41:22 2018 +0000
@@ -698,7 +698,7 @@
 				    (c-point 'bol (elt saved-pos 0))))))))
 
 (defun c-beginning-of-statement-1 (&optional lim ignore-labels
-					     noerror comma-delim)
+					     noerror comma-delim hit-lim)
   "Move to the start of the current statement or declaration, or to
 the previous one if already at the beginning of one.  Only
 statements/declarations on the same level are considered, i.e. don't
@@ -1271,6 +1272,17 @@
 		;; Might have jumped over several labels.  Go to the last one.
 		(setq pos last-label-pos)))))
 
+      ;; Have we hit LIM without finding a beginning of statement?
+      (when (and hit-lim
+		 (bobp)
+		 (>= pos start))
+	(unless
+	    (and (eq (point) 1)
+		 (not (looking-at c-comment-start-regexp))
+		 (not (and c-anchored-cpp-prefix
+			   (looking-at c-anchored-cpp-prefix))))
+	  (setq ret nil)))
+
       ;; Have we got "case <expression>:"?
       (goto-char pos)
       (when (and after-case:-pos
@@ -9656,7 +9668,7 @@
 
   (let ((beg (point)) id-start)
     (and
-     (eq (c-beginning-of-statement-1 lim) 'same)
+     (eq (c-beginning-of-statement-1 lim nil nil nil t) 'same)
 
      (not (and (c-major-mode-is 'objc-mode)
 	       (c-forward-objc-directive)))


> Thanks,
> -- 
>            yashi

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: c-indent-line-or-region with 500 char

[Alan Mackenzie]

Hello, Yashi.

Unfortunately, the patch I suggested in my last post was faulty.

I've now committed a better patch to Emacs master, which should have
fixed the problem.

All the best!

-- 
Alan Mackenzie (Nuremberg, Germany).


On Sat, Dec 08, 2018 at 13:53:51 +0000, Alan Mackenzie wrote:
> Hello, Yashi.

> On Mon, Nov 26, 2018 at 22:19:15 +0900, Yasushi SHOJI wrote:
> > Hello,

> > I just found this odd behavior on my Emacs and I'd like to ask how to
> > fix it.  I'm attaching a.c with 500 chars in. Go to the very bottom of
> > the file and hitting the tab will move the cursors to the right. hitting the
> > tab key again moves it again. It just keeps going.

> > If you delete some char from the file, it stop behaving.

> > I can reproduce this with the following Emacs with `-q`.

> >  - Debian Sid's Emacs 1:25.2+1-11
> >  - The current tip of emacs-26 branch (ea624626)

> > Does anyone see the behavior?

> Yes, this was one of these bugs which was fairly easy to diagnose, but
> difficult to decide how to fix.  Thanks for taking the trouble to report
> this.

> Your file is actually 502 bytes long.  At some place in CC Mode, there
> was a call to (c-beginning-of-statement-1 ...) with a search limit of
> 500 bytes.  This just failed to reach the # of the #define at the
> beginning of the buffer, hence mis-analysed the text, leading to the
> strange behaviour.

> When a random byte is removed, this 500 limit was just big enough to
> reach that # at the beginning of the buffer, hence analysed it
> correctly, and the <tab> key worked properly.

> The fix in the patch below amends c-beginning-of-statement-1 to detect
> hitting the limit.  It should apply cleanly to the emacs-26 branch.

> Could you please try out this patch (to
> emacs/lisp/progmodes/cc-engine.el), byte compile cc-engine.el, try it
> out on your real code, and confirm to me that it fixes the bug, or tell
> me what's still not working.  If you want any help applying the patch or
> byte compiling the file, feel free to send me private email.

> Thanks again for the report!

[ .... ]