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 15:56:26 +0000 Message-ID: References: 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="13210"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 18 17:57:22 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 1mRciP-0003FH-VV for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Sep 2021 17:57:21 +0200 Original-Received: from localhost ([::1]:34298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRciO-0004pS-1X for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Sep 2021 11:57:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34200) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRchc-0004Ag-4I for emacs-devel@gnu.org; Sat, 18 Sep 2021 11:56:32 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:35349 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mRcha-0005mK-14 for emacs-devel@gnu.org; Sat, 18 Sep 2021 11:56:31 -0400 Original-Received: (qmail 34520 invoked by uid 3782); 18 Sep 2021 15:56:27 -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 17:56:27 +0200 Original-Received: (qmail 8414 invoked by uid 1000); 18 Sep 2021 15:56:26 -0000 Content-Disposition: inline In-Reply-To: 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=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:274999 Archived-At: Hello, Stefan. On Sat, Sep 18, 2021 at 10:15:02 -0400, Stefan Monnier wrote: > >> 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. They're defined. The caller of self-insert-function can take account of them. Also only things like SPACE or LFD trigger these functionalities. > > 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. 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. > > 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. Maybe. > > 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. > > 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`. ] Sorry, yes, that's exactly what I meant. > It would introduce its own lot of regressions, of course. It might, I'm not convinced either way. 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ćo about such an interface over the last few years, now and then, but such has not yet been forthcoming. > > 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`. Thanks. > Stefan -- Alan Mackenzie (Nuremberg, Germany).