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: Fri, 21 Dec 2018 19:24:02 +0000 Message-ID: References: <20181221134829.29135.qmail@mail.muc.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000052db56057d8d31dc" X-Trace: blaine.gmane.org 1545423652 20244 195.159.176.226 (21 Dec 2018 20:20:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Dec 2018 20:20:52 +0000 (UTC) Cc: Alan Mackenzie , Stefan Monnier , 33794@debbugs.gnu.org To: bea@klebe.blog Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 21 21:20:47 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 1gaRHo-00057F-SI for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Dec 2018 21:20:46 +0100 Original-Received: from localhost ([::1]:47725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaRJv-0001oo-GD for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Dec 2018 15:22:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaRJe-0001oW-So for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 15:22:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gaRJZ-0007bY-T1 for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 15:22:38 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54573) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gaRJZ-0007bJ-Os; Fri, 21 Dec 2018 15:22:33 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gaQPu-00064i-3P; Fri, 21 Dec 2018 14:25: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: Fri, 21 Dec 2018 19:25: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.154542026223297 (code B ref 33794); Fri, 21 Dec 2018 19:25:02 +0000 Original-Received: (at 33794) by debbugs.gnu.org; 21 Dec 2018 19:24:22 +0000 Original-Received: from localhost ([127.0.0.1]:58805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaQPF-00063h-Oc for submit@debbugs.gnu.org; Fri, 21 Dec 2018 14:24:22 -0500 Original-Received: from mail-qt1-f182.google.com ([209.85.160.182]:40170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaQPE-00063T-Aj for 33794@debbugs.gnu.org; Fri, 21 Dec 2018 14:24:20 -0500 Original-Received: by mail-qt1-f182.google.com with SMTP id k12so6910833qtf.7 for <33794@debbugs.gnu.org>; Fri, 21 Dec 2018 11:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E9fI04p6v9RHYFcFWxNsgf7V5p3ghkdBsbcWbfkDpek=; b=i/yoSyPSCUM3kFN9EdPgZ2RXsCTVjqlcFBzGYmFH4fQzxJ7KJa3FqTavanaAdRJoLP wRof58sUjyWMWaRYi/asqjDUUjZk3lDfFjkKX+jjXLM4kgrPme+bW8hEFr1kKPUWoM+u gfCZCZN8cLI1KoAd/EdI8trpw7O9sKudIeJYQDg92rEHnUir9PRdDLoiQg4n6jo2iMxW QQpVs5BAhWpi1hmch2qQx4t8xsQHuwYJz0R0ZUkxjogkpqOvgPrKiDE1xlNqiaLiRXR5 iTT8RdIUuabBLVFGaKkwAmrVwjqU35qFUErm+447JGEjk4AEkT/3/AJMhbSp0DKxf72X +VFQ== 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:from:date :message-id:subject:to:cc; bh=E9fI04p6v9RHYFcFWxNsgf7V5p3ghkdBsbcWbfkDpek=; b=guk+s7sAdVbdsGnQyP6Mzuos1M4nle+veRn5cdA6haHBtqHQO2MvSh4+5H9fWoUvyG BFL53LHJy00KdYWGaI3UdMbofMpjUpVtB+Vl9fPDVwILz1//74vKU/awHT6yiRJtb2/h ya8pm/2R8uNqTO9AnSKOqZX3YO+SnmP+2diU1WlQVAFTkD8MRHL92OdCZ4O6jYpRmqgR pTheNNp9fsl4IExADaSjSDdiZ8RThFFqgCHwqPzZC5nov1AKKvWlCUIAux7PU+ayyWLc /saykbCyA1rMdHH//sItZFp6teq2ir45Wj6MekKHoyEEGEiC11VPGcbRhJr67vtj62cO 6o2A== X-Gm-Message-State: AA+aEWYGrLG2oiUG0u6+SzBSoLe2LHtKW7WzrlOz4gfEhabPJQgXGmfr Ivx1O4rwMjIazfSiE0hgttLEw47C8RJEb4UkFw88UQ== X-Google-Smtp-Source: ALg8bN5I27OqCsGNWMfMke8J0hdAWqR0rUQmcQg5sWsFc/IeTpP0njSLQ9OHD2pIKvmU5W5EuBNOFhcE65mm8Xis5PY= X-Received: by 2002:ac8:3e91:: with SMTP id y17mr3779916qtf.390.1545420254925; Fri, 21 Dec 2018 11:24:14 -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:153700 Archived-At: --00000000000052db56057d8d31dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable By the way, Stefan, this patch is only an idea, and maybe not a very good one since it may break backward compatibility in electric-layout-rules. After having seen Beatrix's link to your so answer, I see that two separate rules on two separate chars should also work for this. Jo=C3=A3o On Fri, Dec 21, 2018, 19:20 Jo=C3=A3o T=C3=A1vora Hi Beatrix, > > The solution I propose involves introducing the hotpatch I attached to fi= x > electric-layout-mode in your emacs, so I wouldn't expect it to work if yo= u > 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 searchin= g >> > > 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 bi= t >> > > 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, o= r >> > > 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 jus= t >> > 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 look= ed >> > 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 answe= r >> 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-matching >> > engine doesn't allow for it. The current solution seems to be goo= d >> > 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 >> recursively. >> > - ;; 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 >> inserting \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 >> recursively. >> > + ;; 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) >> > + >> (electric-pair-open-newline-between-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 befor= e >> inserting \n? >> > + (goto-char end))))))) >> > >> > (put 'electric-layout-post-self-insert-function 'priority 40) >> > >> > --00000000000052db56057d8d31dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
By the way, Stefan, this patch is only an idea, and maybe= not a very good one since it may break backward compatibility in electric-= layout-rules.=C2=A0 After having seen Beatrix's link to your so answer,= I see that two separate rules on two separate chars should also work for t= his.

