GNU bug report logs - #46400
Sporadically breaking newline-indentation in c-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 46400 in the body.
You can then email your comments to 46400 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: 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 #8 received at 46400 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: 46400 <at> debbugs.gnu.org
Cc: acm <at> muc.de
Subject: [BISECTED] Sporadically breaking newline-indentation in c-mode
Date: Wed, 10 Feb 2021 01:13:49 +0300

I just bisected it to a commit 

    3096437593 CC Mode: introduce a new cache for brace structures.  This fixes bug #45248

before this commit I couldn't reproduce it, and on this I reproduce it immediately.

CCing the commit author.

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

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: 46400 <at> debbugs.gnu.org
Cc: acm <at> muc.de
Subject: Re: [BISECTED] Sporadically breaking newline-indentation in c-mode
Date: Fri, 12 Feb 2021 17:08:19 +0300

On Wed, 2021-02-10 at 01:13 +0300, Konstantin Kharlamov wrote:
> I just bisected it to a commit 
> 
>     3096437593 CC Mode: introduce a new cache for brace structures.  This
> fixes bug #45248
> 
> before this commit I couldn't reproduce it, and on this I reproduce it
> immediately.
> 
> CCing the commit author.

So, what's the plan here? Should I send a revert?

CC: Alan Mackenzie (I know I already CCed, but I figured they might not know they were mentioned if they has mail filters for example, since I didn't write the name).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: acm <at> muc.de, 46400 <at> debbugs.gnu.org
Subject: Re: [BISECTED] Sporadically breaking newline-indentation in c-mode
Date: Fri, 12 Feb 2021 14:56:41 +0000

Hello, Konstantin.

First of all, thanks for taking the trouble to report this bug, and
thanks even more for taking the diagnosis so far.

On Fri, Feb 12, 2021 at 17:08:19 +0300, Konstantin Kharlamov wrote:
> On Wed, 2021-02-10 at 01:13 +0300, Konstantin Kharlamov wrote:
> > I just bisected it to a commit 

> >     3096437593 CC Mode: introduce a new cache for brace structures.  This
> > fixes bug #45248

> > before this commit I couldn't reproduce it, and on this I reproduce it
> > immediately.

> > CCing the commit author.

> So, what's the plan here? Should I send a revert?

No, please don't do that - that was an essential fix for a performance
bug.

> CC: Alan Mackenzie (I know I already CCed, but I figured they might
> not know they were mentioned if they has mail filters for example,
> since I didn't write the name).

Sorry, I should have got back to you sooner, but I wanted to have
something to show.

I don't think the bug was introduced by the commit you cite, more likely
that commit triggered the bug which was lying in wait elsewhere.

I've been working on this bug for several hours, so far, and have found
that the "c-state-cache" (which records the positions of certain braces,
brackets and parentheses) becomes corrupt while running your `test'
function.  I'm trying to track down where and how this corruption
happens.

Also relevant is that the bug seems to be being triggered by the
apostrophe in

    bar("Couldn't open %s", to);
               ^

..  At least, if I take that apostrophe away, I don't see the bug
symptoms any more.

So, please bear with me some while longer.  I am working on the bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 46400 <at> debbugs.gnu.org
Subject: Re: [BISECTED] Sporadically breaking newline-indentation in c-mode
Date: Fri, 12 Feb 2021 18:46:41 +0300

On Fri, 2021-02-12 at 14:56 +0000, Alan Mackenzie wrote:
> Hello, Konstantin.
> 
> First of all, thanks for taking the trouble to report this bug, and
> thanks even more for taking the diagnosis so far.
> 
> On Fri, Feb 12, 2021 at 17:08:19 +0300, Konstantin Kharlamov wrote:
> > On Wed, 2021-02-10 at 01:13 +0300, Konstantin Kharlamov wrote:
> > > I just bisected it to a commit 
> 
> > >     3096437593 CC Mode: introduce a new cache for brace structures.  This
> > > fixes bug #45248
> 
> > > before this commit I couldn't reproduce it, and on this I reproduce it
> > > immediately.
> 
> > > CCing the commit author.
> 
> > So, what's the plan here? Should I send a revert?
> 
> No, please don't do that - that was an essential fix for a performance
> bug.
> 
> > CC: Alan Mackenzie (I know I already CCed, but I figured they might
> > not know they were mentioned if they has mail filters for example,
> > since I didn't write the name).
> 
> Sorry, I should have got back to you sooner, but I wanted to have
> something to show.
> 
> I don't think the bug was introduced by the commit you cite, more likely
> that commit triggered the bug which was lying in wait elsewhere.
> 
> I've been working on this bug for several hours, so far, and have found
> that the "c-state-cache" (which records the positions of certain braces,
> brackets and parentheses) becomes corrupt while running your `test'
> function.  I'm trying to track down where and how this corruption
> happens.
> 
> Also relevant is that the bug seems to be being triggered by the
> apostrophe in
> 
>     bar("Couldn't open %s", to);
>                ^
> 
> ..  At least, if I take that apostrophe away, I don't see the bug
> symptoms any more.
> 
> So, please bear with me some while longer.  I am working on the bug.
> 

D: Oh, this is cool! Sure, thank you very much for looking into it! I'm definitely not in hurry, I was just kinda being afraid that the report could've gotten through the cracks. I'm happy to hear that wasn't the case ☺

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

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

Hello, Basil, Géza and Konstantin.

Sorry I missed this bug report in December, and thanks, Basil, for
drawing it to my attention.

On Fri, Feb 12, 2021 at 21:17:56 +0000, Basil L. Contovounesios wrote:
> reassign 45375 emacs,cc-mode
> quit

> [CCed CC Mode maintainer.]

> Herman <at> debbugs.gnu.org, Géza <geza.herman <at> gmail.com> writes:

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

> I tried following your recipe (the lines in xdisp.c have since moved
> around a bit), but was unable to reproduce the issue.

> Can you still reproduce it on your end?

I can reproduce it easily on the indicated commit, and I have found
where the problem is.  It's in the handling of the c-state-cache (the
cache which tracks the positions of certain
braces/brackets/parentheses).  Fixing it could be quite tricky,
particularly given the need to retain optimisation for the case that the
above commit "fixed".

I am fairly, but not absolutely, sure that this is the same bug as
46400, but the bug scenario here is easier to reproduce than the other
one, so I will concentrate on this bug first.  Maybe we can join the bug
reports later.

> Thanks,

> -- 
> Basil

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Herman, Géza <geza.herman <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>, "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 46400 <at> debbugs.gnu.org, 45375 <at> debbugs.gnu.org
Subject: Re: bug#45375: cc-mode indentation sometimes doesn't work
Date: Sat, 13 Feb 2021 19:43:31 +0100

Hi all,

>> Can you still reproduce it on your end?
>
I'm using a ~3-week-old native-comp branch, this bug (#45375) doesn't 
happen anymore for me.

Note that the bisect gave a different commit for #46400, so maybe the 
issues are different, even though the symptoms are very similar (same?).

Thank you for looking at this!
Geza

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

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

Hello, Géza.

On Sat, Feb 13, 2021 at 19:43:31 +0100, Herman, Géza wrote:
> Hi all,

> >> Can you still reproduce it on your end?

> I'm using a ~3-week-old native-comp branch, this bug (#45375) doesn't 
> happen anymore for me.

The bug was caused by an error in the handling of a cache (the
"c-state-cache" which tracks the position of certain
braces/brackets/parenthese).  I can assure you the error is still there,
even if it isn't currently triggering very often.

> Note that the bisect gave a different commit for #46400, so maybe the 
> issues are different, even though the symptoms are very similar (same?).

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.

> Geza


Hello, Konstantin.

>> I don't think the bug was introduced by the commit you cite, more
>> likely that commit triggered the bug which was lying in wait elsewhere.

>> I've been working on this bug for several hours, so far, and have found
>> that the "c-state-cache" (which records the positions of certain
>> braces, brackets and parentheses) becomes corrupt while running your
>> `test' function.  I'm trying to track down where and how this
>> corruption happens.

>> Also relevant is that the bug seems to be being triggered by the
>> apostrophe in

>>     bar("Couldn't open %s", to);
>>                ^

>> ..  At least, if I take that apostrophe away, I don't see the bug
>> symptoms any more.

Actually, I was mistaken on this front - the apostrophe had nothing to do
with it.

>> So, please bear with me some while longer.  I am working on the bug.

> D: Oh, this is cool! Sure, thank you very much for looking into it! I'm
> definitely not in hurry, I was just kinda being afraid that the report
> could've gotten through the cracks. I'm happy to hear that wasn't the
> case �

It was indeed a bug in the c-state-cache handling, and I now have a patch
to fix it.  After applying the patch, the `test' function no longer
produces a newline without indentation.  There is something complicated
going on with `undo', so that `test' sometimes reports there is no more
undo data, but the indentation left on new lines is always correct.

As I said above, I intend to commit the patch below in a few days time.
Please feel free to apply it (to master) and test it out.  I would be
happy to hear of anything to do with this bug which is still not working.




diff --git a/lisp/progmodes/cc-engine.el b/lisp/progmodes/cc-engine.el
index 68dadcc272..653c4332b6 100644
--- a/lisp/progmodes/cc-engine.el
+++ b/lisp/progmodes/cc-engine.el
@@ -4314,38 +4314,29 @@ c-invalidate-state-cache-1
       (setq c-state-nonlit-pos-cache-limit (1- here)))
   (c-truncate-lit-pos-cache here)
 
