From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#33794: 26.1; electric-pair-mode breaks auto-newline minor mode of cc-mode Date: Sat, 22 Dec 2018 01:08:54 +0000 Message-ID: <87tvj68j15.fsf@gmail.com> References: <20181221134829.29135.qmail@mail.muc.de> 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 1545440967 12546 195.159.176.226 (22 Dec 2018 01:09:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 22 Dec 2018 01:09:27 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Alan Mackenzie , bea@klebe.blog, Stefan Monnier , 33794@debbugs.gnu.org To: Beatrix Klebe Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 22 02:09:22 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 1gaVn8-00038P-4U for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Dec 2018 02:09:22 +0100 Original-Received: from localhost ([::1]:49185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaVpE-0000XI-IF for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Dec 2018 20:11:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaVoL-0008Vz-Ms for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 20:10:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gaVo9-000309-9m for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 20:10:32 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54749) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gaVnm-0002Jn-80; Fri, 21 Dec 2018 20:10:08 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gaVnm-0008HI-1u; Fri, 21 Dec 2018 20:10:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sat, 22 Dec 2018 01:10: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.154544094631755 (code B ref 33794); Sat, 22 Dec 2018 01:10:02 +0000 Original-Received: (at 33794) by debbugs.gnu.org; 22 Dec 2018 01:09:06 +0000 Original-Received: from localhost ([127.0.0.1]:59007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaVms-0008G6-FQ for submit@debbugs.gnu.org; Fri, 21 Dec 2018 20:09:06 -0500 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:38872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaVmp-0008Fc-Vk for 33794@debbugs.gnu.org; Fri, 21 Dec 2018 20:09:04 -0500 Original-Received: by mail-wr1-f49.google.com with SMTP id v13so6935910wrw.5 for <33794@debbugs.gnu.org>; Fri, 21 Dec 2018 17:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=581E8+kM/qOdAxOb1kC0z9spzWR1dLLC76SnY7KgCj8=; b=Uwb8sI+Azea5z6i/jr/PCeShP+pFDbNdBfCLAqAMzDWNCYMUsAzMPMvbruLgzE4h4n hjwCPlZXqOtPW4h2dQ7WtpDM9wxpunh+oSqBLedm6qTLxCvWuJXlYUf84wcE14KDvPHL J/RCgIzPMummCO6JZmV4SxbLloesGDeKhBXIs4yhePa0Hag9J0AR3T4mVCnou6KKGnIY yKO7CMUZKi0+HkH7//azT3GkRCVEMwGx4iUs+2jmsjV1cz7+UFMnStp4RUKiHLVQ9ibm IaabcciBwHVLSheWPmnB+e7DDyNnjX+Dd7ThHUb/z2VQNaq46V/yrUG4EETVz58+D9XJ DPPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=581E8+kM/qOdAxOb1kC0z9spzWR1dLLC76SnY7KgCj8=; b=tTIIUxCnk0lHmDBXcT6d12W7O5+NBdf/Z9fXQrVMcXiFdqKtvCopt21m5vLisj6FR8 77EzeMefzJZaMz/Pk0hLH9qOFLndk4y1LrHG5puUo1xo2a1jMQAAh/mipvc2b1XNyN0j tIMNlFE5UjPr49yxxL3DGAznuN1V6/Mvgr1gT3LXStJqyl7JkLXTX9D1Y2q4KT1IRjEb dhlGcKRuaD6hw0uTnbXPXQPgBl7+GKjP5WuWaNYUmcZ+F51pWCyz5RaRQ5p3WkO+HwyB 6/EBpizzvBlkReREmBiDRY/F7+MYelTsrDF5JbhpiaRU+nwrq04ONK2waBnq0btwrnP4 8tsg== X-Gm-Message-State: AJcUukeABLMPdQclJj8oc5kAr/1Hfg9fkUllwnQONz0zHqI5d4VstapZ hScFYPCHO1GozoTxQo+DXf7Rc3GH X-Google-Smtp-Source: ALg8bN40OhJRV6Sj0gqQ+dJ1xwWVwKeH+Nlux7sNMLigzEpRfEGHP3ohDV1hFsL61QDoXXlBfYG0iw== X-Received: by 2002:adf:e8c1:: with SMTP id k1mr4299904wrn.104.1545440937828; Fri, 21 Dec 2018 17:08:57 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id c9sm16896797wmh.27.2018.12.21.17.08.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 21 Dec 2018 17:08:56 -0800 (PST) In-Reply-To: (Beatrix Klebe's message of "Fri, 21 Dec 2018 14:43:41 -0500") 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:153709 Archived-At: Beatrix Klebe writes: > I know how to do hotpaches but that doesn't appear to solve the > problem I'm having here, unless I've missed something. The problem is > with moving the opening bracket, not the insertion point. Beatrix, I think you may have missed the fact that I am suggesting alternatives that: * involve cc-mode, or one of its derived modes; * don't involve M-x c-toggle-auto-newline (turning on what you call auto-newline-mode); * involve turning on the global electric-layout-mode and a thin customization for it in the buffers where you think it's relevant (presumably cc-mode); * may involve multiple fixed/patched versions of lisp/electric.el as I understand your problem(s); As it stands, the last patch I sent you passes my only test which is this: given a file 33794.el which is just: (electric-pair-mode) (electric-layout-mode) =20=20=20=20 (add-hook 'c-mode-hook (lambda () (setq-local electric-layout-rules '((?\{ . after) (?\{ . after-stay))))) then running this from a shell: $ emacs -Q -l 33794.el something.c Opens a new c-mode buffer. Type 'int main ()' and then an opening brace. You should get: int main () { } Can you reproduce these results? If you can come up with more of these tests written in this or a similarly simple and exact manner it's easier for me to understand what's going on (it's also easier to write automated tests). Jo=C3=A3o > > > On Fri, Dec 21, 2018 at 2:20 PM Jo=C3=A3o T=C3=A1vora wrote: >> >> Hi Beatrix, >> >> The solution I propose involves introducing the hotpatch I attached >> to fix electric-layout-mode in your emacs, so I wouldn't expect it >> to work if you haven't done that. >> >> Do you know how to do it? >> >> Though Alan will probably suggest otherwise, I'd also steer away >> from c-specific functionality and keep to the triad >> electric-indent-mode, electric-pair-mode and electric-indent-mode, >> at least while we try to extend/fix these modes to accommodate your >> needs. >> >> After such a solution is evaluated, you can select to keep it or move to= something else. >> >> Jo=C3=A3o >> >> On Fri, Dec 21, 2018, 19:06 Beatrix Klebe >> >>> Here's the link, I believe it was Stefan that answered it: >>> https://emacs.stackexchange.com/questions/2837/automatically-formatting= -brackets/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 searchi= ng >>> > > 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 b= it >>> > > 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 functionalit= y. >>> > > 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 ju= st >>> > 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 loo= ked >>> > 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 answ= er you >>> > 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-mat= ching >>> > engine doesn't allow for it. The current solution seems to be go= od >>> > 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. = Bind >>> > 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 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)) >>> > - (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))))) >>> > + (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 r= ecursively. >>> > + ;; It happened to make electric-indent-mode work autom= atically with >>> > + ;; electric-layout-mode (at the cost of re-indenting l= ines >>> > + ;; 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-betwe= en-pairs nil)) >>> > + (newline 1 t)))) >>> > + ('around (save-excursion >>> > + (goto-char (1- pos)) (skip-chars-backward "= \t") >>> > + (unless (bolp) (insert "\n"))) >>> > + (insert "\n"))) ; FIXME: check eolp befo= re inserting \n? >>> > + (goto-char end))))))) >>> > >>> > (put 'electric-layout-post-self-insert-function 'priority 40) >>> >