Re: Question about dubious code for terminal frames

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

martin rudalics <rudalics@gmx.at> writes:

>> I think I have the above here. It reads
>>
>>    /* Assign new sizes.  */
>>    FRAME_COLS (f) = new_text_cols;
>>    FRAME_LINES (f) = new_text_lines;
>
> It might cause something weird in resize_frame_windows, but that's maybe
> only here.
>
>> Anyway. My problem is setting FrameCols/Rows in adjust_frame_size. It's
>> not guaranteed that the terminal's size has indeed changed when that is
>> done.
>
> You mean the
>
> 	FrameRows (FRAME_TTY (f)) =
> 	FrameCols (FRAME_TTY (f)) =
>
> assignments?

Exactly.

> These are from the pre-2014 change_frame_size_1 code with the comments
> mostly preserved and governed by similar conditions. Do you think
> something changed here?

Actually, I wondered if this might be something I overlooked when writing
the new redisplay. Last century :-). Alas, there were so many changes in
the meantime. that I give up trying to find out.

> But I agree that for child frames with their own smaller dimensions
> these assignments should be obviously skipped.

Yes, for child frames it's certainly wrong. And I can easily work around
that.

What I wonder is if it's the right thing to do for normal frames, as
well. What happens if I make-frame a second non-child tty frame with
frame parameters that lead to the FrameRow/Col assignments with smaller
values?

If that happens, the terminal appears to have changed size, which it of
course hasn't. And redisplaying the first frame might trigger an
emacs_abort in cmcheckmagic that tries to make sure that we don't write
beyond the terminal borders, which have been set by the new fraem.

And more general, I wonder why setting the physical terminal size in
adjust_frame_size is the right thing to begin with. I believe
determining the terminal size should happen elsewhere and the size is
and input to the algorith resizing frames.

I don't know whqt Eli thinks about this, as you might have noticed :-)