GNU bug report logs -
#45375
cc-mode indentation sometimes doesn't work
Previous Next
Full log
View this message in rfc822 format
[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 cc-mode indentation sometimes doesn't work
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)]
On current master (6af31fd71ff1a403c199c479577bcc145a547db1) indentation
of C/C++ files sometimes doesn't work. I've bisected it: commit
"9022df7027 Optimise c-parse-state for large buffers with few (if any)
braces." introduced this behavior.
This is how to reproduce: check out
9022df70270243f211c54ccd66800320148b8434, and execute "emacs -Q
xdisp.c". Jump to line 2989 with M-g M-g 2989, move the cursor to the
end of line of "Lisp_Object retval;", and press enter. The cursor will
be moved to the correct place (correctly indented, cursor will be placed
below the 'L' character of the previous line). Then push enter at end of
line of "va_list ap;". For me, cursor will jump to the beginning of the
line, it won't be indented. If I keep pressing enters, the next failure
will be at "va_end (ap);". I'm not sure whether this exact steps
reproduces for everyone, but it happened me 5 of 5 trials. If I don't
press enter at the first line ("Lisp_Object retval;"), the problem
doesn't happen for any of this function lines. But it will happen for
somewhere else, if I keep trying (move around the file, press enter at
random places: if will fail sooner or later).
For my configuration (without -Q), this problem happens quite frequently
during editing C++ code.
[Message part 3 (message/rfc822, inline)]
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).
This bug report was last modified 4 years and 88 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.