GNU bug report logs - #20778
Flush left 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 20778 in the body.
You can then email your comments to 20778 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: Bruce Korb <bkorb <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Flush left indentation in c-mode
Date: Tue, 09 Jun 2015 09:49:15 -0700

With the patched cc-mode, I ran into this situation again.
It seems to think that the flush-left alignment of the "if" statement is fine.
The rest of the code indents as you see here.  Reloading cc-mode does no
good, it leaves the statement flush left.  Closing and re-visiting the file
cleans up the confusion and re-indents correctly.

I do not know what you can do about it without better information from me,
but I don't know what to tell you either.  :(  Oh, the "c-file-style" is "linux".

> void ftl_ns_print(void)
> {
> #if MAX_EVENT_EVT_PRIORITY >= LOG_DEBUG
> 	int skip_ct = 0;
>
> 	for (int i = 0; i < s_ns_table.nst_count; i++) {
> 		struct ftl_ns_t * const ns_p = &s_ns_table.nst_ns_list[i];
>
> 		if (ns_p->active_ns_id == NS_ID_NULL) {
> 			skip_ct++;
> 			continue;
> 		}
>
> 		EMIT_PRINT_NS_EVENT(
> 			debug, "ns_id=%d, flags=%u, active_ns_id=%d, parent_ns_id=%d, next_snapshot_ns_id=%d, "
> 			"snapshot_sn=%u, size_byte=%lu, used_bytes=%lu, physical_used_bytes=%lu, max_lpn=%lu, "
> 			"creation_io_id=%lu, snapshot_sn_seq=%u\n",
> 			sint32, ns_p->ns_id,
> 			uint32, ns_p->flags,
> 			sint32, ns_p->active_ns_id,
> 			sint32, ns_p->parent_ns_id,
> 			sint32, ns_p->next_snapshot_ns_id,
> 			uint32, ns_p->snapshot_sn,
> 			uint64, ns_p->size_bytes,
> 			uint64, ns_p->used_bytes,
> 			uint64, ns_p->physical_used_bytes,
> 			uint64, ns_p->max_lpn,
> 			uint64, ns_p->creation_io_id,
> 			uint32, ns_p->snapshot_sn_seq
> 			);
> 	}
>
> if (skip_ct > 0)
> 	EMIT_SKIPPED_NS_EVENT(debug, "skipped %d empty name spaces", sint32, skip_ct);
> #endif
> }

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

From: Alan Mackenzie <acm <at> muc.de>
To: 20778 <at> debbugs.gnu.org
Cc: Bruce Korb <bkorb <at> gnu.org>
Subject: Re: bug#20778: Flush left indentation in c-mode
Date: 10 Jun 2015 11:00:34 -0000

Hello, Bruce.

In article <mailman.4701.1433868613.904.bug-gnu-emacs <at> gnu.org> you wrote:

> With the patched cc-mode, I ran into this situation again.

Er, any chance of a reference to "this situation"?  Perhaps the bug number
of a previous bug, or the Subject: and Date: of a pertinent email, or
something like that.  :-)

> It seems to think that the flush-left alignment of the "if" statement is fine.
> The rest of the code indents as you see here.  Reloading cc-mode does no
> good, it leaves the statement flush left.  Closing and re-visiting the file
> cleans up the confusion and re-indents correctly.

> I do not know what you can do about it without better information from me,
> but I don't know what to tell you either.  :(  Oh, the "c-file-style" is "linux".

OK, standard information, please:
(i) The Emacs version number (M-x emacs-version).
(ii) The CC Mode version (M-x c-version).
(iii) Have you got any CC Mode customisations in your .emacs?  You've
  already said you're in style "linux", but is there anything else?  If
  so, what?
(iii) The EXACT steps you took between starting Emacs to seeing the error,
  detailed enough that I can reproduce it.
(iv) What exactly do you mean "It seems to think that the flush-left
  alignment ... is fine"?  What command did you give that led you to this
  conclusion, or what output from CC Mode was relevant?

Just for info, when I loaded the following fragment into Emacs, stripped
of the leading "> " from each line, set the style "linux", then indented
it (by indenting the first two lines using <tab>, then placing point at
the opening "{" and doing C-M-q), the indentation was fine.  I can't
reproduce the problem at the moment.

