GNU bug report logs - #45375
cc-mode indentation sometimes doesn't work

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Alan Mackenzie <acm <at> muc.de>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#46400: closed (Sporadically breaking newline-indentation in
 c-mode)
Date: Tue, 23 Feb 2021 11:33:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 23 Feb 2021 11:32:00 +0000
with message-id <YDTnsKwfsU0KFNkO <at> ACM>
and subject line Re: bug#46400: bug#45375: cc-mode indentation sometimes doesn't work
has caused the debbugs.gnu.org bug report #45375,
regarding Sporadically breaking newline-indentation in c-mode
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
45375: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45375
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: Sporadically breaking newline-indentation in c-mode
Date: Tue, 09 Feb 2021 15:45:42 +0300

This is a regression, but I'm not sure when it was introduced. Upon pressing
RET, sometimes indentation gets inserted and you get the caret is on top of
indentation; other times no indentation is inserted and the caret ends up at the
beginning of a new line.

There is not pattern, and both cases may happen many times in the row upon
pressing RET.

It is worth noting that this only happens in certain syntax parts of c-code.

To reproduce the problem you basically put the caret at certain location in
text, and spam RET and undo till some "RET" results in no indentation inserted
(indentation seems expected by default, so it's not expected bahavior).

# Steps to reproduce

1. Create /tmp/.emacs file with the following content:

    (defun test ()
      (let ((i 0)
            (searching t))
        (while (and (< i 10) searching)
          (setq i (+ i 1))
          (call-interactively 'newline)
          (if (eq (line-beginning-position) (point))
              (setq searching nil)
            (call-interactively 'undo))
          )
        (format "exiting with i = %d" i)))

2. Create `test.c` file with the following content:

    void foo() {
        if (-1 == dest)
        {
            bar("Couldn't open %s", to);
            goto exit;
        }
    }

3. Run emacs as `env HOME=/tmp/ emacs test.c`
4. Put caret at the end of `bar("Couldn't open %s", to);` text, right after the
semicolon
5. Evaluate (test)

NOTE: to make this work I had to evaluate the 5-th step twice. The reason is
that `undo` in here behaves oddly: often it just refuses to undo with "No
further undo unformation", thus making function evaluation stop. I'm not sure
what to do about that problem; however repeating the call second time seems to
always reproduce the problem for me.

## Expected

Whenever `(test)` completes, the text is unchanged.

## Actual

At some point you end up with caret being at the beginning of a new line (i.e.
no indentation on that line)

# Version

Latest Emacs build:

    GNU Emacs 28.0.50 (build 12, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.17.4) of 2021-02-09

Also tested on a build from a few weeks ago, commit 9503f8d96c

[Message part 3 (message/rfc822, inline)]

From: Alan Mackenzie <acm <at> muc.de>
To: Herman <at> debbugs.gnu.org, Géza <geza.herman <at> gmail.com>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 45375-done <at> debbugs.gnu.org,
 46400-done <at> debbugs.gnu.org
Subject: Re: bug#46400: bug#45375: cc-mode indentation sometimes doesn't work
Date: Tue, 23 Feb 2021 11:32:00 +0000

Hello, Géza.

On Sun, Feb 14, 2021 at 11:11:28 +0000, Alan Mackenzie wrote:
> On Sat, Feb 13, 2021 at 19:43:31 +0100, Herman, Géza wrote:

[ .... ]

> In bug #46400, I think Konstantin's bisecting threw up the wrong commit,
> since cache bugs tend to be very slippery to pin down.

> > Thank you for looking at this!

> A pleasure!  I intend to commit the patch below in a few days time, if I
> don't hear back from anybody that it's giving trouble.  This patch fixes
> the bug when applied to that commit from December
> (9022df70270243f211c54ccd66800320148b8434).  It should apply cleanly to
> master.

I have now applied the patch to all the relevant places, and I am
closing the bugs with this post.

[ .... ]

> > Geza

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