bug#42319: 28.0.50; c-mode issue with electric-pair-mode

[Alan Mackenzie <acm@muc.de>]

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