-  ;; `c-state-cache':
-  ;; Case 1: if `here' is in a literal containing point-min, everything
-  ;; becomes (or is already) nil.
-  (if (or (null c-state-cache-good-pos)
-	  (< here (c-state-get-min-scan-pos)))
-      (setq c-state-cache nil
-	    c-state-cache-good-pos nil
-	    c-state-min-scan-pos nil)
-
-    ;; Truncate `c-state-cache' and set `c-state-cache-good-pos' to a value
-    ;; below `here'.  To maintain its consistency, we may need to insert a new
-    ;; brace pair.
-    (let ((here-bol (c-point 'bol here))
-	  too-high-pa  ; recorded {/(/[ next above or just below here, or nil.
-	  dropped-cons)		  ; was the last removed element a brace pair?
-      ;; The easy bit - knock over-the-top bits off `c-state-cache'.
-      (while (and c-state-cache
-		  (>= (c-state-cache-top-paren) here))
-	(setq dropped-cons (consp (car c-state-cache))
-	      too-high-pa (c-state-cache-top-lparen)
-	      c-state-cache (cdr c-state-cache)))
-
-      ;; Do we need to add in an earlier brace pair, having lopped one off?
-      (if (and dropped-cons
-	       (<= too-high-pa here))
-	  (c-append-lower-brace-pair-to-state-cache too-high-pa here here-bol))
-      (if (and c-state-cache-good-pos (< here c-state-cache-good-pos))
-	  (setq c-state-cache-good-pos
-		(or (save-excursion
-		      (goto-char here)
-		      (c-literal-start))
-		    here)))))
+  (cond
+   ;; `c-state-cache':
+   ;; Case 1: if `here' is in a literal containing point-min, everything
+   ;; becomes (or is already) nil.
+   ((or (null c-state-cache-good-pos)
+	(< here (c-state-get-min-scan-pos)))
+    (setq c-state-cache nil
+	  c-state-cache-good-pos nil
+	  c-state-min-scan-pos nil))
+
+   ;; Case 2: `here' is below `c-state-cache-good-pos', so we need to amend
+   ;; the entire `c-state-cache' data.
+   ((< here c-state-cache-good-pos)
+    (let* ((res (c-remove-stale-state-cache-backwards here))
+	   (good-pos (car res))
+	   (scan-backward-pos (cadr res))
+	   (scan-forward-p (car (cddr res))))
+      (if scan-backward-pos
+	  (c-append-lower-brace-pair-to-state-cache scan-backward-pos here))
+      (setq c-state-cache-good-pos
+	    (if scan-forward-p
+		(c-append-to-state-cache good-pos here)
+	      good-pos)))))
 
   ;; The brace-pair desert marker:
   (when (car c-state-brace-pair-desert)


-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 46400 <at> debbugs.gnu.org
Subject: Re: [BISECTED] Sporadically breaking newline-indentation in c-mode
Date: Thu, 18 Feb 2021 00:59:08 +0300

Hey! Sorry: I'm replying to the wrong email because it seems I stopped receiving
notifications for the report since the last time I sent an email here. I didn't even
know there was a discussion ongoing till I occasionally looked through the web
interface ☺ The web-interface doesn't allow to reply a specific comment, so I had to
reply to an arbitrary email, last one I got in my mailbox. Sorry. (on a side-note,
Idk what happened to notifications. I looked through spam and other folders, tried
using built-in search on my email-provider in case some filter put them into a random
folder, but emails are nowhere to be seen. Looks like I just wasn't getting any
notifications).

Alan Mackenzie wrote:

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

Oh, this is amazing! I'll give the patch a try as well. I assume though there will be
nothing to report (well, other than "Thank you for fixing the bug" 😉), but if I
happen to find some other problem, I'll make sure to drop an email either here or to
a new report :)

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

From: Alan Mackenzie <acm <at> muc.de>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: 46400 <at> debbugs.gnu.org
Subject: Re: [BISECTED] Sporadically breaking newline-indentation in c-mode
Date: Thu, 18 Feb 2021 11:21:50 +0000

Hello, Konstantin.

On Thu, Feb 18, 2021 at 00:59:08 +0300, Konstantin Kharlamov wrote:
> Hey! Sorry: I'm replying to the wrong email because it seems I stopped
> receiving notifications for the report since the last time I sent an
> email here. I didn't even know there was a discussion ongoing till I
> occasionally looked through the web interface ☺ The web-interface
> doesn't allow to reply a specific comment, so I had to reply to an
> arbitrary email, last one I got in my mailbox. Sorry. (on a side-note,
> Idk what happened to notifications. I looked through spam and other
> folders, tried using built-in search on my email-provider in case some
> filter put them into a random folder, but emails are nowhere to be
> seen. Looks like I just wasn't getting any notifications).

I kept getting rejections from you mail server (something to do with my
ISP's server not sending a STARTTLS operator), so in the end I stopped
adding your address to the To: or Cc: headers.

It might well be I messed something up when I merged this bug with the
other one.  I've not done merging of bugs very often.

Sorry you didn't get the posts from debbugs.gnu.org.

> Alan Mackenzie wrote:

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

> Oh, this is amazing! I'll give the patch a try as well. I assume though
> there will be nothing to report (well, other than "Thank you for fixing
> the bug" 😉), but if I happen to find some other problem, I'll make
> sure to drop an email either here or to a new report :)

Thank you, indeed!  I haven't committed the patch, yet, and I'll leave
off a few days yet.  It's surprising just how often asking people to
check patches for their bugs gets a reply that things aren't properly
fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: 46400 <at> debbugs.gnu.org
Subject: Re: bug#46400: [BISECTED] Sporadically breaking newline-indentation
 in c-mode
Date: Tue, 23 Feb 2021 11:26:19 +0000

Hello again, Konstantin.

On Thu, Feb 18, 2021 at 11:21:50 +0000, Alan Mackenzie wrote:
> On Thu, Feb 18, 2021 at 00:59:08 +0300, Konstantin Kharlamov wrote:
> > Hey! Sorry: I'm replying to the wrong email because it seems I stopped
> > receiving notifications for the report since the last time I sent an
> > email here. I didn't even know there was a discussion ongoing till I
> > occasionally looked through the web interface ☺ The web-interface
> > doesn't allow to reply a specific comment, so I had to reply to an
> > arbitrary email, last one I got in my mailbox. Sorry. (on a side-note,
> > Idk what happened to notifications. I looked through spam and other
> > folders, tried using built-in search on my email-provider in case some
> > filter put them into a random folder, but emails are nowhere to be
> > seen. Looks like I just wasn't getting any notifications).

> I kept getting rejections from you mail server (something to do with my
> ISP's server not sending a STARTTLS operator), so in the end I stopped
> adding your address to the To: or Cc: headers.

Apologies: I got your email address confused with another one beginning
with 'k'.  Your address works just fine, and I never deliberately
omitted it from a Cc:.

> It might well be I messed something up when I merged this bug with the
> other one.  I've not done merging of bugs very often.

> Sorry you didn't get the posts from debbugs.gnu.org.

> > Alan Mackenzie wrote:

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

> > Oh, this is amazing! I'll give the patch a try as well. I assume though
> > there will be nothing to report (well, other than "Thank you for fixing
> > the bug" 😉), but if I happen to find some other problem, I'll make
> > sure to drop an email either here or to a new report :)

> Thank you, indeed!  I haven't committed the patch, yet, and I'll leave
> off a few days yet.  It's surprising just how often asking people to
> check patches for their bugs gets a reply that things aren't properly
> fixed.

I have now committed the patch to all relevant places, and I'm going to
close bug #45375 (which has been merged with bug #46400) next.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 46400 <at> debbugs.gnu.org
Subject: Re: bug#46400: [BISECTED] Sporadically breaking newline-indentation
 in c-mode
Date: Tue, 23 Feb 2021 14:32:19 +0300

On Tue, 2021-02-23 at 11:26 +0000, Alan Mackenzie wrote:
> Hello again, Konstantin.

Hello!

> Apologies: I got your email address confused with another one beginning
> with 'k'.  Your address works just fine, and I never deliberately
> omitted it from a Cc:.
> 
> > It might well be I messed something up when I merged this bug with the
> > other one.  I've not done merging of bugs very often.
> 
> > Sorry you didn't get the posts from debbugs.gnu.org.

No worries!

> > > Alan Mackenzie wrote:
> 
> > > > 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.
> 
> > > Oh, this is amazing! I'll give the patch a try as well. I assume though
> > > there will be nothing to report (well, other than "Thank you for fixing
> > > the bug" 😉), but if I happen to find some other problem, I'll make
> > > sure to drop an email either here or to a new report :)
> 
> > Thank you, indeed!  I haven't committed the patch, yet, and I'll leave
> > off a few days yet.  It's surprising just how often asking people to
> > check patches for their bugs gets a reply that things aren't properly
> > fixed.
> 
> I have now committed the patch to all relevant places, and I'm going to
> close bug #45375 (which has been merged with bug #46400) next.


Thank you! FTR, I have used your patch since my previous email, and haven't
noticed any problems. In fact, I even found one thing fixed (but I don't know if
it's relevant to the patch or was it some other change on master), which is that
if I remove a " symbol around a string, code gets re-highlighted immediately (I
seem to remember it was rehighlighted with a delay previously).

So, all in all, my experience is great so far!

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

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.