Re: master 8aef5d224a6: Merge branch 'scratch/tty-child-frames'

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: michael.albinus@gmx.de,  emacs-devel@gnu.org
> Date: Thu, 19 Dec 2024 14:19:20 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The new code now _requires_ a tty frame to be used (decode_tty_frame,
> >> check_tty), which I think the tests can't provide, running in batch. And
> >> I'd rather not be less picky for the sake of these tests.
> >
> > Why is that a problem?  
> 
> You mean why removing the checks (decode_tty_frame, check_tty) is a
> problem?. My question is more what these tests bring tot he table that
> outweighs removing checks.
>  
> > A batch session does have a frame, you just need to account for that.
> 
> I know it has an initial frame, which is neither a tty nor a window
> system frame. The idea of testing xt-mouse with that is, let's say,
> interesting. And then that comment

That frame is very much like a tty frame, AFAIR.  I suggest to try
relaxing the test and seeing if the xt-mouse tests then pass.

> > I think the test that emits the error is too strict, and should be
> > relaxed when noninteractive is non-zero. Or maybe invert the test and
> > check for !FRAME_WINDOW_P (which would then allow the frame that
> > exists in the batch session).
> 
> I could maybe make check_tty not signal if noninteractive == true. I
> guess that could make things work, one has to try, but it surely doesn't
> win a beauty price :-(.

If it makes a test work, why not?  We can even document this in a
comment.