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

[Alan Mackenzie]

On Sat, Dec 07, 2019 at 10:21:40 +0200, Eli Zaretskii wrote:
> > Date: Fri, 6 Dec 2019 22:24:59 +0000
> > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org
> > From: Alan Mackenzie <acm@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.

OK, sorry for the misunderstanding.  I was reasoning, subconsciously, on
the basis of justifying each function to remain on the hook.  Again,
subconsciously, I assumed you were doing the same.  If I move over to
justifying each function to be filtered out of the hook, things get a lot
easier.

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

>  . why is smie-blink-matching-open inapplicable?

The "simple-minded indentation engine" is not used in CC Mode.  But we
can leave it in the hook since it is harmless.

>  . 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?

blink-paren-function is bound to nil at the start of c-electric-brace and
c-electric-paren.  Otherwise, the paren blinking would happen
instantaneously after inserting the } or ), even though auto-newline may
still need to insert a NL before the } or ); this would be jarring for
the user.  c-electric-brace/paren instead call blink-paren-function
explicitly after any adjustments in the buffer have been made.

But leaving blink-paren-post-self-insert-function on the hook, although
it is redundant, will be harmless.

>  . 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?

These two functions never have any business in CC Mode, so I wanted to
exclude them from the hook for safety reasons.  If they somehow became
active, they might corrupt CC Mode's indentation or auto-newline mode.
But there is no immediately pressing reason to filter them out of the
hook.

>  . 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?

Thanks for the pointer.  This hook alters ASCII quotes to curly quotes,
but does so only in comments and strings.  It might corrupt code if a
user edits the code whilst it is commented out, or (in C++) "stringed
out" by a long raw string (yes, I have seen this happening).

So, I suppose we could say that any user who enables electric-quote-mode
and comments out code should be aware of what she is doing.  Although it
would not happen often, getting a curly quote into commented out code,
then uncommenting it, would be a difficult error to spot, with seemingly
non-sensensical compiler error messages.

But, thinking about it, there is no function `c-electric-quote', so
filtering out electric-quote-p-s-i-f will never have any effect on
anything.  So there is no point in doing so.

So, that would leave just electric-pair-post-self-insert-function to be
filtered out of the hook.

> > 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.

OK.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).