From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs 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 19:27:09 +0000 Message-ID: <20191201192709.GE5085@ACM> References: <20191130143638.GA6716@ACM> <20191201150738.GB5085@ACM> <83imn0lyed.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="263275"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 01 20:28:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ibUt9-0016Km-CP for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Dec 2019 20:28:11 +0100 Original-Received: from localhost ([::1]:54694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibUt8-0004z3-8G for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Dec 2019 14:28:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35906) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibUt1-0004yW-90 for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2019 14:28:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibUt0-000376-3R for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2019 14:28:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58981) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibUsz-000363-Pq for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2019 14:28:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ibUsz-00058b-Mi for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2019 14:28:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Dec 2019 19:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38406 X-GNU-PR-Package: emacs Original-Received: via spool by 38406-submit@debbugs.gnu.org id=B38406.157522843519696 (code B ref 38406); Sun, 01 Dec 2019 19:28:01 +0000 Original-Received: (at 38406) by debbugs.gnu.org; 1 Dec 2019 19:27:15 +0000 Original-Received: from localhost ([127.0.0.1]:36721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibUsE-00057c-Ts for submit@debbugs.gnu.org; Sun, 01 Dec 2019 14:27:15 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:20940 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1ibUsC-00057S-0C for 38406@debbugs.gnu.org; Sun, 01 Dec 2019 14:27:13 -0500 Original-Received: (qmail 74664 invoked by uid 3782); 1 Dec 2019 19:27:10 -0000 Original-Received: from acm.muc.de (p2E5D5336.dip0.t-ipconnect.de [46.93.83.54]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 01 Dec 2019 20:27:08 +0100 Original-Received: (qmail 8906 invoked by uid 1000); 1 Dec 2019 19:27:09 -0000 Content-Disposition: inline In-Reply-To: <83imn0lyed.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172728 Archived-At: Hello, Eli. On Sun, Dec 01, 2019 at 19:59:54 +0200, Eli Zaretskii wrote: > > Date: Sun, 1 Dec 2019 15:07:38 +0000 > > From: Alan Mackenzie > > Cc: 38406@debbugs.gnu.org > > > > 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. > Can we please make it technical again? Why can't the CC Mode function > which temporarily disables post-self-insert-hook call the hook > functions after it does its thing? (I think I already asked this in > the past, but I cannot find that question or any discussion of it.) See bug #33794 (but a lot of the discussion is unedifying). post-self-insert-hook's functions, unusually amongs hooks, interfere with its triggering event. This contrasts with, say, after-change-functions, where the functions don't insert into or delete from the buffer, or pre-redisplay-functions, where the functions don't try to prevent a particular window getting displayed. But post-s-i-h customarily makes its own buffer changes such that self-insert-command no longer performs its prime function, which is to insert exactly one copy (or N copies) of the typed key into the buffer. This makes it problematic for Lisp code which calls self-insert-command. It would be nice if functions on post-self-insert-hook could be split into "disruptive" ones and "safe" ones, so that a function such as c-electric-brace could elect to run just the "safe" ones. I think Ivan's functions would likely be classed as "safe". How about this idea for Emacs 28? Anyhow back to your question: c-electric-brace carefully calls electric-pair-post-self-insert-function testing various states afterwards (such as the buffer reducing in size) so as to be able to complete c-electric-brace's own processing. Just calling post-self-insert-hook instead could easily upset this balance. Unfortunately this hook can contain arbitrary code, and frequently does. So to call this hook at the end of c-electric-brace would mean having to filter the hook first (at the very least, to remove electric-pair-post-self-insert-function), which just seems very hackish and unsatisfactory. As a statistic, there are approximately 111 occurrences of (self-insert-command ...) in the Emacs Lisp sources. Any of them might be vulnerable to disruption by post-self-insert-hook. -- Alan Mackenzie (Nuremberg, Germany).