unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "João Távora" <joaotavora@gmail.com>
Cc: 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: Sat, 22 Dec 2018 10:20:11 +0000	[thread overview]
Message-ID: <20181222102011.GA3935@ACM> (raw)
In-Reply-To: <87y38iqti7.fsf@gmail.com>

Hello, João

On Sat, Dec 22, 2018 at 00:45:20 +0000, João Távora wrote:

> Hi Alan,

> I will be replying to the two emails you sent me in this single message.

> Alan Mackenzie <acm@muc.de> writes:

> > No, not at all.  CC Mode has been working for several decades, and works
> > well.  electric-pair-mode is the new kid on the block, just a few years
> > old, and was apparently hacked together without regard to some well
> > established conventions.  It should have provided interfaces to allow
> > existing software to connect to it - for example a variable to contain a
> > function to insert the electric character, or something like that.
> > Maybe.  It should have been considered, but apparently wasn't.

> First, I think you'll agree that antiquity is a poor measure of the
> merits of software.

Here we have antiquity, combined with software actually being used
combined with a lack of bugs.  (I'm talking about CC Mode's auto-newline
facility, here).  This SW is good.

> Here's a characteristic of electric-pair-mode that I think is an
> actual merit: it works for every mode in Emacs..

This clearly isn't true at the moment.  Have you tested it with, for
example, Cperl Mode, or Vera Mode?  That characteristic is an
aspiration, which is laudable.

> Also, I don't know if you understand the history of electric-pair-mode.
> It has two generations: One, before 24.4, which I believe Stefan wrote,
> where it was a simpler mode to automatically insert parenthesis and
> quotes as described in electric-pair-pairs.  Then, in 24.4, I borrowed
> code from my reasonably popular autopair.el extension and e-p-m became a
> mode that automatically infers what characters to pair from the syntax
> table of each mode.  Furthermore, in the new version, it also makes
> educated guesses about when to pair or when not to pair based, again on
> the information collected from the buffer and its syntax table by
> syntax-ppss.

I think that what is missing from this history is the stage where the
idea with proposed solution is first discussed on emacs-devel, where
conceptual problems can be identified and resolved.  As a result, e-p-m
is only compatible with some major modes; it is incompatible with those
that explicitly call self-insert-function as part of a command bound to
a key which is usually self-inserting.  There are quite a few such
modes.

> The use of post-self-insert-hook was a requirement at the time, since
> that is how the pre-24.4 electric-pair-mode, electric-indent-mode and
> electric-layout-mode already worked.  I welcomed this requirement, and
> it was what encouraged me to kill autopair.el and migrate to the new
> framework, since in autopair.el I had to rebind the parenthesis keys,
> which is akward (much like c-electric-brace and c-electric-paren are
> akward IMO).  This simplified the code tremendously.

Have a look at the doc string for self-insert-command, and ask yourself
what should happen on this call:

    (self-insert-command 1 &{)

.  The answer is, of course, that "{" should be inserted into the
buffer.  With electric-pair-mode-enabled, what actually happens is that
"{}" gets inserted instead.  This is broken.  I ask you to consider this
paragraph very carefully rather than reacting emotionally against it.
self-insert-command is broken, and this is the cause of the current bug.

What you seem to be suggesting is that rather than fix this breakage,
major modes like CC Mode (and there are quite a few) should have to work
around it.

> So these "well established conventions" are, with all due respect,
> nothing more than personal opinions based on a narrow experience with a
> subset of modes (maybe "mode" singular), tried and tested as it may be.

> If I abandon the post-self-insert-hook convention for e-p-m, I'll
> probably be breaking the e-p-m interaction with electric-indent-mode,
> electric-layout-mode, etc.  If there are existing problems with these
> interactions they should be fixed, but I will not fix e-p-m for
> interaction a specific part of cc-mode, unless you provide
> retro-compatible fix that guarantees existing behaviour outside cc-mode.

Again, you're much more familiar with electric-indent-mode, and friends.
Do they also break self-insert-command?

> I would rather declare e-p-m incompatible with that part of cc-mode and
> invest some time in providing alternatives based on
> electric-layout-mode, fixing Beatrix's problem by replacing bits of
> cc-mode-specific initialization in her init file with bits that works
> for all modes, including cc-mode.

You're trying to replace core CC Mode functionality.  Trying to do that
with a few quick hacks can only lead to frustration all round, and to
tears.

electric-layout-mode is incompatible with CC Mode.  This would have come
up in the discussion on emacs-devel and a resolution found if that
discussion had taken place.  Sadly it didn't, hence the incompatibility.
The same applies to electric-pair-mode.  We're having that discussion
now, sort of.

In CC Mode (and Cperl Mode, and Vera Mode,....), on insertion of a {,
the processing associated with the insertion needs to be allowed to
complete before the insertion of the mating }.  Above all,
self-insert-command needs to behave correctly, according to its
documentation.  It is surely not beyond us to fix these problems.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2018-12-22 10:20 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
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 [this message]
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=20181222102011.GA3935@ACM \
    --to=acm@muc.de \
    --cc=33794@debbugs.gnu.org \
    --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).