bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes

[Alan Mackenzie]

Hello, Eli.

On Thu, Dec 05, 2019 at 21:25:14 +0200, Eli Zaretskii wrote:
> > Date: Thu, 5 Dec 2019 19:09:51 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Can you explain why you exempt these from being called from CC Mode?

> > There is already a call to the matching-paren blink functionality in
> > cc-cmds.el, which must stay for older Emacsen.  If blink-paren-p-s-i-f
> > was allowed to run too, the result would probably be a doubling of the
> > blink time.  This is not desirable.  The same applies to smie-blink-m-o,
> > which in any case will not be used for CC Mode.

> > electric-pair-post-self-insert-function must not run in
> > c-electric-brace/paren except as carefully coded in these functions
> > explicitly; it would otherwise foul things up, one way or another, as it
> > did in the scenario for which bug #33794 was raised.

> > Of the other three electric-* functions, only one has a complete doc
> > string, so it is work to work out what the other two do.
> > electric-indent-post-self-insert-function is redundant in CC Mode, and
> > probably harmful.  At best it will just take up processor cycles.  I
> > believe electric-layout-p-s-i-f just duplicates the auto-newline
> > behaviour of the c-electric-* functions, making it redundant.  I don't
> > know exactly what electric-quote-p-s-i-f does, but it is likely to be
> > something to do with quotes, and thus likely to clash with CC Mode's
> > handling of quotes.

> I don't think CC Mode should protect users of those hooks from
> themselves.

It doesn't.  Ivan's hook functions will now get called.

> If the user or Lisp set up these hooks such that they end up shooting
> themselves in the foot, we should let them.

It's not a matter of what users might do.  It's about what Emacs
maintainers have already done.  The current changes to CC Mode are to
protect users of CC Mode from these design clashes inside Emacs.

> We never provide any "safety nets" for silly hook functions, so we
> shouldn't do that here as well.  OTOH, if someone puts a function on
> those hooks which does something legitimate, we should meet their
> expectations and let those functions run, as the contract says.

I think that, with my latest patch, that is the case.

> So I think you shouldn't filter anything from the hook before you run
> it.

I thought you were urging me to do precisely that two or three posts ago.

I just tried taking a particular function off of
c--unsafe-post-self-insert-hook-functions and enabling electric-pair
mode.  On typing a brace, electric-pair-mode threw an obscure error.  It
doesn't make sense to call electric-pair-post-self-insert-function twice
for one keypress.  That is a good reason for having that function
filtered out of the hook.  For the other five filtered out functions, I
gave what I think were good reasons in my last post.

The root of the problem is the hook post-self-insert-hook.  It is a
thoroughly bad idea.  The implications of introducing it a few years ago
weren't thought through.  Assuming that removing this hook from Emacs
isn't an option, we are left with ugly ad-hoc workarounds, such as the
patch we're currently discussing.

-- 
Alan Mackenzie (Nuremberg, Germany).