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: Thu, 5 Dec 2019 20:17:13 +0000 Message-ID: <20191205201713.GC6252@ACM> References: <20191130143638.GA6716@ACM> <20191201150738.GB5085@ACM> <83imn0lyed.fsf@gnu.org> <20191201192709.GE5085@ACM> <83blsrn58a.fsf@gnu.org> <20191204204159.GA7587@ACM> <83immuj0g7.fsf@gnu.org> <20191205190951.GA6252@ACM> <83pnh2h8x1.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="96870"; 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 Thu Dec 05 21:18:26 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 1icxZx-000P3X-VM for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 21:18:26 +0100 Original-Received: from localhost ([::1]:60564 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icxZv-0008DA-QW for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 15:18:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37740) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icxZf-00086F-KW for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 15:18:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icxZd-0002f8-Kr for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 15:18:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39305) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1icxZa-0002cU-2N for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 15:18:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1icxZZ-0003Ay-Sq for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 15:18: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: Thu, 05 Dec 2019 20:18: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.157557704112145 (code B ref 38406); Thu, 05 Dec 2019 20:18:01 +0000 Original-Received: (at 38406) by debbugs.gnu.org; 5 Dec 2019 20:17:21 +0000 Original-Received: from localhost ([127.0.0.1]:45278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icxYu-00039n-Ky for submit@debbugs.gnu.org; Thu, 05 Dec 2019 15:17:20 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:43840 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1icxYr-00039d-8P for 38406@debbugs.gnu.org; Thu, 05 Dec 2019 15:17:19 -0500 Original-Received: (qmail 69103 invoked by uid 3782); 5 Dec 2019 20:17:15 -0000 Original-Received: from acm.muc.de (p4FE15A39.dip0.t-ipconnect.de [79.225.90.57]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 05 Dec 2019 21:17:13 +0100 Original-Received: (qmail 6719 invoked by uid 1000); 5 Dec 2019 20:17:13 -0000 Content-Disposition: inline In-Reply-To: <83pnh2h8x1.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:172932 Archived-At: Hello, Eli. On Thu, Dec 05, 2019 at 21:25:14 +0200, Eli Zaretskii wrote: > > Date: Thu, 5 Dec 2019 19:09:51 +0000 > > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org > > From: Alan Mackenzie > > > Can you explain why you exempt these from being called from CC Mode? > > There is already a call to the matching-paren blink functionality in > > cc-cmds.el, which must stay for older Emacsen. If blink-paren-p-s-i-f > > was allowed to run too, the result would probably be a doubling of the > > blink time. This is not desirable. The same applies to smie-blink-m-o, > > which in any case will not be used for CC Mode. > > electric-pair-post-self-insert-function must not run in > > c-electric-brace/paren except as carefully coded in these functions > > explicitly; it would otherwise foul things up, one way or another, as it > > did in the scenario for which bug #33794 was raised. > > Of the other three electric-* functions, only one has a complete doc > > string, so it is work to work out what the other two do. > > electric-indent-post-self-insert-function is redundant in CC Mode, and > > probably harmful. At best it will just take up processor cycles. I > > believe electric-layout-p-s-i-f just duplicates the auto-newline > > behaviour of the c-electric-* functions, making it redundant. I don't > > know exactly what electric-quote-p-s-i-f does, but it is likely to be > > something to do with quotes, and thus likely to clash with CC Mode's > > handling of quotes. > I don't think CC Mode should protect users of those hooks from > themselves. It doesn't. Ivan's hook functions will now get called. > If the user or Lisp set up these hooks such that they end up shooting > themselves in the foot, we should let them. It's not a matter of what users might do. It's about what Emacs maintainers have already done. The current changes to CC Mode are to protect users of CC Mode from these design clashes inside Emacs. > We never provide any "safety nets" for silly hook functions, so we > shouldn't do that here as well. OTOH, if someone puts a function on > those hooks which does something legitimate, we should meet their > expectations and let those functions run, as the contract says. I think that, with my latest patch, that is the case. > So I think you shouldn't filter anything from the hook before you run > it. I thought you were urging me to do precisely that two or three posts ago. I just tried taking a particular function off of c--unsafe-post-self-insert-hook-functions and enabling electric-pair mode. On typing a brace, electric-pair-mode threw an obscure error. It doesn't make sense to call electric-pair-post-self-insert-function twice for one keypress. That is a good reason for having that function filtered out of the hook. For the other five filtered out functions, I gave what I think were good reasons in my last post. The root of the problem is the hook post-self-insert-hook. It is a thoroughly bad idea. The implications of introducing it a few years ago weren't thought through. Assuming that removing this hook from Emacs isn't an option, we are left with ugly ad-hoc workarounds, such as the patch we're currently discussing. -- Alan Mackenzie (Nuremberg, Germany).