unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: bea@klebe.blog
Cc: Alan Mackenzie <acm@muc.de>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	33794@debbugs.gnu.org
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	[thread overview]
Message-ID: <CALDnm50bcRWd1V4vNfYC+9TBSMcKDRg=-GPce9bUp4ruuH515Q@mail.gmail.com> (raw)
In-Reply-To: <CALDnm5281d-pqq2rFmZQNQRiwonvh190M6NON1n0P0BYU-xLew@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 11050 bytes --]

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ão

On Fri, Dec 21, 2018, 19:20 João Távora <joaotavora@gmail.com 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ão
>
> On Fri, Dec 21, 2018, 19:06 Beatrix Klebe <beeuhtricks@gmail.com wrote:
>
>> 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ão Távora <joaotavora@gmail.com> wrote:
>> >
>> > Beatrix Klebe <beeuhtricks@gmail.com> 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 () {
>> >         <cursor here>
>> >     }
>> >
>> > 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ão
>> >
>> > PS: Also, can you link to the the relevant to the stack overflow answer
>> you
>> > mentioned?
>> >
>> > commit ab036bdedbb49ecc96d550b5e883e43bb03eaccc
>> > Author: João Távora <joaotavora@gmail.com>
>> > 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 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.
>> 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 before
>> inserting \n?
>> > +            (goto-char end)))))))
>> >
>> >  (put 'electric-layout-post-self-insert-function 'priority  40)
>> >
>>
>

[-- Attachment #2: Type: text/html, Size: 13841 bytes --]

  reply	other threads:[~2018-12-21 19:24 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18 17:38 bug#33794: 26.1; electric-pair-mode breaks auto-newline minor mode of cc-mode Beatrix Klebe
     [not found] ` <mailman.5894.1545155289.1284.bug-gnu-emacs@gnu.org>
2018-12-21 13:48   ` Alan Mackenzie
2018-12-21 13:57     ` João Távora
2018-12-21 14:12       ` Stefan Monnier
2018-12-21 16:00         ` Beatrix Klebe
2018-12-21 18:49           ` João Távora
2018-12-21 19:06             ` Beatrix Klebe
2018-12-21 19:20               ` João Távora
2018-12-21 19:24                 ` João Távora [this message]
2018-12-21 19:43                 ` Beatrix Klebe
2018-12-22  1:08                   ` João Távora
2018-12-22  2:16                     ` João Távora
2018-12-22  2:41                       ` Alan Mackenzie
2018-12-22  3:22                         ` João Távora
2018-12-22  4:41                           ` Beatrix Klebe
2018-12-22 10:02                             ` João Távora
2018-12-22 12:33                           ` Alan Mackenzie
2019-01-01 19:27           ` Alan Mackenzie
2019-01-15 16:10             ` Alan Mackenzie
2018-12-21 20:11         ` Alan Mackenzie
2018-12-22  0:45           ` João Távora
2018-12-22 10:20             ` Alan Mackenzie
2018-12-22 13:47               ` João Távora
2018-12-21 21:50       ` Alan Mackenzie
2018-12-22 16:22         ` Stefan Monnier
2018-12-22 16:34           ` Beatrix Klebe
2018-12-22 17:12             ` Stefan Monnier
2018-12-22 17:34               ` Beatrix Klebe
2018-12-22 21:19                 ` João Távora
2018-12-22 22:15                   ` Alan Mackenzie
2018-12-22 22:55                     ` João Távora
2018-12-23 20:21                       ` Alan Mackenzie
     [not found]                       ` <20181223202143.GA6658@ACM>
2018-12-23 21:38                         ` João Távora
2018-12-23 21:46                           ` Alan Mackenzie
2018-12-28 12:44                           ` Alan Mackenzie
2018-12-23 14:43                     ` Stefan Monnier
2018-12-23 14:48   ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALDnm50bcRWd1V4vNfYC+9TBSMcKDRg=-GPce9bUp4ruuH515Q@mail.gmail.com' \
    --to=joaotavora@gmail.com \
    --cc=33794@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=bea@klebe.blog \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).