From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: 27.0.50: How can I test a buffer-local window-configuration-change-hook in batch mode? Date: Fri, 25 Oct 2019 15:42:46 +0300 Message-ID: <83k18tvvw9.fsf@gnu.org> References: <83ftjixlwh.fsf@gnu.org> <72dda818-78b6-953f-ba5c-e2e1c81c036e@orcon.net.nz> <83tv7xw78d.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="139663"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 25 14:44:39 2019 Return-path: Envelope-to: ged-emacs-devel@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 1iNyxK-000a7u-LA for ged-emacs-devel@m.gmane.org; Fri, 25 Oct 2019 14:44:38 +0200 Original-Received: from localhost ([::1]:59464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNyxJ-0006yd-72 for ged-emacs-devel@m.gmane.org; Fri, 25 Oct 2019 08:44:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53817) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNyvl-0006uf-4Q for emacs-devel@gnu.org; Fri, 25 Oct 2019 08:43:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49318) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iNyvk-0007lH-R1; Fri, 25 Oct 2019 08:43:00 -0400 Original-Received: from [176.228.60.248] (port=4131 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iNyvk-0004bv-9r; Fri, 25 Oct 2019 08:43:00 -0400 In-reply-to: (message from Phil Sainty on Fri, 25 Oct 2019 23:31:33 +1300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241408 Archived-At: > From: Phil Sainty > Cc: "emacs-devel@gnu.org" > Date: Fri, 25 Oct 2019 23:31:33 +1300 > > On 25/10/19 9:37 PM, Eli Zaretskii wrote: > >> * window-configuration-change-hook > >> * window-size-change-functions > >> > >> AFAICS the latter cannot be invoked from lisp? > > > > Why not? > > Hmmm. It's no longer clear to me. I'd assumed from the existence > of the C wrapper function that it *required* a wrapper function > (and, as no lisp wrapper existed, that it could therefore only be > used in C). run_window_size_change_functions() does more than just > `run-hook-with-args' at any rate, so maybe it's inadvisable to run > it without the wrapper, but I don't really know. > > > they are just Lisp functions, so you can invoke them from > > Lisp as usual, no? > > I guess I'm equating "can" with "should" here. If a hook is normally > called via a wrapper, and that wrapper does more than just the usual > `run-hooks' behaviours, then I'm assuming that the only correct way > to call the hook is using the wrapper -- which, in this instance, was > not exposed to lisp. It depends on what you want to do; "correct" is context dependent. In general, no Lisp code should ever call a hook that is meant to be called from C, because only the C code "knows" when and how to call it "correctly" so that the hook does its documented job. But if you need to call a hook function for testing purposes, all bets are off. > > But in general, I see no reason why we would expect a hook to be > > callable from Lisp via some wrapper, as opposed to directly, what > > would be the use case for that? > > As above, it behaves unusually for a hook, so the use-case is simply > any lisp code which needs to run that hook, because `run-hooks' > isn't going to do the trick for this one. Once again, I don't expect any Lisp to call a hook "correct;y" when that hook can only do its job when called from C. > >> However the only *calls* to 'run_window_size_change_functions' in > >> Emacs 26.3 are in xdisp.c -- so I'm presuming this hook was already > >> untestable in batch mode? > > > > "Untestable" in what sense? If you mean a test that would make sure > > the hook is called under some specific situations related to display, > > then we are back to the problem that the display code does nothing in > > batch mode. > > Yes, that's all I meant -- that it's not possible to write a batch mode > test which relies upon `window-size-change-functions' being triggered > by Emacs in the usual way, when "the usual way" is via redisplay, and > redisplay isn't doing anything. Yes, but it it also is impossible to write a batch-mode test which runs _any_ of the display-related hooks, because the only "correct" way to do that is to trigger redisplay, and you cannot do that in batch mode. So you can only write partial tests for these hooks, by invoking them directly from Lisp. > >> + (unless (version< emacs-version "27") > >> + (redisplay) > >> + (when noninteractive > >> + (run-window-configuration-change-hook))) > > > > I think the example is too much for NEWS, and is also a bit > > misleading, per the above discussion. > > See above, I guess, if you're referring here to whether or not > `run-window-configuration-change-hook' should exist? No, I'm referring to the fact that this test will not in general check that the hook is working, because it is unable to recreate its context and its triggering. It's a very partial test. > > I'd also suggest to make the text more general, because > > window-configuration-change-hook is not the only hook/feature > > affected by this issue. > > I think it is? No, it isn't. People who write tests for these hooks need to understand that they can never invoke the hooks from Lisp in the right context and at the right moment. > My suggested addition to this specific NEWS item is purely about > flagging a potential backwards-incompatibility, and this is the only > hook out of the original two which is affected in this way (because > `window-size-change-functions' was already run only by redisplay). You are looking at this from the narrow POV of backwards incompatibility, for someone who had a test that used run-window-configuration-change-hook. I suggest instead to write text that will be useful for people who might have tests for other similar hooks, even though they are new in Emacs 27.