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

[Phil Sainty]

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.


On 26/10/19 10:07 PM, Eli Zaretskii wrote:
> Could be.  But why does it have to be related to the first time a
> buffer is displayed?  Don't we want to do that when the file is
> visited instead?

Your comment was to Martin, but were you wondering why so-long would
wait for the buffer to be displayed?

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

I don't think long lines pose any performance problems in buffers
which are never displayed, so the revised approach means those buffers
are simply left alone (they just get a buffer-local hook value which
will most likely never be examined or acted on), and it's only buffers
which actually get displayed that are subject to so-long's actions.

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.


>>  > Without `run-window-configuration-change-hook' I'd have to replicate
>>  > some of that functionality myself, and the test would be getting even
>>  > further away from the real processes, and therefore becoming less and
>>  > less useful as a test.  I'd like to have to fake as little as possible.
>>
>> Understandable.  Rewriting this in Elisp is no fun.
> 
> 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.  The actual
implementation in C is going to remain, so removing the lisp binding
seems like an extremely minimal saving, whereas keeping it provides a
concrete benefit in at least this case.  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, so ultimately I don't think it's too important how we get to that
point, so long as I get to compare 'before hooks runs' and 'after hook
runs' -- which, at present, I can do.


-Phil