From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Fixing post-self-insert-hook. Date: Sat, 18 Sep 2021 09:57:19 +0000 Message-ID: References: <83ilyy77q5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27838"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 18 11:58:27 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mRX75-0006wC-4g for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Sep 2021 11:58:27 +0200 Original-Received: from localhost ([::1]:56902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRX73-0004N2-Hv for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Sep 2021 05:58:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43492) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRX68-0003dO-Vd for emacs-devel@gnu.org; Sat, 18 Sep 2021 05:57:29 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:26132 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mRX62-0008RP-Bz for emacs-devel@gnu.org; Sat, 18 Sep 2021 05:57:28 -0400 Original-Received: (qmail 97999 invoked by uid 3782); 18 Sep 2021 09:57:19 -0000 Original-Received: from acm.muc.de (p2e5d52d9.dip0.t-ipconnect.de [46.93.82.217]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 18 Sep 2021 11:57:19 +0200 Original-Received: (qmail 5240 invoked by uid 1000); 18 Sep 2021 09:57:19 -0000 Content-Disposition: inline In-Reply-To: <83ilyy77q5.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:274978 Archived-At: Hello, Eli. On Sat, Sep 18, 2021 at 08:50:26 +0300, Eli Zaretskii wrote: > > Date: Fri, 17 Sep 2021 19:37:27 +0000 > > From: Alan Mackenzie > > Cc: João Távora > > Given that it is now (at least politically) impossible to ban buffer > > changing post-self-insert-hook functions, I propose to change the time at > > which the hook gets called. > > Instead of getting called straight after the self-insert-command, it > > should be called at the end of the command which called > > self-insert-command. Just before post-command-hook, perhaps. Yes there > > are details to be worked out. > > This will make no difference to the usual self-insert-command call. It > > will, however, restore the certainty of processing to Lisp code such as > > c-electric-brace without having to resort to ugly workarounds. > If CC Mode has problem with these hooks, it could bind them to nil > around the call to self-insert-command, couldn't it? That has indeed been done since early 2019. It's not nice. It involves c-electric-brace knowing that one of the entries in post-self-insert-hook is electric-pair-post-self-insert-function, and calling it explicitly. It couples the electric-... minor modes with CC Mode, and blocks out any other functionality on the hook from CC Mode. > That'd be much better than making any globally-visible change in > behavior, for which we cannot possibly know the unintended > consequences. The mechanism is currently broken. Do we stick with this known breakage for fear of an unknown, not particularly likely one, or do we fix it? > In any case, please let's not make this change before the emacs-28 > branch is cut, as it can potentially disrupt many places. Yes. But surely we have enough time before Emacs 29 for any problems it might cause to come to light. -- Alan Mackenzie (Nuremberg, Germany).