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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 19 Dec 2024 12:59:44 +0100
>> 
>> Michael Albinus <michael.albinus@gmx.de> writes:
>> 
>> > Gerd Moellmann <gerd@gnu.org> writes:
>> >
>> > Hi Gerd,
>> >
>> >>     Merge branch 'scratch/tty-child-frames'
>> >>
>> >>     Add support for child frames on tty
>> >
>> > This breaks xt-mouse-tests:
>> >
>> > --8<---------------cut here---------------start------------->8---
>> > # make -C test xt-mouse-tests
>> > Test xt-mouse-tracking-basic condition:
>> >     (error "tty frame should be used")
>> >    FAILED  1/3  xt-mouse-tracking-basic (0.776520 sec) at lisp/xt-mouse-tests.el:61
>> > Test xt-mouse-tracking-sgr condition:
>> >     (error "tty frame should be used")
>> >    FAILED  2/3  xt-mouse-tracking-sgr (0.000466 sec) at lisp/xt-mouse-tests.el:102
>> > Test xt-mouse-tracking-utf-8 condition:
>> >     (error "tty frame should be used")
>> >    FAILED  3/3  xt-mouse-tracking-utf-8 (0.000746 sec) at lisp/xt-mouse-tests.el:80
>> > --8<---------------cut here---------------end--------------->8---
>> >
>> > Best regards, Michael.
>> 
>> Hi Michael,
>> 
>> 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

;; FIXME: this doesn't work when called inside a non-batch mode Emacs
;; session.

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