[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42319: 28.0.50; c-mode issue with electric-pair-mode
From: |
Alan Mackenzie |
Subject: |
bug#42319: 28.0.50; c-mode issue with electric-pair-mode |
Date: |
Sun, 12 Jul 2020 10:54:59 +0000 |
Hello, Ergus.
On Sat, Jul 11, 2020 at 15:15:12 +0200, Ergus wrote:
> On Sat, Jul 11, 2020 at 10:26:53AM -0000, Alan Mackenzie wrote:
> >This happens because of the missing semicolon after the class. CC Mode
> >indents the otherwise empty line as a 'topmost-intro-cont line,
> I supposed so.
> >since it appears still to be within the class.
> But this is an issue right? because after that } it is already out of
> the class; ... even without the `;` there is not a class scope to indent
> right? The same applies to nested classes.
The same also applies to structs and unions. Each of these constructs is
incomplete without the closing semicolon.
> Actually AFAIK without the `;` there is a syntax error if we insert
> anything else except for inline class/variable declarations like:
Precisely!
> class A {
> } var;
> or
> typedef class A {
> } type_A;
> But then the new line after the } should never be added?
You could well be right, here. I'd have to check carefully all the
things that can generate a 'class-close syntax before changing the
defaults.
> >One workaround for this is to
> >configure CC Mode not to insert a newline after this particular type of
> >brace. For example
> >(push '(class-close before) c-hanging-braces-alist)
> >, to try it out (it's a buffer local variable).
> This works, thanks. I think that this should be the default as it is the
> most general/expected behavior and doesn't insert extra
> newline/spaces. This work around seems to be a cleaner solution than the
> cleanup ;p because it works easier for:
> =========
> For: };
> class A {
> };
> #
> =========
> And for: } var;
> class A {
> } var;
> #
> I think the user never wants this:
> ==========
> class A {
> }
> ;
> #
> =========
> or
> =========
> class A {
> }
> var;
> #
> And for sure not this:
> =========
> class A {
> }
> var;
> #
> =========
> But I am probably wrong.
My experience is that there's virtually _no_ form of indentation which no
user wants. But I think I'll look at changing that default.
> >> The problem is actually worst if defun-close-semi is in c-cleanup-list
> >> because it doesn't work.
> >That surprises me. It works for me, here. What happens/fails to happen
> >in these circumstances?
> Ohh, my bad. I forgot to add defun-close-semi when using -Q for
> reporting. So please forget it and forgive me.
No problems! Far better than there actually being a bug. ;-)
> >> I need to remove the extra spaces first to make it work.
> >That indeed feels like a bug. Could you perhaps post your CC Mode
> >configuration (generated by C-c C-b), please, which should help me to
> >reproduce the bug.
> I discovered myself error with this... very useful. Thanks.
> So probably if you don't think that the extra indentation is an issue
> you can close this bug.
I think that indentation is correct, even if a bit awkward. That's why
that cleanup is available. So, yes, I'll close the bug, thanks.
> Off-topic:
> I reported another issue (bug#42270) related with attributes and
> indentation. did you see it?
Yes, I started working on it on Thursday. Most of that time, I've "just
been an hour away from finishing it", so it didn't feel necessary to
acknowledge the bug. That was a mistake, sorry. Actually, there're
quite a few tricky things in there to sort out and clean up, so it could
take a few days yet.
> Very Thanks,
> Ergus
--
Alan Mackenzie (Nuremberg, Germany).