>> void ftl_ns_print(void)
>> {
>> #if MAX_EVENT_EVT_PRIORITY >= LOG_DEBUG
>>       int skip_ct = 0;
>>
>>       for (int i = 0; i < s_ns_table.nst_count; i++) {
>>               struct ftl_ns_t * const ns_p = &s_ns_table.nst_ns_list[i];
>>
>>               if (ns_p->active_ns_id == NS_ID_NULL) {
>>                       skip_ct++;
>>                       continue;
>>               }
>>
>>               EMIT_PRINT_NS_EVENT(
>>                       debug, "ns_id=%d, flags=%u, active_ns_id=%d, parent_ns_id=%d, next_snapshot_ns_id=%d, "
>>                       "snapshot_sn=%u, size_byte=%lu, used_bytes=%lu, physical_used_bytes=%lu, max_lpn=%lu, "
>>                       "creation_io_id=%lu, snapshot_sn_seq=%u\n",
>>                       sint32, ns_p->ns_id,
>>                       uint32, ns_p->flags,
>>                       sint32, ns_p->active_ns_id,
>>                       sint32, ns_p->parent_ns_id,
>>                       sint32, ns_p->next_snapshot_ns_id,
>>                       uint32, ns_p->snapshot_sn,
>>                       uint64, ns_p->size_bytes,
>>                       uint64, ns_p->used_bytes,
>>                       uint64, ns_p->physical_used_bytes,
>>                       uint64, ns_p->max_lpn,
>>                       uint64, ns_p->creation_io_id,
>>                       uint32, ns_p->snapshot_sn_seq
>>                       );
>>       }
>>
>> if (skip_ct > 0)
>>       EMIT_SKIPPED_NS_EVENT(debug, "skipped %d empty name spaces", sint32, skip_ct);
>> #endif
>> }

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Bruce Korb <bkorb <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>, 20778 <at> debbugs.gnu.org
Subject: Re: bug#20778: Flush left indentation in c-mode
Date: Fri, 12 Jun 2015 07:55:37 -0700

On 06/10/15 04:00, Alan Mackenzie wrote:
>> With the patched cc-mode, I ran into this situation again.
>
> Er, any chance of a reference to "this situation"?

"see below" :)

>> I do not know what you can do about it without better information from me,
>> but I don't know what to tell you either.  :(  Oh, the "c-file-style" is "linux".
>
> OK, standard information, please:
> (i) The Emacs version number (M-x emacs-version).

> $ emacs --version
> GNU Emacs 24.3.1
> Copyright (C) 2013 Free Software Foundation, Inc.

> (ii) The CC Mode version (M-x c-version).

> $ ls -l ~/.emacs.d|fgrep cc-mode
> drwxr-xr-x 2 bkorb dev   4096 May 11 13:31 cc-mode
> -rw-r----- 1 bkorb dev 580925 May  7 17:19 cc-mode-5.32.5.tar.gz

5.32.5, but patched:

