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

[Phil Sainty]

On 27/10/19 12:28 AM, Eli Zaretskii wrote:
> Looks like the problem was specifically with setting the buffer
> read-only?  Why does so-long do that?

The reasoning for this default was that *editing* a long line might
be slow, and in the sorts of files which I was expecting so-long to
trigger for, the user probably doesn't want to be manually editing
them; so this is to protect against the user accidentally modifying
the line (and probably then needing to undo it), all while Emacs is
responding more slowly than usual.

The particular issue raised was certainly with the read-only state,
but it did make me think that other issues might well be possible,
and that NOT messing with invisible buffers would be a much safer
(and much less surprising) default behaviour from the point of view
of other libraries doing automated things to files behind the scenes.

(It's configurable, so the original approach can be restored if users
choose to.)


>> 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'll have to have a play.

My initial feeling is that the *potential* to break such background
processing (which is liable to be hidden from the user) by triggering
so-long is a more significant risk than the potential for background
processing to run slowly because of long lines; so I'm still leaning
towards using the "visible buffers only" approach as the preferable
compromise here.


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

I think it's quite a nice use of the hook, to be honest (even if it's
not a use-case that was originally envisaged).  I was very pleased
when I realised how very simple and efficient this approach was.  The
behaviour I wanted arises almost effortlessly from setting a single
buffer-local value.  I definitely didn't see that as a downside.


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

Do you mean, in the case where I have done this...

(add-hook 'window-configuration-change-hook #'so-long nil :local)

...that my test could just call `so-long' directly, rather than
running the hook?

If I did that, the test would really be redundant.  It certainly
wouldn't be testing any part of the new behaviour.  Other existing
tests already assert what happens when `so-long' is called directly.
The entire purpose of this test was to confirm that `so-long' gets
called *in*directly.


-Phil