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

Previous Next

Full log

Message #59 received at 38406 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: yyoncho <at> gmail.com, 38406 <at> debbugs.gnu.org
Subject: Re: bug#38406: 27.0.50; post-self-insert-hook does not hold its
 contract in cc-mode derived modes
Date: Thu, 05 Dec 2019 21:25:14 +0200

> Date: Thu, 5 Dec 2019 19:09:51 +0000
> Cc: yyoncho <at> gmail.com, 38406 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> 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.  If the user or Lisp set up these hooks such that they end
up shooting themselves in the foot, we should let them.  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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.