emacs-devel
[Top][All Lists]
Advanced

[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:11:34 +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 14:59:54 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Did you consider SIGWINCH?  Its handler also calls adjust_frame_size.
>> 
>> Thanks, that would be this one, right?
>
> Right.
>
>> It also could know and set the terminal size, if get_tty_size can.
>> 
>> How complicated. I guess I rather work around this for now :-).
>
> 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.

>> And I wonder if one could brew a make-frame with some suitable frame
>> parameters that lead to setting the terminal size to something that
>> leads to a later emacs_abort in cmcheckmagic during redisplay of another
>> frame on the same terminal :-).
>
> Someone already did, see bug#71289.

Hahaha :-).

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. 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]