unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Beatrix Klebe <beeuhtricks@gmail.com>
To: "João Távora" <joaotavora@gmail.com>
Cc: Alan Mackenzie <acm@muc.de>, "Mx. Beatrix Klebe" <bea@klebe.blog>,
	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 14:43:41 -0500	[thread overview]
Message-ID: <CAH6apoY=WbD5Khcf=qDjfUAy10qy8PGdXjayEk_cqZa8ShbC+Q@mail.gmail.com> (raw)
In-Reply-To: <CALDnm5281d-pqq2rFmZQNQRiwonvh190M6NON1n0P0BYU-xLew@mail.gmail.com>

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.


On Fri, Dec 21, 2018 at 2:20 PM 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)
>> >





  parent reply	other threads:[~2018-12-21 19:43 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
2018-12-21 19:43                 ` Beatrix Klebe [this message]
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='CAH6apoY=WbD5Khcf=qDjfUAy10qy8PGdXjayEk_cqZa8ShbC+Q@mail.gmail.com' \
    --to=beeuhtricks@gmail.com \
    --cc=33794@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=bea@klebe.blog \
    --cc=joaotavora@gmail.com \
    --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).