Jo=C3=A3o

=
On Fri, Dec 21, 2018, 19:20 Jo= =C3=A3o T=C3=A1vora <joaotavora@= gmail.com wrote:
Hi Beatrix,

The= solution I propose involves introducing the hotpatch I attached to fix ele= ctric-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, elect= ric-pair-mode and electric-indent-mode, at least while we try to extend/fix= these modes to accommodate your needs.=C2=A0=C2=A0
=
After such a solution is evaluated, you can sel= ect to keep it or move to something else.

=
Jo=C3=A3o

On Fri, Dec 21= , 2018, 19:06 Beatrix Klebe <beeuhtricks@gmail.com wrote:
Here's the link, I believe it was Stef= an that answered it:
https://emacs.stackexchange.com/questions/2837/automatically-fo= rmatting-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
{
=C2=A0 =C2=A0 |

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() {
=C2=A0 =C2=A0 |
} // 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()
{
=C2=A0 =C2=A0 |
} // 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<= br> just recently gotten deeper into Emacs Lisp.

On Fri, Dec 21, 2018 at 1:49 PM Jo=C3=A3o T=C3=A1vora <joao= tavora@gmail.com> wrote:
>
> Beatrix Klebe <beeuhtricks@gmail.com> writes:<= br> >
> > I believe I saw your Stack Overflow answer about this while searc= hing
> > for the solution. electric-layout-mode works with some quirks, su= ch as
> > that if you put a space after parens in a function definition, th= e
> > 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 t= o get
> > auto-pairing of brackets with braces being placed where they shou= ld 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 functional= ity.
> > 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 jus= t
> have to report the bugs to the Emacs developers as efficiently as
> possible.
>
> 1. Though Alan possibly has already, I still cannot understand the
>=C2=A0 =C2=A0 original problem.=C2=A0 Can you start by describing what = the buffer looked
>=C2=A0 =C2=A0 like before, what you did, what it looked like afterwards= , and what
>=C2=A0 =C2=A0 you expected it to look like?=C2=A0 If possible start wit= h a clean Emacs
>=C2=A0 =C2=A0 -Q recpe.
>
> 2. I have experimented with nicer-playing like alternatives like
>=C2=A0 =C2=A0 electric-layout-mode.=C2=A0 I came across a few quirks my= self (though I'm
>=C2=A0 =C2=A0 not sure if they are the same as yours). So I prepared a = patch (in
>=C2=A0 =C2=A0 branch scratch/fix-33794-extend-electric-layout-mode) and= attached
>=C2=A0 =C2=A0 it after the sig.
>
> After loading this patch, in a simple Emacs -Q the configuration:
>
>=C2=A0 =C2=A0 (electric-pair-mode)
>=C2=A0 =C2=A0 (electric-layout-mode)
>
>=C2=A0 =C2=A0 (add-hook 'c-mode-hook
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(lambda ()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq-local electric-la= yout-rules
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0'((?\{ . after)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(?\{ . after-stay)))))
>
> And, when visiting a C file, if I press `{' I get the expected
> pair+layout+indent behaviour.=C2=A0 Sor example opening a brace after<= br> > int main () gives me:
>
>=C2=A0 =C2=A0 =C2=A0int main () {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cursor here>
>=C2=A0 =C2=A0 =C2=A0}
>
> 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 answe= r you
> mentioned?
>
> commit ab036bdedbb49ecc96d550b5e883e43bb03eaccc
> Author: Jo=C3=83=C2=A3o T=C3=83=C2=A1vora <joaotavora@= gmail.com>
> Date:=C2=A0 =C2=A0Fri Dec 21 18:00:08 2018 +0000
>
>=C2=A0 =C2=A0 =C2=A0Extend electric-layout-mode to handle more complex = layouts
>
>=C2=A0 =C2=A0 =C2=A0Also, have it play nice with electric-pair-mode. >
>=C2=A0 =C2=A0 =C2=A0Multiple matching entries in `electric-layout-rules= ' are executed in
>=C2=A0 =C2=A0 =C2=A0order of appearance.=C2=A0 When inserting a newline= in the 'after-stay
>=C2=A0 =C2=A0 =C2=A0rule, ensure electric-pair-open-newline-between-pai= rs is nil.
>
>=C2=A0 =C2=A0 =C2=A0Arguably the logic behind electric-pair-open-newlin= e-between-pairs
>=C2=A0 =C2=A0 =C2=A0should be moved to electric-layout-mode, but the cu= rrent rule-matching
>=C2=A0 =C2=A0 =C2=A0engine doesn't allow for it.=C2=A0 The current = solution seems to be good
>=C2=A0 =C2=A0 =C2=A0enough for the situations reported in bug#33794. >
>=C2=A0 =C2=A0 =C2=A0* lisp/electric.el (electric-layout-rules): Adjust = docstring.
>=C2=A0 =C2=A0 =C2=A0(electric-layout-post-self-insert-function): Loop t= hrough rules.=C2=A0 Bind
>=C2=A0 =C2=A0 =C2=A0electric-pair-open-newline-between-pairs to nil whe= n handling
>=C2=A0 =C2=A0 =C2=A0after-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
>
>=C2=A0 The symbols specify where in relation to CHAR the newline
>=C2=A0 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.")
>
>=C2=A0 (defun electric-layout-post-self-insert-function ()
> -=C2=A0 (let* ((rule (cdr (assq last-command-event electric-layout-rul= es)))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pos)
> -=C2=A0 =C2=A0 (when (and rule
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq pos (ele= ctric--after-char-pos))
> +=C2=A0 (let (pos)
> +=C2=A0 =C2=A0 (when (and (setq pos (electric--after-char-pos))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Not in= a string or comment.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(not (nth= 8 (save-excursion (syntax-ppss pos)))))
> -=C2=A0 =C2=A0 =C2=A0 (let ((end (point-marker))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (sym (if (functionp rule) (= funcall rule) rule)))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 (set-marker-insertion-type end (not (eq s= ym 'after-stay)))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 (goto-char pos)
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 (pcase sym
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; FIXME: we used `newline' do= wn here which called
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; self-insert-command and ran pos= t-self-insert-hook recursively.
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; It happened to make electric-in= dent-mode work automatically with
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; electric-layout-mode (at the co= st of re-indenting lines
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; multiple times), but I'm no= t sure it's what we want.
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;;
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; FIXME: check eolp before insert= ing \n?
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ('before (goto-char (1- pos)) = (skip-chars-backward " \t")
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= (unless (bolp) (insert "\n")))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ('after=C2=A0 (insert "\n= "))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ('after-stay (save-excursion > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(let ((electric-layout-rules nil))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0(newline 1 t))))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ('around (save-excursion
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0(goto-char (1- pos)) (skip-chars-backward " \t")
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0(unless (bolp) (insert "\n")))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= (insert "\n")))=C2=A0 =C2=A0 =C2=A0 ; FIXME: check eolp before in= serting \n?
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 (goto-char end)))))
> +=C2=A0 =C2=A0 =C2=A0 (goto-char pos)
> +=C2=A0 =C2=A0 =C2=A0 (dolist (rule electric-layout-rules)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 (when (eq last-command-event (car rule))<= br> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (let* ((end (point-marker))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(rule (= cdr rule))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(sym (i= f (functionp rule) (funcall rule) rule)))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (set-marker-insertion-type = end (not (eq sym 'after-stay)))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (pcase sym
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; FIXME: we used `n= ewline' down here which called
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; self-insert-comma= nd and ran post-self-insert-hook recursively.
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; It happened to ma= ke electric-indent-mode work automatically with
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; electric-layout-m= ode (at the cost of re-indenting lines
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; multiple times), = but I'm not sure it's what we want.
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; FIXME: check eolp= before inserting \n?
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ('before (goto-c= har (1- pos)) (skip-chars-backward " \t")
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0(unless (bolp) (insert "\n")))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ('after=C2=A0 (i= nsert "\n"))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ('after-stay (sa= ve-excursion
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((electric-layout-rules nil)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(electric-pair-open= -newline-between-pairs nil))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(newline 1 t))))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ('around (save-e= xcursion
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(goto-char (1- pos)) (skip-chars-backward " \t&qu= ot;)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(unless (bolp) (insert "\n")))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0(insert "\n")))=C2=A0 =C2=A0 =C2=A0 ; FIXME: check = eolp before inserting \n?
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (goto-char end)))))))
>
>=C2=A0 (put 'electric-layout-post-self-insert-function 'priorit= y=C2=A0 40)
>
--00000000000052db56057d8d31dc--