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 10:15:02 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34508"; 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, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 18 16:16:19 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 1mRb8d-0008lu-6N for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Sep 2021 16:16:19 +0200 Original-Received: from localhost ([::1]:34184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRb8c-0006Ur-34 for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Sep 2021 10:16:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRb7X-0005Ab-Mf for emacs-devel@gnu.org; Sat, 18 Sep 2021 10:15:11 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7857) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRb7U-0003FY-Qy for emacs-devel@gnu.org; Sat, 18 Sep 2021 10:15:10 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DF41080A6B; Sat, 18 Sep 2021 10:15:06 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5018C8009D; Sat, 18 Sep 2021 10:15:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1631974505; bh=mr9PV6B6v6CR9sygNCIRtXIs8iEp0bmnlSetcGKDUQ0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FUS59SAUva5XalwVcxAmmm8wvSkvVSwCJqDukcUj85uQ+cCeZ8zPRv/YiXrwUpmSe VdE3lKe+4CTUmgEl8cOPSJ1porV43gvmKI7dWx9ybFYokDEfemyXvOpfEGvtoeoVSs NoT70qB2KThh2FzhtVgivtEgifO+UfFLaf/57gZVSajBSaq+NgWOV4FztygLfTqlOH gvrnaKeyWm4Zf7LcLjStYg9Oa+zrHT5/jXl/V4ynC4WdSVbBP9sf5T+0zipOyN9czy tLvRBaqPh1yFsghcS4BjxRBrgmZKm4/0LnPhloCOLQnLsXJnGWhdiQaoHdWNK3JEKz Aq973Wv7dPKAQ== Original-Received: from milanesa (unknown [45.72.241.23]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CAE8B120228; Sat, 18 Sep 2021 10:15:04 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Fri, 17 Sep 2021 20:53:42 +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:274996 Archived-At: >> The question here is why those effects are undesirable while the other >> effects (like auto-fill or abbrev expansion) aren't. > It's because it's like making a buffer change in an after-change function > (that is an insertion or a deletion, not just a text-property change). I still don't see how the changes performed by auto-fill and abbrev expansions are different in this respect (both of them are internal to `self-insert-command` rather than being on `post-self-insert-hook`, for historical reasons). They aren't just making text-property changes. > There's no way for the calling function to keep track of what's done. That's usually the point: the calling function doesn't want to insert a given char, but instead it wants to faithfully reproduce all the magic things that happen when you hit the corresponding key. 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. > That may be so, but the point is, an indeterminate part of these 111 > calls is currently undefined. And I'm pretty sure that among those a significant fraction is already similarly broken/undefined even when `post-self-insert-hook` is nil because it would also break in the face of some auto-fill or abbrev expansions. > 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. > However, if the call to post-self-insert-hook were to be postponed to the > end of the function, all the 111 Lisp calls would be defined again, and > they would do the same as they did before post-s-i-h came along. [ I assume by "end of the function" you meant "after the command" such as via `post-command-hook`. ] It would introduce its own lot of regressions, of course. > I actually disagree with this (or I'm lacking some knowledge). With M-: > post-self-insert-function you can see what's in the hook, and with a > little bit of delq, and so on, can change it for testing purposes. I > don't think you can do any of that with an add-function type structure. > Please tell me if I'm wrong, here. Thanks! Not wrong, no. `M-:` indeed currently gives you the raw unreadable bytecode, but if you do `C-h o foo-function` or if you use `foo-function` in `M-x ielm`, you'll get something like: ELISP> (defvar foo-function #'ignore) foo-function ELISP> (add-function :around foo-function #'fun1) #f(advice-wrapper :around ignore fun1) ELISP> foo-function #f(advice-wrapper :around ignore fun1) ELISP> It's more verbose than the values we have on hooks, admittedly, but it's somewhat readable. This "passably readable" form is displayed whenever the value is printed by `cl-print`. Stefan