unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "João Távora" <joaotavora@gmail.com>, emacs-devel@gnu.org
Subject: Re: Fixing post-self-insert-hook.
Date: Sun, 19 Sep 2021 14:57:07 +0000	[thread overview]
Message-ID: <YUdPwz86Ubo33iNN@ACM> (raw)
In-Reply-To: <jwvee9k3f43.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Sun, Sep 19, 2021 at 08:59:59 -0400, Stefan Monnier wrote:
> >> My alternative suggestion, which I've offered now and then, over the
> >> years, is for you to study how cc-mode behaves when you bind the
> >> delimiter keys simply to 'self-insert-command' ....

> > You know full well that this is problematic.

> I can't speak for João, but no I don't.

OK, I'm telling you now it is problematic.

> >> and refrain from re-inventing 'electric-pair-mode' inside cc-mode.
> > I sometimes wonder if such a reimplementation inside CC Mode might have

> I don't understand the "might".  You do have such a "reimplementation"
> (and you even implemented it before `electric-*-mode`).

And we're now reduced to silly discussions about the precise meanings of
words.  There is no implementation of the electric pair mode
functionality in CC Mode.  There is a call to an unofficial function in
elec-pair.el which currently happens to work.  There is no better
interface available, and João seems determined that there won't be one.

> The difficulty you're facing is due to the face that contrary to all
> other major modes which used to have such features, ....

There were no other such modes.  Or were there?  Which modes at the time
had electric indentation, or auto newline?

> .... you decided to keep your implementation and try to make it
> interact correctly with `electric-*-mode`s.

More precisely, the difficulties were caused by electric-*-mode being
developed in such a way as to be incompatible with existing major modes,
in particular CC Mode modes.  Perhaps you might like to say something
about why you did this.  It is (at least in hindsight) obvious there
would be incompatibilities with CC Mode.

I don't recall there being any discussion on emacs-devel at the time
these electric-*-modes were being planned.  If there had been, the
friction which has happened since might well have been avoided.

So, why did you design these new modes in such an incompatible fashion?

It's perhaps worthwhile to come back to a main incompatibility
introduced, and that is the original topic of this thread,
post-self-insert-hook.  This broke self-insert-function, at least as
used in CC Mode.  This is what has forced the ugly workarounds on CC
Mode.  Again, the question why?

[ .... ]

> I understand your desire to preserve exactly the featureset you designed
> for CC-mode, ....

More the features introduced by Barry Warsaw, Martin Stjernholm and
their predecessors.  They're good features, not obsolete, and change for
change's sake is never something I've been keen on.

> .... rather than rely on the `electric-*-mode`s features which aren't
> exactly equivalent and aren't configured in the same way.

They're worse features, from CC Mode's point of view.  They're more
complicated, more fragmented (you yourself admitted to cross coupling
between the mechanisms of the different electric-*-modes), more
difficult to debug, and so on.  All this compared with a collection of
straightforwardly written commands, c-electric-brace and friends, which
just work, and have done for several decades, and would be exceptionally
easy to debug if that were ever needed.

> So you gave more importance to preserving compatibility with older
> Emacs/CC-mode, whereas I give more importance to harmonization of
> configuration and behavior across major modes.

If you really wanted such harmonization, why did you create these modes
with such gross incompatibilities with CC Mode?  Why didn't you discuss
these things with me or Martin Stjernholm first, so that we could have
developed things co-operatively rather than you going your own way and
trying to force the result on CC Mode?

> > been less work than all the email exchange with you trying to get
> > you to fix things.

> There is a simpler solution at hand.  You say it's "problematic", but
> all solutions have their downsides.

It's problematic, and anything but simple.

> >> I must be honest.  I don't really expect you arrive at that conclusion
> >> or even try that experiment.
> > No.  I have a user base to consider.

> Some of your user base would appreciate not having to do things
> differently in CC-modes than in other modes.

That's pure speculation.  Also speculation: CC Mode users appreciate not
having to report bugs for c-electric-brace.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2021-09-19 14:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17 19:37 Fixing post-self-insert-hook Alan Mackenzie
2021-09-17 20:04 ` Stefan Monnier
2021-09-17 20:53   ` Alan Mackenzie
2021-09-17 21:45     ` João Távora
2021-09-18  6:08       ` tomas
2021-09-18  8:44         ` João Távora
2021-09-18 14:15     ` Stefan Monnier
2021-09-18 15:56       ` Alan Mackenzie
2021-09-18 18:03         ` Stefan Monnier
     [not found]         ` <CALDnm52z_8HyqdC92nrMgzOMOOq48h2MQ4pjbROBOsdm5N_cJg@mail.gmail.com>
2021-09-18 22:55           ` João Távora
2021-09-19 12:14             ` Alan Mackenzie
2021-09-19 12:36               ` João Távora
2021-09-19 12:59               ` Stefan Monnier
2021-09-19 14:57                 ` Alan Mackenzie [this message]
2021-09-19 20:20                   ` Stefan Monnier
2021-09-17 20:15 ` João Távora
2021-09-17 20:35   ` Alan Mackenzie
2021-09-17 20:48     ` João Távora
2021-09-18  5:59     ` Eli Zaretskii
2021-09-18  9:41       ` Alan Mackenzie
2021-09-18  5:50 ` Eli Zaretskii
2021-09-18  9:57   ` Alan Mackenzie
2021-09-18 11:04     ` Eli Zaretskii

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=YUdPwz86Ubo33iNN@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --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).