> --- cc-cmds.el  2013-05-03 10:11:16.000000000 -0700
> +++ ../cc-mode/cc-cmds.el       2015-05-11 13:31:16.758777535 -0700
> @@ -937,15 +937,8 @@
>         ;; do all cleanups and newline insertions if c-auto-newline is on.
>         (if (or (not c-auto-newline)
>                 (not (looking-at "[ \t]*\\\\?$")))
> -           (when c-syntactic-indentation
> -               (let ((syntax (c-guess-basic-syntax)))
> -                 (c-indent-line syntax)
> -                 ;; Guard against the C hacker inserting a statement before a
> -                 ;; non-compound statement in an if/while/for.
> -                 (if (eq (caar syntax) 'substatement)
> -                     (save-excursion
> -                       (if (eq 0 (forward-line))
> -                           (c-indent-line))))))
> +           (if c-syntactic-indentation
> +                (c-indent-line))
>           ;; clean ups: list-close-comma or defun-close-semi
>           (let ((pos (- (point-max) (point))))
>             (if (c-save-buffer-state ()

> (iii) Have you got any CC Mode customisations in your .emacs?  You've
>    already said you're in style "linux", but is there anything else?  If
>    so, what?

Not much:

> $ cat .dir-locals.el
>
> (
>  (nil . ((indent-tabs-mode . t)
>          (tab-width . 8)
>          (show-trailing-whitespace . t)
>          (fill-column . 132)))
>
>  (c-mode . ((c-file-style . "linux")))
> )

> (iii) The EXACT steps you took between starting Emacs to seeing the error,
>    detailed enough that I can reproduce it.

If I knew the answer to that, I would have included that.  :(
I work for hours and then suddenly this happens.
The mechanism for clearing it requires closing and re-visiting the file
in question.  I do not have to restart emacs.  Changing to another
mode and changing back to C-mode is not effective (i.e. the problem
persists).

> (iv) What exactly do you mean "It seems to think that the flush-left
>    alignment ... is fine"?  What command did you give that led you to this
>    conclusion, or what output from CC Mode was relevant?

I put the cursor on the flush-left "if" line and press <tab> to no effect.
I re-indent the region, to no effect.  I switch to "text-mode" and back
and re-indent the region, to no effect.  I close and re-visit the file
and indent-region now works correctly, as you see for yourself when
you tried re-indenting the region.  The only way I can think of
to resolve this is if there is some information I can dump out
about the buffer the next time it happens.  Obviously, I have to close
and re-visit the file fairly soon, as this is my day job....

> Just for info, when I loaded the following fragment into Emacs, stripped
> of the leading "> " from each line, set the style "linux", then indented
> it ....  I can't
> reproduce the problem at the moment.

It is not the particular code fragment, but the editing history
that seems to trigger the problem.  I have trouble remembering
all the 100's to 1000's of keystrokes I went through to cause it. ;)

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

From: Bruce Korb <bruce.korb <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: bug#20778: Flush left indentation in c-mode
Date: Fri, 26 Jun 2015 14:24:03 -0700

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

Here is a short program that went into this weirdo mode several times
fairly quickly.
Adding #include directives might be involved, but maybe not.  Again,
the same symptom:
everything goes flush left until I close out and re-visit the file.
So, when you first visit
the file, I am sure it will indent properly.  And just because you
fiddle it, it doesn't mean
it will stop indenting properly.  I do not know what the trigger
mechanism is.  I just
know it was much more frequent (several times in a few minutes).

Again, "linux" style:

$ cat ../.dir-locals.el

(
 (nil . ((indent-tabs-mode . t)
         (tab-width . 8)
         (show-trailing-whitespace . t)
         (fill-column . 132)))

 (c-mode . ((c-file-style . "linux")))
)

[fix-tabs.c (text/x-csrc, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Bruce Korb <bruce.korb <at> gmail.com>
Cc: 20778 <at> debbugs.gnu.org
Subject: Re: bug#20778: Flush left indentation in c-mode
Date: Mon, 16 Aug 2021 15:05:01 +0200

Bruce Korb <bruce.korb <at> gmail.com> writes:

> Here is a short program that went into this weirdo mode several times
> fairly quickly.  Adding #include directives might be involved, but
> maybe not.  Again, the same symptom: everything goes flush left until
> I close out and re-visit the file.  So, when you first visit the file,
> I am sure it will indent properly.  And just because you fiddle it, it
> doesn't mean it will stop indenting properly.  I do not know what the
> trigger mechanism is.  I just know it was much more frequent (several
> times in a few minutes).

(I'm going through old bug reports that unfortunately got no response at
the time.)

I tried reproducing this bug in Emacs 28, but I was unable to.  But as
you say, it may be difficult to trigger.

Are you still seeing this issue in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Bruce Korb <bruce.korb <at> gmail.com>
Cc: 20778 <at> debbugs.gnu.org
Subject: Re: bug#20778: Flush left indentation in c-mode
Date: Tue, 14 Sep 2021 12:54:45 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I tried reproducing this bug in Emacs 28, but I was unable to.  But as
> you say, it may be difficult to trigger.
>
> Are you still seeing this issue in recent Emacs versions?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.