bug#20778: Flush left indentation in c-mode

bug#20778: Flush left indentation in c-mode

[Bruce Korb]

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

bug#20778: Flush left indentation in c-mode

[Alan Mackenzie]

Hello, Bruce.

In article <mailman.4701.1433868613.904.bug-gnu-emacs@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).

bug#20778: Flush left indentation in c-mode

[Bruce Korb]

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

bug#20778: Flush left indentation in c-mode

[Bruce Korb]

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

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")))
)

[-- Attachment #2: fix-tabs.c --]
[-- Type: text/x-csrc, Size: 1803 bytes --]


#include <sys/types.h>
#include <sys/stat.h>

#include <ctype.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define NL  '\n'
#define NUL '\0'
#define HT  '\t'

static void
fserr(char const * fn, char const * op)
{
	char const * err = strerror(errno);

	fprintf(stderr, "fs error %u (%s) %s on %s\n",
		errno, err, op, fn);
	exit(EXIT_FAILURE);
}

static inline char *
detab(char * line)
{
	static union {
		unsigned long	spaces;
		unsigned char	sp[sizeof(unsigned long)];
	} const u = { .sp = { ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ' } };
	int tab_ct = 0;
	unsigned long * lp = (void *)line;

	while (*lp == u.spaces) {
		tab_ct++;
		lp++;
	}

	line = (char *)lp;

	// Trim trailing white space
	{
		char * eol  = line + strlen(line);
		while ((eol > line) && isspace((unsigned)eol[-1]))
			eol--;
		*(eol++) = NL;
		*eol     = NUL;
		if (eol == line + 1)
			return line; // blank line
	}

	// insert "tab_ct" tab characters before the point where "line" points
	//
	while (tab_ct-- > 0)
		*(--line) = HT;
	return line;
}

static inline void
fix_file(char const * fname)
{
	char line[0x2000]; // any line over 8K deserves being mangled.

	FILE * ifp = fopen(fname, "r");

	if (ifp == NULL)
		fserr("open-read", fname);

	char tpl[] = "fix-tabs-XXXXXX";
	int fd = mkstemp(tpl);

	if (fd < 0)
		fserr("mkstemp", tpl);

	FILE * ofp = fdopen(fd, "w");

	if (ofp == NULL)
		fserr("open-write", tpl);

	for (;; ) {
		char * p = fgets(line, sizeof(line), ifp);
		if (p == NULL)
			break;
		fputs(detab(line), ofp);
	}
	{
		struct stat sb;
		if (fstat(fileno(ifp), &sb) == 0)
			fchmod(fd, sb.st_mode);
	}
	fclose(ifp);
	fclose(ofp);
	unlink(fname);
	rename(tpl, fname);
}

int
main(int argc, char ** argv)
{
	while (--argc > 0)
		fix_file(*(++argv));
}

bug#20778: Flush left indentation in c-mode

[Lars Ingebrigtsen]

Bruce Korb <bruce.korb@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

bug#20778: Flush left indentation in c-mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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