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

[Eli Zaretskii]

> Cc: martin rudalics <address@hidden>, address@hidden
> From: Phil Sainty <address@hidden>
> Date: Sat, 26 Oct 2019 23:57:49 +1300
> 
> On 26/10/19 2:44 AM, Eli Zaretskii wrote:
> >> if you feel it belongs in NEWS then let's do that.
> >
> > I do.  TIA.
> 
> All good.  I'll write that along with some updates for the manuals
> sometime soon.

Thanks.

> It did originally act as soon as the file was visited (and the code
> currently in master still does) regardless of buffer visibility; but
> I ended up with some bug reports related to libraries which were
> visiting files in order to do some processing behind-the-scenes,
> but which were getting tripped up by so-long doing things to those
> buffers unexpectedly.
> 
> Refer to:
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-10/msg01726.html

Looks like the problem was specifically with setting the buffer
read-only?  Why does so-long do that?

> I don't think long lines pose any performance problems in buffers
> which are never displayed

You are wrong: it will cause problems in any function that uses the
display code, even if nothing is displayed.  For example,
vertical-motion, next-line, posn-at-point, etc. all use the display
code internally.

> I've not been able to spot any down-sides to the change, so I'm pretty
> sure it's the right thing to do.

Well, one downside is that you now need to use a hook that was not
really meant for that, or we'd need to introduce yet another hook.
Which is perfectly OK, as long as we are sure there's no simpler
solution, one that uses existing facilities.

> > Per previous messages, rewriting in Lisp is either (a) not necessary,
> > or (b) will not help even if done.  So I don't think this discussion
> > concluded that run-window-configuration-change-hook is of any
> > importance that would justify leaving it in our sources in the long
> > run.
> 
> I'll argue for not removing the function while it has a use.

I'm not going to push to remove this, but I think your basic premise
here is wrong.  These hooks cannot be possibly tested in full from
batch mode anyway, so your ability to test them is limited, with or
without that function.

> Running the hook explicitly in my test may not be the same thing as
> redisplay running it; but then the thing I'm really testing is that
> when the hook runs, so-long does its thing

And you cannot test that by calling the hook function directly?  Why
not?