From unknown Wed Jun 18 23:11:11 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#55340 <55340@debbugs.gnu.org> To: bug#55340 <55340@debbugs.gnu.org> Subject: Status: electric-pair open newline Reply-To: bug#55340 <55340@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:11:11 +0000 retitle 55340 electric-pair open newline reassign 55340 emacs submitter 55340 Sam Halliday severity 55340 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon May 09 15:31:23 2022 Received: (at submit) by debbugs.gnu.org; 9 May 2022 19:31:23 +0000 Received: from localhost ([127.0.0.1]:59502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1no96J-0005oR-C4 for submit@debbugs.gnu.org; Mon, 09 May 2022 15:31:23 -0400 Received: from lists.gnu.org ([209.51.188.17]:46082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1no96H-0005oJ-Ke for submit@debbugs.gnu.org; Mon, 09 May 2022 15:31:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1no96H-0000fV-D5 for bug-gnu-emacs@gnu.org; Mon, 09 May 2022 15:31:21 -0400 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]:45738) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1no96F-0001Uu-L1 for bug-gnu-emacs@gnu.org; Mon, 09 May 2022 15:31:21 -0400 Received: by mail-ej1-x62a.google.com with SMTP id ch13so331137ejb.12 for ; Mon, 09 May 2022 12:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:mime-version; bh=p5yEiEjkKg9Angxk8Jn1ri9YvzzYD70dygvjbhfMf58=; b=ghI23YXFr1yTaRfrtsOiG5l4xt84sNYZYmxegfj7ytpTX4lxGa0RwyQGfnZCi4TIU2 s5xXXdFNQj98/HPD6rWEXziE0L8EILdJZYV+MVz9JavGjO6FKPrWejhGrnpbqLe1btzL wcAvp6BnX3MvNCtTHSHL87S1T+5cP0uuhCdWfJxFme6tPtIoMCJ6yhOLHxCvaBJPrTD+ iIkJ+lQYAX+qoNac4OwEgf1RbR5WUXtfXq2IQ7cL8U6Nu3GD9tJax6Wc9Lke68JUaAuB IHjVwN6rfnrqgi73oxfdoMaHeJM2m1DXtmWpFUA4781ilzurg1sD/7GO5E+FK0Rds8Ei XkEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=p5yEiEjkKg9Angxk8Jn1ri9YvzzYD70dygvjbhfMf58=; b=twK/wbdmdhopb8AZIUvWk9zMXVvCTFk6z67MLf27vgmAbMK/ARUpM1r0CabMjNiZdW R5Jx7SnKWruJDBe/a2pkMkqXG+mVaeHlzDwArmXRGVnfL54gjACGJWGhXXVTq/m4FABX E6eQb/BFltkVO+u+slHMl/4y3NurNlnJIIQRQRMgNfU6cLS4L0Uujv4wEOQRx98PFCpI W1ueJi5bclVSMAPqjtU7a3hxoOthUC1EXJP/QhrxODXZMxhs+HB4utI1edwT1nfi0UyD +9F0UpXnSmprT0bb+4xaQURgs5H3gC9gD9fOcHYuScRUCzohQTK6aoDZi0W1NZYRXiXQ N6+Q== X-Gm-Message-State: AOAM531lmeFURFl3xi4Y2YO0CBT9lSxZz5Y9D/bFIHo1qFIkmqdkabs1 LajLzoE+w/otnlRoIik8aaPqLU/WH50= X-Google-Smtp-Source: ABdhPJzlvQFt7Fb8rUVDj1yFxX3NCudm8UDyHmW6qwMoOSiXDCPFxiZiYblA+njSXGTdmmgKPWkCGQ== X-Received: by 2002:a17:907:16a8:b0:6f3:e9fc:29e7 with SMTP id hc40-20020a17090716a800b006f3e9fc29e7mr16419691ejc.428.1652124677622; Mon, 09 May 2022 12:31:17 -0700 (PDT) Received: from localhost ([2a00:23c6:c30b:5f00:9ee3:a2c6:362b:56a1]) by smtp.gmail.com with ESMTPSA id d23-20020aa7d697000000b0042617ba63absm6521156edr.53.2022.05.09.12.31.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 12:31:17 -0700 (PDT) From: Sam Halliday To: bug-gnu-emacs@gnu.org Subject: electric-pair open newline Date: Mon, 09 May 2022 20:35:12 +0100 Message-ID: <87k0auwlcf.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::62a; envelope-from=sam.halliday@gmail.com; helo=mail-ej1-x62a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain 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 --=-=-= Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --==-=-= Content-Type: text/plain --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARECADUWIQTrVS7VRt8l2pBJU9SHlDipUv0byQUCYnls8Bccc2FtLmhhbGxp ZGF5QGdtYWlsLmNvbQAKCRCHlDipUv0bySJ+AJ9STzNtGwf0+K4t725QYCW4omJm IwCfZ7N5Ga33zGzHb+p9P6qWkRWanrE= =+0+y -----END PGP SIGNATURE----- --==-=-=-- --=-=-=--