[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Testing redisplay code in batch
From: |
Eli Zaretskii |
Subject: |
Re: Testing redisplay code in batch |
Date: |
Thu, 24 Sep 2020 21:58:28 +0300 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: psainty@orcon.net.nz, emacs-devel@gnu.org
> Date: Thu, 24 Sep 2020 14:31:58 -0400
>
> Based on your comments, I assume you consider that this feature is
> acceptable for `master` once it's clean.
Sure, why not? It looks useful.
> /* No actual display to update so the "update" is a nop and
> obviously isn't interrupted by pending input. */
> paused_p = false;
OK.
> Without it I got an assertion failure in xdisp.c:18241
>
> if (MINI_WINDOW_P (w))
> {
> if (w == XWINDOW (echo_area_window)
> && !NILP (echo_area_buffer[0]))
>
> because XWINDOW complains that `echo_area_window` is not a window.
>
> Maybe the better fix is to change `init_xdisp` so it also sets
> `echo_area_window` when `noninteractive`?
Yes, I think so.
> Do you think it's otherwise acceptable as-is? I was thinking of only
> allowing redisplay in `FRAME_INITIAL_P` under the control of some
> special config var.
A command-line option, perhaps? I agree that the "normal" -batch
should probably continue working as it does now.
And yes, I think it's okay to go in. I bet it may not support too
many display features, but we can always extend it as we go.
> > How about a small NEWS item about this?
>
> I'll see to it,
Thanks.
Re: Testing redisplay code in batch, Alan Mackenzie, 2020/09/23
Re: Testing redisplay code in batch, Eli Zaretskii, 2020/09/23