From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Fixing post-self-insert-hook. Date: Sat, 18 Sep 2021 14:03:27 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35756"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 18 20:04:28 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 1mRehQ-000943-BX for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Sep 2021 20:04:28 +0200 Original-Received: from localhost ([::1]:50438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRehO-0002I1-V9 for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Sep 2021 14:04:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRegZ-0001dU-UL for emacs-devel@gnu.org; Sat, 18 Sep 2021 14:03:36 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55523) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRegW-0005aO-P6 for emacs-devel@gnu.org; Sat, 18 Sep 2021 14:03:34 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4A163100186; Sat, 18 Sep 2021 14:03:30 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4C28D100139; Sat, 18 Sep 2021 14:03:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1631988208; bh=1yxFfrRyzSOV3/F6Vp4Ln7n0R364syz+IKtpN7tMLdM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GSIt2s+W+jDOzqDck0UBBJwMVd3WKZvUu4h3ULoXhhwQcDXzm9f+HsM/CfznxQhPN Tq549aHreBUBLNRkHJVqDt5q/4aOQwTsvCM6Fv/R/gtTL7mor6z3ZzHPkKQ/n+x7nG Bgkp4a1utpqkqnsk50VNv7tVTuRxKBW7bDfZwAiYSvEC3WI3b373B0HhWgMKGrk3zZ R6JGLKCJY8pkuIvR+jBrS/fehrUTzWbPBV6M3VdTyX0DN1phwlEt8WqPjfadB81pRv KtE+14MeI6hWNht86HoHUPmxzAk2XstleiFsxfaHlXqtTYrRnNDFmwk60k5Y3fwPG7 mCtNEV8UWxMVQ== Original-Received: from pastel (unknown [45.72.241.23]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1E7451203B5; Sat, 18 Sep 2021 14:03:28 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sat, 18 Sep 2021 15:56:26 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:275023 Archived-At: > They're defined. The caller of self-insert-function can take account of > them. Also only things like SPACE or LFD trigger these functionalities. abbrev expansion can take place for other keys than SPC and auto-fill can happen for any char in `auto-fill-char`, so it's not limited to SPC and LFD: it can happen virtually with any key, depending on the user's config. Indeed, in practice it tends to happen only for a few keys like SPC, but if a code doesn't want `post-self-insert-hook` modifications, and it presumes that auto-fill or abbrev expansion won't happen, then we're back at the question about why does it call `self-insert-command` rather than `insert`. >> After all, if the code just wanted to insert a given char, it >> should/would have used `insert`, which is both shorter and >> more efficient. > OK. We're back at the point of speculating what all the > self-insert-commands are there for. `insert' isn't actually fewer > characters to type, because one hast to extract the keypress from > this-command-keys, but I take the point. In my experience, there isn't a general solution to this problem (and yes, I agree it's a problem; what I disagree with is the characterization that it's specifically linked to `post-self-insert-hook`). We need to fix it on a case by case basis, and I think it's OK to do that lazily by only fixing the problems when we encounter them. >> > The effect of self-insert-function called from Lisp is wholly >> > dependent on what happens to be in post-s-i-h. You might get no >> > characters inserted, you might get 1 or 2, you might get many. >> > You just can't know at programming time. > >> Indeed. If they want/need to know, then why do they call >> `self-insert-command` instead of `insert`? >> Until we know that, we can't know what's the better fix. > > I suspect it's for commands which do something extra as well as > self-insert-function. The c-electric-... commands fall into this > category. Maybe the thinking is compatibility with self-i-c. It's difficult to combine several extra behaviors in `self-insert-command` in a modular way. For that reason `electric-indent-mode`, `electric-pair-mode`, and `electric-layout-mode` know about each other to some extent (tho I strove to design them such that they are independent). For that same reason, `c-electric-*` needs to know about those others as well :-(, tho it also has the option of just breaking them by using plain `insert`. >> It would introduce its own lot of regressions, of course. > It might, I'm not convinced either way. I can see a few "obvious" interactions with other post-command-hooks, and based on the history of the subtle issues we've had with interactions between `electric-*-mode`s I'm pretty sure it would take a few iterations before getting something that works as well as what we have. And of course, the effects that are currently undesired may still be undesired when postponed to `post-command-hook`. I think postponing to `post-command-hook` will just make the behavior yet more complex and yet harder to control (e.g. you won't have the easy option of let-binding `electric-*-mode` around the call to `self-insert-command`). > Right now, commands like c-electric-brace get by by binding > post-self-insert-hook to nil (thus getting predictability) then > explicitly calling electric-pair-post-self-insert-function a bit later. > This isn't good, since e-p-p-s-i-function is really an internal function > in elec-pair.el, without any guaranteed functionality. I really need a > defined external function in elec-pair.el which would do the same thing > as e-p-p-s-i-function, but in addition return information about what > it's just done. I've asked Jo=E3o about such an interface over the last > few years, now and then, but such has not yet been forthcoming. Of course, IMO (and I believe Jo=E3o has the same position) the better path forward is to drop that `c-electric-brace` code altogether and rely on `electric-pair-mode` instead like all other modes do, so the need for such extra API is definitely not very high in my list of priorities ;-) Stefan