From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Beatrix Klebe Newsgroups: gmane.emacs.bugs Subject: bug#33794: 26.1; electric-pair-mode breaks auto-newline minor mode of cc-mode Date: Fri, 21 Dec 2018 14:06:34 -0500 Message-ID: References: <20181221134829.29135.qmail@mail.muc.de> Reply-To: bea@klebe.blog NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1545419117 20762 195.159.176.226 (21 Dec 2018 19:05:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Dec 2018 19:05:17 +0000 (UTC) Cc: Alan Mackenzie , "Mx. Beatrix Klebe" , Stefan Monnier , 33794@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 21 20:05:12 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaQ6g-0005Gu-VI for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Dec 2018 20:05:11 +0100 Original-Received: from localhost ([::1]:47323 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaQ8n-0004Li-N2 for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Dec 2018 14:07:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaQ8g-0004LS-Ct for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 14:07:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gaQ8a-0002eh-2h for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 14:07:12 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54532) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gaQ8U-0002ZG-M9; Fri, 21 Dec 2018 14:07:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gaQ8U-0005eD-A5; Fri, 21 Dec 2018 14:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Beatrix Klebe Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Fri, 21 Dec 2018 19:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33794 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 33794-submit@debbugs.gnu.org id=B33794.154541921321695 (code B ref 33794); Fri, 21 Dec 2018 19:07:02 +0000 Original-Received: (at 33794) by debbugs.gnu.org; 21 Dec 2018 19:06:53 +0000 Original-Received: from localhost ([127.0.0.1]:58790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaQ8K-0005dr-WF for submit@debbugs.gnu.org; Fri, 21 Dec 2018 14:06:53 -0500 Original-Received: from mail-oi1-f172.google.com ([209.85.167.172]:43337) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaQ8I-0005da-Tm for 33794@debbugs.gnu.org; Fri, 21 Dec 2018 14:06:51 -0500 Original-Received: by mail-oi1-f172.google.com with SMTP id u18so5595647oie.10 for <33794@debbugs.gnu.org>; Fri, 21 Dec 2018 11:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=255PxEUP1HzE41Vq0L+cWpALLQ8Oup2+0ycfq2Ckw08=; b=dywRS+UMKIDbIljMe3z93EUmhrlbLPZsNE7qAGOb63hUTs97cMYcdvdhCdUGjUCSc4 3l8/+TnhQpfJVpAMv4He5MMPhgeWPQNxT6+TTj/ASJcVSzSiw3UDhqiK6qpdzE/G77sU A9PVbIvm2ATyaczMq3iaczbLNKZqZk2ZIvbzrviwaM3ODGpQ3yALXNMeLR0OHBhgAFzO HKKLH3jZakFhNwORjrxRLqjRmVuMXyOL4KG8Kj5wxWyNjWcf4ecIXmuc3b0ukN6Wp0oJ WrwynrhY3MXYUqefz7qjrIdzg5a+ZOYjbeQYPFNb0Pl7pWEVN9TNruQNAksc+vAFuUC5 vzZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=255PxEUP1HzE41Vq0L+cWpALLQ8Oup2+0ycfq2Ckw08=; b=HYmhf6sQCZhPSxF4lfn8jSGy68tQzT1u0EzQd5LeWe24SurXlfdggGFTDteMkfzq50 XIbyUyY5r6C4vpK8yGacQoQhIuU63TDqeUJtY1wb1y4iKSQZNhp7Zb4NKWHStsC1DO/1 g/47SAzoK+tTvOICyP2sehY5N6Fm42yXuB0cz68KrgK2Tsc0h3NAZMgnrb1ktBbHSvsV ATdsMGhIOv1LeORuPwPmOIr4oINc0COcx5hfkHIEEXlrGjeMkzqZzRPy4MQ0tNgaLneB ho3W5JrRpyTi8mv6c79ZFUHxcTQFUzi3pWp1vH61KkM2x49McADb4UovEiXCfsF1qZpP MHTA== X-Gm-Message-State: AA+aEWZp/6p2KYg2VUq2SYS1M/2fxLcfrAKzwKTMVZbEIJl3pOmtPPag 3fMIhOqqBbRcQhaLHw/OzwZoRgYNGnsnNOiGODQ= X-Google-Smtp-Source: AFSGD/UAIioC/GSZX9WctxKdA0jCHll8ySC+YwEVr2GAWs4OCxFeRQEaqvxej9H1A0VnuupLWxc8o4chDIJo1I6TLM0= X-Received: by 2002:aca:f18:: with SMTP id 24mr2064925oip.310.1545419205003; Fri, 21 Dec 2018 11:06:45 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:153695 Archived-At: Here's the link, I believe it was Stefan that answered it: https://emacs.stackexchange.com/questions/2837/automatically-formatting-bra= ckets/2853#2853 I have tried this with emacs -Q and it does not fix the issue, which is as follows. Ordinarily in cc-mode when you have auto-newline-mode activated, and as far as I can tell, a cc-mode configuration that supports it, (which csharp-mode contains), the following happens when opening a block (pipe is the cursor): void Main() {| // opening bracket is typed becomes void Main { | when c-toggle-auto-newline is activated. However, if you also want your braces automatically paired, with electric-pair-mode, instead the following occurs: void Main() {| // opening bracket is typed void Main() {|} // electric-pair-mode closes the open bracket, but auto-newline-mode does not appear to do anything. void Main() { | } // user hits return, inserting the cursor at the correct indent level, but leaving the opening brace where it is. The ideal/desired behavior is: void Main() {| // opening bracket is typed void Main() { | } // user hits return key, electric-pair-mode pairs up the brackets, and auto-newline-mode formats the braces correctly It would also probably suffice to format with the newline before hitting enter as well, although I think I prefer hitting enter to open the block. I'm quite curious as to the internals of these formatting systems and would be happy to help with a fix/feature if that would be desired, I am mostly an OCaml programmer but C# is my day job and I've just recently gotten deeper into Emacs Lisp. On Fri, Dec 21, 2018 at 1:49 PM Jo=C3=A3o T=C3=A1vora wrote: > > Beatrix Klebe writes: > > > I believe I saw your Stack Overflow answer about this while searching > > for the solution. electric-layout-mode works with some quirks, such as > > that if you put a space after parens in a function definition, the > > space gets carried on to the newline with that method, which is a bit > > annoying. What would be ideal, and what I'm looking for, is to get > > auto-pairing of brackets with braces being placed where they should be > > automatically and the insertion point getting put in between them at > > the correct indent level, such as what happens with Visual Studio, or > > Visual Studio Code, or several other editors with this functionality. > > Perhaps it is not emacslike to have such behavior be totally > > automated, but I am used to it and finds it decreases my ordinary > > levels of frustration when working with verbose and imperative > > languages. I am currently trying to write some insert specifiers for > > smartparens to do this, but it is proving more difficult to find an > > elegant solution than I had expected. > > It is quite emacslike (though maybe not activated by default): you just > have to report the bugs to the Emacs developers as efficiently as > possible. > > 1. Though Alan possibly has already, I still cannot understand the > original problem. Can you start by describing what the buffer looked > like before, what you did, what it looked like afterwards, and what > you expected it to look like? If possible start with a clean Emacs > -Q recpe. > > 2. I have experimented with nicer-playing like alternatives like > electric-layout-mode. I came across a few quirks myself (though I'm > not sure if they are the same as yours). So I prepared a patch (in > branch scratch/fix-33794-extend-electric-layout-mode) and attached > it after the sig. > > After loading this patch, in a simple Emacs -Q the configuration: > > (electric-pair-mode) > (electric-layout-mode) > > (add-hook 'c-mode-hook > (lambda () > (setq-local electric-layout-rules > '((?\{ . after) > (?\{ . after-stay))))) > > And, when visiting a C file, if I press `{' I get the expected > pair+layout+indent behaviour. Sor example opening a brace after > int main () gives me: > > int main () { > > } > > I, like Stefan, think cc-mode could/should set electric-layout-rules > buffer-locally to reflect whatever c-style the user has selected. > > Thanks, > Jo=C3=A3o > > PS: Also, can you link to the the relevant to the stack overflow answer y= ou > mentioned? > > commit ab036bdedbb49ecc96d550b5e883e43bb03eaccc > Author: Jo=C3=83=C2=A3o T=C3=83=C2=A1vora > Date: Fri Dec 21 18:00:08 2018 +0000 > > Extend electric-layout-mode to handle more complex layouts > > Also, have it play nice with electric-pair-mode. > > Multiple matching entries in `electric-layout-rules' are executed in > order of appearance. When inserting a newline in the 'after-stay > rule, ensure electric-pair-open-newline-between-pairs is nil. > > Arguably the logic behind electric-pair-open-newline-between-pairs > should be moved to electric-layout-mode, but the current rule-matchin= g > engine doesn't allow for it. The current solution seems to be good > enough for the situations reported in bug#33794. > > * lisp/electric.el (electric-layout-rules): Adjust docstring. > (electric-layout-post-self-insert-function): Loop through rules. Bin= d > electric-pair-open-newline-between-pairs to nil when handling > after-stay. > > diff --git a/lisp/electric.el b/lisp/electric.el > index 6dbf46b80c..6a307a49b9 100644 > --- a/lisp/electric.el > +++ b/lisp/electric.el > @@ -370,38 +370,43 @@ electric-layout-rules > > The symbols specify where in relation to CHAR the newline > character(s) should be inserted. `after-stay' means insert a > -newline after CHAR but stay in the same place.") > +newline after CHAR but stay in the same place. > + > +If multiple rules match, they are all executed in order of > +appearance.") > > (defun electric-layout-post-self-insert-function () > - (let* ((rule (cdr (assq last-command-event electric-layout-rules))) > - pos) > - (when (and rule > - (setq pos (electric--after-char-pos)) > + (let (pos) > + (when (and (setq pos (electric--after-char-pos)) > ;; Not in a string or comment. > (not (nth 8 (save-excursion (syntax-ppss pos))))) > - (let ((end (point-marker)) > - (sym (if (functionp rule) (funcall rule) rule))) > - (set-marker-insertion-type end (not (eq sym 'after-stay))) > - (goto-char pos) > - (pcase sym > - ;; FIXME: we used `newline' down here which called > - ;; self-insert-command and ran post-self-insert-hook recursive= ly. > - ;; It happened to make electric-indent-mode work automatically= with > - ;; electric-layout-mode (at the cost of re-indenting lines > - ;; multiple times), but I'm not sure it's what we want. > - ;; > - ;; FIXME: check eolp before inserting \n? > - ('before (goto-char (1- pos)) (skip-chars-backward " \t") > - (unless (bolp) (insert "\n"))) > - ('after (insert "\n")) > - ('after-stay (save-excursion > - (let ((electric-layout-rules nil)) > - (newline 1 t)))) > - ('around (save-excursion > - (goto-char (1- pos)) (skip-chars-backward " \t") > - (unless (bolp) (insert "\n"))) > - (insert "\n"))) ; FIXME: check eolp before inser= ting \n? > - (goto-char end))))) > + (goto-char pos) > + (dolist (rule electric-layout-rules) > + (when (eq last-command-event (car rule)) > + (let* ((end (point-marker)) > + (rule (cdr rule)) > + (sym (if (functionp rule) (funcall rule) rule))) > + (set-marker-insertion-type end (not (eq sym 'after-stay))) > + (pcase sym > + ;; FIXME: we used `newline' down here which called > + ;; self-insert-command and ran post-self-insert-hook recur= sively. > + ;; It happened to make electric-indent-mode work automatic= ally with > + ;; electric-layout-mode (at the cost of re-indenting lines > + ;; multiple times), but I'm not sure it's what we want. > + ;; > + ;; FIXME: check eolp before inserting \n? > + ('before (goto-char (1- pos)) (skip-chars-backward " \t") > + (unless (bolp) (insert "\n"))) > + ('after (insert "\n")) > + ('after-stay (save-excursion > + (let ((electric-layout-rules nil) > + (electric-pair-open-newline-between-p= airs nil)) > + (newline 1 t)))) > + ('around (save-excursion > + (goto-char (1- pos)) (skip-chars-backward " \t"= ) > + (unless (bolp) (insert "\n"))) > + (insert "\n"))) ; FIXME: check eolp before i= nserting \n? > + (goto-char end))))))) > > (put 'electric-layout-post-self-insert-function 'priority 40) >