GNU bug report logs - #55340
electric-pair open newline

Previous Next

Full log

View this message in rfc822 format

From: Sam Halliday <sam.halliday <at> gmail.com>
To: 55340 <at> debbugs.gnu.org
Subject: bug#55340: electric-pair open newline
Date: Mon, 09 May 2022 20:35:12 +0100

[Message part 1 (text/plain, inline)]

Hello Emacs maintainers,

I have noticed that `electric-pair-open-newline-between-pairs-psif' from
elec-mode.el (copied in its entirety here for convenience) uses
`newline' from simple.el

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun electric-pair-open-newline-between-pairs-psif ()
  "Honour `electric-pair-open-newline-between-pairs'.
Member of `post-self-insert-hook' if `electric-pair-mode' is on."
  (when (and (if (functionp electric-pair-open-newline-between-pairs)
                 (funcall electric-pair-open-newline-between-pairs)
               electric-pair-open-newline-between-pairs)
             (eq last-command-event ?\n)
             (< (1+ (point-min)) (point) (point-max))
             (eq (save-excursion
                   (skip-chars-backward "\t\s")
                   (char-before (1- (point))))
                 (matching-paren (char-after))))
    (save-excursion (newline 1 t))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

and that `newline' will behave differently if `electric-indent' is
enabled. However, this does not work as intended in at least golang and
scala modes.

Let's take an example. I would expect that entering curly brackets in
either language, then pressing RET (which for me is bound to
`newline-and-indent`), would result in the final brace being indented
and the line containing point (I'll use a caret) would also be indented,
in other words I would expect to see

  {
    ^
  }

but instead I see

  {
    ^
}

i.e. the final bracket is not indented. If I use `newline' rather than
`newline-and-indent' I see

  {
^
}

and the final bracket is still not indented, which seems to be the same
failure mode (I wanted to demonstrate that `newline-and-indent' is not
the culprit).

Digging into this in more detail, it seems that if I manually get into a
situation where my code looks like

  {
  }

(simulating a standalone call to `newline-and-indent')

or

  {
}

(simulating a standalone call to `newline')

with point preceeding the closing bracket in either case, and then
manually invoke `(newline 1 t)' with `electric-indent-mode' enabled,
then I (correctly!) get

  {
    _
  }

(underscore indicating the whitespace indentation level), the point is
still just before the final bracket (since it is not in a save
excursion).

To achieve the behaviour that I want, I must copy/paste
`electric-pair-open-newline-between-pairs-psif' and replace the call to
`newline' with a call to `newline-and-indent'.

It would be good to have an out of the box solution that does what I
wish because I believe the correctly indented closing bracket would be
the preferred behaviour for the vast majority of developers who are
using C-derived languages such as golang, Java and Scala.

In addition, I would like to have the option to be able to auto-indent
without having to enable electric-indent mode, as I don't tend to get
any value out of it (and I'd be in favour of it being turned off by
default! But that's a separate discussion).

-- 
Best regards,
Sam

[Message part 2 (text/plain, inline)]

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.