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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Phil Sainty <address@hidden>
> Date: Sun, 27 Oct 2019 02:09:30 +1300
> 
> 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.

It sounds strange to make the buffer read-only for this, because doing
that by itself doesn't make Emacs faster.  Maybe you should explain
the rationale somewhere in the docs.

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

I don't insist, but I do think that having different behavior in
displayed and non-displayed buffers would surprise me.  YMMV, of
course.

> 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 actually don't see why you'd need to compromise here.  But it's your
call.

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

If you don't need a new hook (and Stefan says you shouldn't need one),
then there's no issue here.  I just wrote that under the assumption
that you'd ask for a new hook, as Martin seemed to indicate.

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

How is it not redundant now?  The hook is not called from the display
engine, so you cannot test that it does its job when it's needed.

> The entire purpose of this test was to confirm that `so-long' gets
> called *in*directly.

So you want to make sure that putting a function on
window-configuration-change-hook will cause that function to be called
when run-window-configuration-change-hook is called?  If that's the
purpose, then I guess it's okay, but then what does it have to do with
the real-life calls?  run-window-configuration-change-hook isn't
called then.