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

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

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

--text follows this line--

In c-mode there is an issue of adding some extra spaces in
electric-pair-mode after class definitions.

For example

emacs -Q main.cxx
M-x electric-pair-mode
M-x c-toggle-auto-newline
and then insert:

class A {

you should get: (# means the cursor)

class A
{
  #
}

now insert } and then you get

class A
{
  
}
  #

instead of:

class A
{
  
}
#

The problem is actually worst if defun-close-semi is in c-cleanup-list
because it doesn't work. I need to remove the extra spaces first to make
it work.


In GNU Emacs 28.0.50 (build 12, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
 of 2020-07-10 built on ergus
Repository revision: 7caf570662e41dd7cb90efaf8a335918cf1ac0da
Repository branch: master
System Description: Debian GNU/Linux 10 (buster)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
main.cxx has auto save data; consider M-x recover-this-file
Electric-Pair mode enabled
You can run the command ‘c-toggle-auto-newline’ with C-c C-a
Undo [2 times]
Mark set
Making completion list...

Configured using:
 'configure --prefix=/home/ergus/.local/ --with-mailutils'

Configured features:
XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
LUCID X11 XDBE XIM MODULES THREADS PDUMPER

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C++//la

Minor modes in effect:
  electric-pair-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs text-property-search time-date subr-x seq mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
cus-start cus-load elec-pair cc-mode cc-fonts easymenu cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib
term/tmux term/xterm xterm byte-opt gv bytecomp byte-compile cconv
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 78618 7004)
 (symbols 48 9526 1)
 (strings 32 23498 1860)
 (string-bytes 1 844562)
 (vectors 16 10057)
 (vector-slots 8 107261 7421)
 (floats 8 26 435)
 (intervals 56 287 3)
 (buffers 992 12))

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

[Alan Mackenzie]

Hello, Ergus.

In article <mailman.82.1594456263.2306.bug-gnu-emacs@gnu.org> you wrote:
> In c-mode there is an issue of adding some extra spaces in
> electric-pair-mode after class definitions.

> For example

> emacs -Q main.cxx
> M-x electric-pair-mode
> M-x c-toggle-auto-newline
> and then insert:

> class A {

> you should get: (# means the cursor)

> class A
> {
>  #
> }

> now insert } and then you get

> class A
> {
>  
> }
>  #

> instead of:

> class A
> {
>  
> }
> #

This happens because of the missing semicolon after the class.  CC Mode
indents the otherwise empty line as a 'topmost-intro-cont line, since it
appears still to be within the class.  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).

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

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

> In GNU Emacs 28.0.50 (build 12, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
> of 2020-07-10 built on ergus
> Repository revision: 7caf570662e41dd7cb90efaf8a335918cf1ac0da
> Repository branch: master
> System Description: Debian GNU/Linux 10 (buster)

[ .... ]

> Major mode: C++//la

> Minor modes in effect:
>  electric-pair-mode: t
>  tooltip-mode: t
>  global-eldoc-mode: t
>  electric-indent-mode: t
>  mouse-wheel-mode: t
>  tool-bar-mode: t
>  menu-bar-mode: t
>  file-name-shadow-mode: t
>  global-font-lock-mode: t
>  font-lock-mode: t
>  auto-composition-mode: t
>  auto-encryption-mode: t
>  auto-compression-mode: t
>  line-number-mode: t
>  transient-mark-mode: t
>  abbrev-mode: t

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sat, Jul 11, 2020 at 10:26:53AM -0000, Alan Mackenzie wrote:
>Hello, Ergus.
>
>
>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.

Actually AFAIK without the `;` there is a syntax error if we insert
anything else except for inline class/variable declarations like:

class A {

} var;

or

typedef class A {

} type_A;

But then the new line after the } should never be added?



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

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

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

Off-topic:

I reported another issue (bug#42270) related with attributes and
indentation. did you see it?

Very Thanks,
Ergus

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

[Alan Mackenzie]

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