unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#20778: Flush left indentation in c-mode
@ 2015-06-09 16:49 Bruce Korb
       [not found] ` <mailman.4701.1433868613.904.bug-gnu-emacs@gnu.org>
  2015-06-26 21:24 ` Bruce Korb
  0 siblings, 2 replies; 6+ messages in thread
From: Bruce Korb @ 2015-06-09 16:49 UTC (permalink / raw)
  To: 20778


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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#20778: Flush left indentation in c-mode
       [not found] ` <mailman.4701.1433868613.904.bug-gnu-emacs@gnu.org>
@ 2015-06-10 11:00   ` Alan Mackenzie
  2015-06-12 14:55     ` Bruce Korb
  0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2015-06-10 11:00 UTC (permalink / raw)
  To: 20778; +Cc: Bruce Korb

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






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#20778: Flush left indentation in c-mode
  2015-06-10 11:00   ` Alan Mackenzie
@ 2015-06-12 14:55     ` Bruce Korb
  0 siblings, 0 replies; 6+ messages in thread
From: Bruce Korb @ 2015-06-12 14:55 UTC (permalink / raw)
  To: Alan Mackenzie, 20778

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#20778: Flush left indentation in c-mode
  2015-06-09 16:49 bug#20778: Flush left indentation in c-mode Bruce Korb
       [not found] ` <mailman.4701.1433868613.904.bug-gnu-emacs@gnu.org>
@ 2015-06-26 21:24 ` Bruce Korb
  2021-08-16 13:05   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 6+ messages in thread
From: Bruce Korb @ 2015-06-26 21:24 UTC (permalink / raw)
  To: 20778

[-- 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));
}

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#20778: Flush left indentation in c-mode
  2015-06-26 21:24 ` Bruce Korb
@ 2021-08-16 13:05   ` Lars Ingebrigtsen
  2021-09-14 10:54     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-16 13:05 UTC (permalink / raw)
  To: Bruce Korb; +Cc: 20778

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#20778: Flush left indentation in c-mode
  2021-08-16 13:05   ` Lars Ingebrigtsen
@ 2021-09-14 10:54     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-14 10:54 UTC (permalink / raw)
  To: Bruce Korb; +Cc: 20778

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-09-14 10:54 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-09 16:49 bug#20778: Flush left indentation in c-mode Bruce Korb
     [not found] ` <mailman.4701.1433868613.904.bug-gnu-emacs@gnu.org>
2015-06-10 11:00   ` Alan Mackenzie
2015-06-12 14:55     ` Bruce Korb
2015-06-26 21:24 ` Bruce Korb
2021-08-16 13:05   ` Lars Ingebrigtsen
2021-09-14 10:54     ` Lars Ingebrigtsen

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).