Autopairing broken in master branch in java-mode/c++mode

[yyoncho]

I think that recent change in lisp/progmodes/cc-mode.el in emacs master branch broke smartparens because smartparens works fine in js-mode/rust-mode but breaks in java-mode/c++-mode. At the same time, it works fine in emacs26. I could debug it on my side if you give me a point what is the place in the code which is responsible to write the closing pair.

Expected behavior

( to be closed.

Actual behavior

When I type ( it is not closed.

Steps to reproduce the problem

Open java/cpp file, do M-x smartparens-mode and write (

Environment & version information

• smartparens version: 20190622.1750
• Active major-mode: java-mode
• Smartparens strict mode: nil
• Emacs version (M-x emacs-version): GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32) of 2019-07-11
• Starterkit/Distribution: Vanilla
• OS: gnu/linux

(cc @joaotavora you might be interested since you are participating in a discussion about eletric-pair-mode in emacs-devel which might be related to the issue).

[joaotavora]

you are participating in a discussion about eletric-pair-mode in emacs-devel which might be related to the issue

Thanks. Indeed. It might be related, but let's wait until this is analysed. In the meantime, can you try

(advice-add 'c-unescaped-nls-in-string-p
	    :around
	    (lambda (_ _)
	      t))

And see if the problem persists?

My intuition is that it will persist. It might related to another recent cc-mode change whereby it (cc-mode) decides to bypass post-self-insert-hook (something also don't agree with, and have stated disagreement in the past). But again, let's wait this is analyzed in smartparens.

[yyoncho]

And see if the problem persists?

It still persists. FTR this fixes smartparens (it may be expected).

(define-key java-mode-map "(" nil)

It might related to another recent cc-mode change whereby it (cc-mode) decides to bypass post-self-insert-hook (something also don't agree with, and have stated disagreement in the past). But again, let's wait this is analyzed in smartparens.

I noticed that too - it breaks lsp-mode's onTypeFormatting.

[yyoncho]

Actually, seems like this is causing the issue: When I remove the let block smartparens work fine.

    (let (post-self-insert-hook) ; The only way to get defined functionality
                                        ; from `self-insert-command'.
      (self-insert-command (prefix-numeric-value arg)))

Edit: to clarify this is part of c-electric-paren

[joaotavora]

Edit: to clarify this is part of c-electric-paren

Sooner or later we need a mode that doesn't bind custom commands for ( and ) and so on, or at least doesn't do what c-electric-paren does. Until then, there's not much smartparens or other extensions can do, short of radically changing how they work just for cc-mode ,which is slightly non-optimal to say the least.

[Fuco1]

Yep, basically smartparens works by having a hook on post-self-insert-hook. I also have a bunch of special hacks on post-command-hook where there is a list of "special insert commands" and I basically fix them on a case-by-case basis. But the recent changes in cc-mode made even this approach broken (though I haven't analyzed exactly why it stopped working).

What we can do is to patch the functions involved with advices or straight-up redefine them but that is pretty invasive solution.

As @yyoncho pointed out "unbinding" the commands works and that's what I personally do in my configuration.

[yyoncho]

As @yyoncho pointed out "unbinding" the commands works and that's what I personally do in my configuration.

I will do that but IMO this must be fixed in the upstream - it doesn't make sense to provide post-self-insert-hook in Emacs core and then break it in another Emacs core component(cc-mode). At least the behaviour of cc-mode should not be the default one...

[joaotavora]

That's right, you should submit an emacs bug report stating just that.

[rileyrg]

Just a "beep": It is broken in PHP-MODE in emacs 27 too.

[yyoncho]

I reported the issue in emacs and it was fixed https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38406 - I am yet to test with ToT whether it works.