Re: 27.0.50: How can I test a buffer-local window-configuration-change-hook in batch mode?

[Phil Sainty]

Hi Eli,

On 25/10/19 3:23 AM, Eli Zaretskii wrote:
>> How does one write tests for this new behaviour?
> 
> I don't think you can.  Redisplay does nothing in batch mode,
> by design:

That certainly explains things; thanks.

I think the ERT manual would benefit from a mention of that
general constraint for batch mode; and perhaps (elisp) Batch Mode
and (elisp) Forcing Redisplay could comment on it as well?


For the specific changes to the window change functions, I think
it would be good to call out these testing side-effects in the
NEWS entry (I've spent a fair chunk of time looking at this, so
it might save someone else the same trouble).

AFAICS of the six window change hooks in Emacs 27, only two of
them were present in earlier versions:

* window-configuration-change-hook
* window-size-change-functions

The former has `run-window-configuration-change-hook' (which I've
now used in my test as a workaround).

AFAICS the latter cannot be invoked from lisp?

`run_window_size_change_functions' is a C function only.  Emacs 27
adds `run_window_change_functions' which is an umbrella for the
various new things, but that's also a C function only.

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?

So it looks to me as if `window-configuration-change-hook' is the
only one which would break existing tests.


How does this look?

--- etc/NEWS
+++ #<buffer NEWS>
@@ -2709,6 +2709,16 @@
 See the section "(elisp) Window Hooks" in the Elisp manual for a
 detailed explanation of the new behavior.

+As 'window-configuration-change-hook' is now invoked by redisplay,
+existing tests relying on it may fail.  Adding a call to 'redisplay'
+is sufficient for interactive test runs; but for batch mode you will
+need to run the hook explicitly, as 'redisplay' has no effect:
+
+  (unless (version< emacs-version "27")
+    (redisplay)
+    (when noninteractive
+      (run-window-configuration-change-hook)))
+
 +++
 ** Making scroll bar and fringe settings persistent for windows.
 The functions 'set-window-scroll-bars' and 'set-window-fringes' now



> This is not just an optimization: in batch mode important data
> structures related to the display engine are not set up, because we
> have no device to display on, so trying to enter redisplay will crash
> very soon.
>
> It would be a very important and useful feature to add a
> pseudo-terminal which would allow invoking display in batch mode and
> accessing the results of such a "display" in memory in order to verify
> its correctness.  Such a feature would allow us to finally start
> adding display tests, something that we sorely need.  So if you (or
> anyone else) are interested, working on that would be very welcome,
> and as a side effect will make the person who does that an expert on
> our display code.  But until this job is done, display-related tests
> can only be run interactively.

I don't believe I'm the person for this, sorry.  I do have a (perhaps
stupid) question about it, though.

When you say "pseudo-terminal" are we talking about text terminals,
or graphical 'terminals', or potentially both independently?  Or am
I misinterpreting entirely?

I am *imagining* that adding a text-based pseudo-terminal would be
a substantially simpler task than a graphical one, and would be
sufficient for testing redisplay as it pertains to text frames?

I'm also imagining that there is existing GPL'd tty/pty code which
might conceivably form a basis, and that the harder part would be
making it possible to interrogate?

So would step 1 be to provide a tty/pty for batch mode, and remove
the code inhibiting 'redisplay', and have Emacs "not crash"?


-Phil