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

[Eli Zaretskii]

> Cc: address@hidden
> From: Phil Sainty <address@hidden>
> Date: Fri, 25 Oct 2019 12:53:46 +1300
> 
> 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?

Patches welcome.

> 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).

See below.

> 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?

Why not? they are just Lisp functions, so you can invoke them from
Lisp as usual, no?

I don't know why Martin needed run-window-configuration-change-hook,
it doesn't seem to be called anywhere in Emacs.  But in general, I see
no reason why we would expect a hook to be callable from Lisp via some
wrapper, as opposed to directoy, what would be the use case for that?

> `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?

"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.  If you mean calling the hook functions directly, then you
certainly _can_ do that -- just walk the list and call each function
in the list directly.  Or what am I missing?

> 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)))

I think the example is too much for NEWS, and is also a bit
misleading, per the above discussion.  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.

> > 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?

We actually need both an emulation of a text-mode and of a GUI
display, because redisplay treats them differently, and because some
display features are not supported on text-mode terminals.

It is true that emulating a text-mode display is somewhat easier,
because we need to implement fewer APIs, but I'm not sure the
difference is too significant, at least not with some designs.

> 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?

I'm not sure how the pty code is relevant.  If you are thinking of
hooking the pty device and somehow redirecting the stuff back to us,
then I would recommend against such a design because it is unportable,
and cannot be extended to support GUI displays.  (Texinfo does
something like that in its test suite for the stand-alone Info reader,
if someone wants to take a look.)

My idea is to intercept the displayed stuff inside Emacs, and analyze
the results by accessing some in-memory data instead.  But I admit
that I never thought about this long enough to see if this idea will
work well enough, so maybe trying it will hit some brick wall.

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

We don't need to remove any code for that, we just need to implement a
new type of "window-system" whose frames will not pass the
FRAME_INITIAL_P test.  Running Emacs in batch mode with such a
window-system will need to provide the necessary parameters the
display engine needs, like the dimensions of the display, in some
initialization code.