[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about dubious code for terminal frames
From: |
Gerd Möllmann |
Subject: |
Re: Question about dubious code for terminal frames |
Date: |
Mon, 02 Sep 2024 16:54:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org, rudalics@gmx.at
>> Date: Mon, 02 Sep 2024 16:11:34 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > What exactly is the problem? Doesn't change_frame_size support child
>> > frames?
>>
>> Not on terminals, no, for exactly the reason that adjust_frame_size for
>> terminal frames sets the terminal's size. So, when I opened a new child
>> frame of size 20x30 suddenty the terminal had size 20x30. And the
>> innocent root frame redisplay got an emacs_abort because it wrote
>> outside of that range because the root frame was of course much larger.
>
> OK, but the behavior on TTY terminals in this regard should be exactly
> the same as on GUI terminals, when you drag the frame's border with
> the mouse. So I very much hope there's code in Emacs that you can
> simply copy or maybe even just call.
Well, an easy cop-out is to not set FrameCols/FrameRows for child
frames. Seems to work, but it's not a solution. Hence my question here.
>> I personally think it's wrong to set FrameCols/Rows in this way in
>> adjust_frame_size. From my POV, it's should be a physical property of
>> the terminal that Emacs does not change. If we can't determine the size
>> of the terminal (and I wonder how often that is the case), we should
>> devise a way to let the user specify the size, but without the current
>> magic.
>
> But with the current proliferation of terminal emulators whose window
> can be resized, what other choice do we have when the only source of
> information about the resize is SIGWINCH? How else can we update the
> Emacs notion of the frame's size?
See get_tty_size which the SIGWINCH handler already calls. We could use
that to get the physical dimension of the terminal. Only problem are
terminals not supporting one of the methods get_tty_size knows, for
example the co/li escape sequences. We'd need some way to let the user
specify the terminal size for that case.
Outside of get_tty_size I'd make FrameCols/Rows const. I guess that
frame size changes could remain as is. Only that setting FrameCols/Rows
is none of their business. It's an input for them, not an output.
- Question about dubious code for terminal frames, Gerd Möllmann, 2024/09/02
- Re: Question about dubious code for terminal frames, Eli Zaretskii, 2024/09/02
- Re: Question about dubious code for terminal frames, Gerd Möllmann, 2024/09/02
- Re: Question about dubious code for terminal frames, Eli Zaretskii, 2024/09/02
- Re: Question about dubious code for terminal frames, Gerd Möllmann, 2024/09/02
- Re: Question about dubious code for terminal frames, Eli Zaretskii, 2024/09/02
- Re: Question about dubious code for terminal frames,
Gerd Möllmann <=
- Re: Question about dubious code for terminal frames, Eli Zaretskii, 2024/09/02
- Re: Question about dubious code for terminal frames, Gerd Möllmann, 2024/09/02
- Re: Question about dubious code for terminal frames, Eli Zaretskii, 2024/09/02
- Re: Question about dubious code for terminal frames, Gerd Möllmann, 2024/09/02
- Re: Question about dubious code for terminal frames, Eli Zaretskii, 2024/09/02
- Re: Question about dubious code for terminal frames, Gerd Möllmann, 2024/09/02
- Re: Question about dubious code for terminal frames, Eli Zaretskii, 2024/09/02
- Re: Question about dubious code for terminal frames, martin rudalics, 2024/09/02
- Re: Question about dubious code for terminal frames, Gerd Möllmann, 2024/09/02
- Re: Question about dubious code for terminal frames, martin rudalics, 2024/09/02