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

Hello, Ivan.

On Sun, Dec 01, 2019 at 12:02:56 +0200, yyoncho wrote:
> 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."

The problem you have stumbled over is more of a political problem than a
technical one.

post-self-insert-hook was introduced relatively recently as a quick and
dirty method of doing certain things.  Its implications weren't thought
through beforehand.  In particular, it breaks major modes which use
self-insert-command as part of their processing, including CC Mode.

If functions put onto post-self-insert-hook didn't violate the
definition of self-insert-command (inserting exactly one copy of the key
typed), there wouldn't be a problem.  An example of such a function is
blink-paren-post-self-insert-function (see lisp/simple.el L7801).

However, there are several functions put onto this hook that make
extensive buffer changes.  An example is
electric-pair-post-self-insert-function (in lisp/elec-pair.el).  These
mess up self-insert-command, and violate the principle that major modes
should be in charge of what text goes where in a window.

People like using post-self-insert-hook without worrying about the
problems it causes.  Binding post-self-insert-hook to nil in CC Mode,
while not good, was a pragmatic workaround from around a year ago.  This
allowed electric-pair-mode to function in CC Mode.  As I said, this
problem is primarily a political problem.  Forgive me not wanting to
draw too much attention to it at the moment.

Again, how does this binding of post-self-insert-hook to nil in CC Mode
affect you?  What is it you're trying to do that this binding makes
difficult?

> Thanks,
> Ivan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2019-12-01 15:07 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
2019-12-01 15:07     ` Alan Mackenzie [this message]
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=20191201150738.GB5085@ACM \
    --to=acm@muc.de \
    --cc=38406@debbugs.gnu.org \
    --cc=yyoncho@gmail.com \
    /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.