From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sam Halliday Newsgroups: gmane.emacs.bugs Subject: bug#55340: 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="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20184"; mail-complaints-to="usenet@ciao.gmane.io" To: 55340@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 09 21:32:14 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1no978-00058m-H3 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 09 May 2022 21:32:14 +0200 Original-Received: from localhost ([::1]:37068 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1no977-0000kc-5x for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 09 May 2022 15:32:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38924) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1no96w-0000kT-Dw for bug-gnu-emacs@gnu.org; Mon, 09 May 2022 15:32:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37372) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1no96w-0001bo-5L for bug-gnu-emacs@gnu.org; Mon, 09 May 2022 15:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1no96w-0005pR-2y for bug-gnu-emacs@gnu.org; Mon, 09 May 2022 15:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sam Halliday Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 May 2022 19:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 55340 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.165212468322351 (code B ref -1); Mon, 09 May 2022 19:32:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 9 May 2022 19:31:23 +0000 Original-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 Original-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 Original-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 Original-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 Original-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) Original-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) 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:231781 Archived-At: --=-=-= 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----- --==-=-=-- --=-=-=--