C/C++ electric commands not handled

[dieggsy]

Expected behavior

Inserting brackets (paren, curly bracket) in C/C++ mode autoinserts pair

Actual behavior

Pair not autoinserted

Steps to reproduce the problem

Enable smartparens-mode in C/C++ buffer, enter ( or {.

Backtraces if necessary (M-x toggle-debug-on-error)

Environment & version information

• smartparens version: <Please specify manually>
• Active major-mode: c++-mode
• Smartparens strict mode: nil
• Emacs version (M-x emacs-version): GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit) of 2019-01-30 (commit 08bc407a22)
• Starterkit/Distribution: Evil
• OS: gnu/linux

Additional info

I can work around this by adding c-electric-paren and c-electric-brace to sp--special-self-insert-commands.

[cbsirb]

I have the same issue with emacs-version: GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.4) of 2019-01-30. Looks like something added recently to emacs.

[Ruin0x11]

Same, caused by upgrade to Emacs 27. Version is GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.2) of 2019-02-28.

[tangxinfa]

The same problem encountered after upgrade to emacs 27.

By adding c-electric-paren and c-electric-brace to sp--special-self-insert-commands, and disable electric-indent-mode, it works.

(edit: as of emacs 28 this seems to be no longer necessary // @Fuco1)

[raxod502]

If you're adding the above workaround to your configuration, you should only do it for Emacs 27. If you do it in Emacs 26, then it will result in an extra paren being inserted: ())

[Hi-Angel]

By adding c-electric-paren and c-electric-brace to sp--special-self-insert-commands, and disable electric-indent-mode, it works

Thanks, works for me. To future readers: code to do this is

(setq sp--special-self-insert-commands (cl-list* 'c-electric-paren 'c-electric-brace sp--special-self-insert-commands))

[raxod502]

I would rather recommend the following code, which avoids adding those symbols again if the code is evaluated more than once:

;; Smartparens is broken in `cc-mode' as of Emacs 27. See
;; <https://github.com/Fuco1/smartparens/issues/963>.
(when (version<= "27" emacs-version)
  (dolist (fun '(c-electric-paren c-electric-brace))
    (add-to-list 'sp--special-self-insert-commands fun)))

[Fuco1]

Can we put this to the package itself? Anyone interested in a pull request?

Do we need to guard for the version? IOW does it behave differently on older Emacs?

[raxod502]

If you run that code in Emacs 26, it will misbehave. I think it is probably a good idea to figure out what is actually going on, and what changed between 26 and 27 to cause this—you're probably in a better position to understand that than I—before merging anything. (Maybe it's a bug in Emacs 27?)

[Hi-Angel]

An odd thing: on different computers I have 2 Emacses 27.0.50, one is built on 2018-12-29, the other is on 2019-04-07. The first one doesn't have the problem, the second one does. Their configuration differs though, but not by much (mostly to cater to differences between what I do in office and home), in the end it seems to be a bug in Emacs.

Maybe I'll try bisecting when I get some free time.

[Fuco1]

I run into this in php-mode and adding those functions to special insert didn't work for me either, but it should in principle... I think cc-mode is doing something very odd. It also doesn't seem to respect the self-insert-uses-region-functions settings.

Eh :/

[Hi-Angel]

Maybe I'll try bisecting when I get some free time.

Okay, so, I'm about to try it and… This may seem a weird question, but how does one enable inserting an autopair? E.g. I run the following:

emacs -Q --eval "(progn (package-initialize) (c++-mode) (smartparens-mode))"

…and I expect upon typing ( to automatically get ), but I get nothing.

I figured, over the years I've been using smartparens, default pairs have been overriden in my config to match behavior of SublimeText editor (though maybe not so much in latest version of the config).

Querying search engine with "smartparens auto insert pair" comes up with nothing. The README also doesn't mention how to enable it.

[Hi-Angel]

Oh, okay, I figured that with emacs 27 I'm not getting a pair without the code from comment. Works fine with emacs 26 though (I happen to have REmacs that's based on 26th version).

[Hi-Angel]

And yeah, this is odd: I'm pretty sure I was getting an extra paren without the code, but now I'm not getting any paren at all without it. Either way, having the code makes it work correctly. I'm confused. I guess, for bisection, I have to test both "not inserting" and "inserting an extra paren" conditions.

[Hi-Angel]

So, to report the progress: I'm currently stuck trying to figure out, how to insert a paren ( from elisp, so I could automate bisection. I tried (let ((last-command-event ?\( )) (call-interactively #'c-electric-paren)), and doing (run-hooks 'post-command-hook) after the opening ( is in buffer. None of it triggers smartparens to insert closing pair, even though it inserts it when typing manually.

[Fuco1]

Look at execute-kbd-macro that should be close to 100% simulation of when you actually hit a key on your keyboard.

[Hi-Angel]

Eh, turned out bisecting Emacs is harder than I expected. Once in a while build breaks with one or another error after an entry Collecting OKURI-NASI entries..., and make clean && make distclean doesn't help, one needs to remove whole source code repository, losing bisection results.

[raxod502]

@Hi-Angel Try git clean -ffdx, and if things are really screwed up then also find . -exec touch '{}' ';'

[Hi-Angel]

Yay, I found the bad commit in Emacs, it's this one:

223e7b87872d4a010ae1c9a6f09a9c15aee46692 is the first bad commit
commit 223e7b87872d4a010ae1c9a6f09a9c15aee46692
Author: Alan Mackenzie <[email protected]>
Date:   Tue Jan 15 15:54:02 2019 +0000

    Make CC Mode and electric-pair-mode work together.  This fixes bug #33794

    * lisp/progmodes/cc-cmds.el (c-electric-pound, c-electric-slash)
    (c-electric-star, c-electric-semi&comma, c-electric-colon, c-electric-lt-gt):
    Bind post-self-insert-hook to nil around calls to self-insert-command to
    protect against arbitrary functionality confusing CC Mode.
    (c-do-brace-electrics): New function, extracted from c-electric-brace and
    enhanced.
    (c-electric-brace): Bind post-self-insert-hook to nil around the call to
    self-insert-command.  When electric-pair-mode is configured, call
    electric-pair-post-self-insert-function.  Handle any deletion done by this
    function.  Call c-do-brace-electrics for the inserted brace, and perhaps for a
    brace inserted by electric-pair-self-insert-function.
    (c-electric-paren): Bind post-self-insert-hook to nil around the call to
    self-insert-command.  When electric-pair-mode is configured, call
    electric-pair-post-self-insert-function.

:040000 040000 d9706860ac9b4ec8f747479d4f990372465f670d 97fb9d63d6618c391caa7fc564db4e511a544078 M      lisp

I double-checked: before this commit everything works, and then with this commit the bug appears.

Now, I guess a bug-report about regression needs to be created; but I'm not sure what to write about. What is the problem? The fact that the commit breaks an addon sounds vague. Can we pin it down to the actual functional not working? Is there maybe a hook or something that smartparens is using, which stopped working?

[Fuco1]

@Hi-Angel That's an amazing piece of detective work!

Yea, I think a bug report is really out of place. It seems weird that the "core" should care about outside plugins, however popular.

But with this new information I can at least look into it and possibly find a fix/workaround. If not, we can craft some change request upstream.

[Fuco1]

(let (post-self-insert-hook)	; Disable random functionality.

well :D

[mnewt]

For convenience, here is a direct link to the discussion of the aforementioned bug and patch: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33794

@Fuco1 I'll defer to your experience but from my perspective it seems to be a regression because disabling post-self-insert-hook breaks a basic Emacs API to stop one finicky (buggy?) minor mode from breaking another minor mode.

Has there been any discussion of this regression on the Emacs mailing list?

[rileyrg]

Just adding a quick note for googleability here: smartparens not working in php-mode emacs 27. This worked for me:

https://github.com/Fuco1/smartparens/issues/963#issuecomment-488151756

[MatthewZMD]

Emacs 27 code cutoff already had happened. If this issue should be fixed by Emacs upstream, it should be done quick.

[hendrikweisser]

I'm currently trying Emacs 28.0.50 with @MatthewZMD's M-EMACS config. It looks like the bug reported here is no longer present, but the workaround will lead to double closing parens being inserted (as mentioned before for Emacs 26) if it's applied for this version.

[MatthewZMD]

I'm currently trying Emacs 28.0.50 with @MatthewZMD's M-EMACS config. It looks like the bug reported here is no longer present, but the workaround will lead to double closing parens being inserted (as mentioned before for Emacs 26) if it's applied for this version.

Thanks for letting me know, I verified that the workaround caused double closing parens insertion bug and it has now been removed from M-EMACS.

Maybe this issue can be closed too on the smartparens side?

[mjkramer]

In Emacs 27.0.60 (75a9eee8b) I also find that the workaround is no longer necessary and leads to double closing parens.