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 #11 received at 38406 <at> debbugs.gnu.org (full text, mbox):

From: yyoncho <yyoncho <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 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: Sun, 1 Dec 2019 12:02:56 +0200

[Message part 1 (text/plain, inline)]

Hi Alan,

> There are other possible "fixes", for example modifying these functions
> so that they don't use self-insert-command at all, but somehow I don't
> think that's what you want.

I don't think that the code that is implemented against the contract listed
in
the hook documentation should be rewritten. If electric stuff is so that
important and there is no way to disable it by default then at least a
function
to unbind the electric functionality the documentation of
post-self-insert-hook
should state: "Don't rely on this hook in cc derived modes because of
{implementation details}. If you still want to use post-self-insert-hook
disable
use {implementation details} to turn electric off."

Thanks,
Ivan


On Sat, Nov 30, 2019 at 4:36 PM Alan Mackenzie <acm <at> muc.de> wrote:

> Hello, Yyoncho.
>
> On Wed, Nov 27, 2019 at 22:00:26 +0200, yyoncho wrote:
> > As per post-self-insert-hook documentation.
>
> > > Hook run at the end of `self-insert-command'.
> > > This is run after inserting the character.
>
> Yes.  This is a problematic hook, since it is capable of disrupting the
> correct functionality of any Lisp program which uses
> self-insert-command.  This transpired in CC Mode, so to make
> c-electric-brace and friends work, the action of the hook was nullified.
>
> > This does not hold by default in cc-mode due to the following mapped by
> > default functions:
>
> > > (define-key c-mode-base-map "#"         'c-electric-pound)
> > > (define-key c-mode-base-map "{"         'c-electric-brace)
> > > (define-key c-mode-base-map "}"         'c-electric-brace)
> > > (define-key c-mode-base-map "/"         'c-electric-slash)
> > > (define-key c-mode-base-map "*"         'c-electric-star)
> > > (define-key c-mode-base-map ";"         'c-electric-semi&comma)
> > > (define-key c-mode-base-map ","         'c-electric-semi&comma)
> > > (define-key c-mode-base-map ":"         'c-electric-colon)
> > > (define-key c-mode-base-map "("         'c-electric-paren)
> > > (define-key c-mode-base-map ")"         'c-electric-paren)
>
> > All of these functions (or at least majority) contain the following
> lines:
>
> > > (let (post-self-insert-hook) ; Disable random functionality.
> > >      (self-insert-command (prefix-numeric-value arg)))
>
> Yes.  This was one way to get self-insert-function to perform its
> correct functionality, namely inserting exactly one copy of a typed key
> (or alternatively N copies when there's a prefix key).
>
> > Possible fixes:
>
> First question, what's the problem?  What do you want to do that the
> above mechanism hinders?
>
> > 1. Do not bind the functions by default.
>
> They are essential to the correct functioning of CC Mode.
>
> > 2. Rewrite them so they do not inhibit post-self-insert-hook functions.
>
> This is difficult.  If there were an easy way to do this, I would have
> done it.  Note that, from the point of view of a major mode,
> post-self-insert-hook is totally random functionality - it is a bit like
> a trojan horse.  The major mode has no way to control what it does, thus
> is unable to guarantee the major mode will work.
>
> There are other possible "fixes", for example modifying these functions
> so that they don't use self-insert-command at all, but somehow I don't
> think that's what you want.
>
> Another fix would be to specify restrictions on what one is allowed to
> do in this hook.  I would prefer this, but other people would object
> strongly.
>
> I would advise against using post-self-insert-hook, if you possibly can.
> after-change-functions may be a good alternative.  Maybe you can't.  So,
> again, what is it you're trying to do?
>
> > In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
> >  of 2019-11-23 built on kyoncho-H87-D3H
> > Repository revision: 8934762bb37273e6606097de92dcc2556456acd2
> > Repository branch: master
> > Windowing system distributor 'The X.Org Foundation', version
> 11.0.12001000
> > System Description: Linux Mint 19.1
>
> [ .... ]
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

[Message part 2 (text/html, inline)]

Previous Next

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