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

View this message in rfc822 format

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: bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes
Date: Sat, 07 Dec 2019 10:21:40 +0200

> Date: Fri, 6 Dec 2019 22:24:59 +0000
> Cc: yyoncho <at> gmail.com, 38406 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > If you already call that particular function explicitly, then calling
> > it one more time is indeed redundant.
> 
> No, it's not redundant.  It's positively harmful.

Agreed.

>   smie-blink-matching-open is inapplicable to CC Mode and just takes up
>   processor cycles.
> 
>   electric-pair-post-self-insert-function we've already discussed.
> 
>   blink-paren-post-self-insert-function would do nothing anyhow, since
>   blink-paren-function has been bound to nil - this is so that the actual
>   blinking doesn't occur until the newly inserted brace is at its final
>   position.
> 
>   electric-indent-post-self-insert-function is redundant and possibly
>   harmful.
> 
>   electric-layout-post-self-insert-function is undocumented, thus likely
>   to be harmful.  Its name suggests it is redundant.
> 
>   electric-quote-post-self-insert-function is undocumented, uncommented
>   and obscure.  It is safer not to risk running it.
> 
> Given that the mechanism for filtering post-self-insert-hook is there,
> why is there the resistance to filtering out redundant and effect-free
> functions?

Alan, I'm trying to do TRT here, but I cannot do everything by myself,
because that would mean I need to invest an inordinate amount of time
in each decision, and will never be able to catch up.  Please help me
with this particular task by providing more detailed information about
your reasons for filtering out each of the functions you want to
filter out.  You have evidently studied them, so you should know more
about them then shown above, and certainly more than I do.

In general, I'd like to leave any function that is not harmful in the
list unfiltered, even if calling it in this context is silly, or has
no effect, or is otherwise redundant.  Can you please humor me by
looking at the above list through these eyes, and trying to avoid your
apparent dislike for the whole idea while at that?  I really need your
help.

Specifically, I'd like the following questions answered, at the very
least:

 . why is smie-blink-matching-open inapplicable?
 . where and why is blink-paren-function bound to nil?  Your patch
   calls blink-paren-function explicitly -- does that mean calling
   blink-paren-post-self-insert-function will be redundant?
 . why do you think electric-indent-post-self-insert-function could be
   harmful?  If it's merely redundant, could we please call it here?
 . electric-layout-post-self-insert-function inserts newlines, and its
   documentation is in electric-layout-rules; the latter is nil by
   default and only used in js.el and octave.el -- why would it be
   harmful here?
 . electric-quote-post-self-insert-function replaces quote characters
   (see the doc string of electric-quote-mode); do you have specific
   reasons why calling it here could be harmful or risky?

> And how come functions without meaningful doc strings are allowed onto
> Emacs hooks?

Please, let's not try fix all of Emacs while working on this single
issue.  I agree that undocumented functions is not a good thing, but,
as shown above, documentation for what these functions do _is_
available nearby.

Thanks.

Previous Next

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