all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: yyoncho <yyoncho@gmail.com>
To: Alan Mackenzie <acm@muc.de>
Cc: 38406@debbugs.gnu.org
Subject: 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	[thread overview]
Message-ID: <CACCVLQWSXY5mMfcvinL0ZqeocoL6BK53OVdj9hKF6+OD7ZiNgg@mail.gmail.com> (raw)
In-Reply-To: <20191130143638.GA6716@ACM>

[-- Attachment #1: Type: text/plain, Size: 4039 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5164 bytes --]

  reply	other threads:[~2019-12-01 10:02 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27 20:00 bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes yyoncho
2019-11-30 14:36 ` Alan Mackenzie
2019-12-01 10:02   ` yyoncho [this message]
2019-12-01 15:07     ` Alan Mackenzie
2019-12-01 15:27       ` yyoncho
2019-12-01 15:58         ` Alan Mackenzie
2019-12-01 18:03           ` Eli Zaretskii
2019-12-02 18:37             ` Alan Mackenzie
2019-12-01 17:59       ` Eli Zaretskii
2019-12-01 19:27         ` Alan Mackenzie
2019-12-01 20:47           ` Eli Zaretskii
2019-12-02 18:31             ` Alan Mackenzie
2019-12-02 20:17               ` Eli Zaretskii
2019-12-04 20:41             ` Alan Mackenzie
2019-12-04 21:04               ` Dmitry Gutov
2019-12-05 19:14                 ` Alan Mackenzie
2019-12-05 20:44                   ` Dmitry Gutov
2019-12-05 14:45               ` Eli Zaretskii
2019-12-05 19:09                 ` Alan Mackenzie
2019-12-05 19:25                   ` Eli Zaretskii
2019-12-05 20:17                     ` Alan Mackenzie
2019-12-06  8:06                       ` Eli Zaretskii
2019-12-06 18:28                         ` Alan Mackenzie
2019-12-06 18:48                           ` Eli Zaretskii
2019-12-06 22:24                             ` Alan Mackenzie
2019-12-07  8:21                               ` Eli Zaretskii
2019-12-07 11:40                                 ` Alan Mackenzie
2019-12-07 13:27                                   ` Eli Zaretskii
2019-12-07 19:03                                     ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACCVLQWSXY5mMfcvinL0ZqeocoL6BK53OVdj9hKF6+OD7ZiNgg@mail.gmail.com \
    --to=yyoncho@gmail.com \
    --cc=38406@debbugs.gnu.org \
    --cc=acm@muc.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.