[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions on glyph matrices used for rendering frame in terminal
From: |
Akib Azmain Turja |
Subject: |
Re: Questions on glyph matrices used for rendering frame in terminal |
Date: |
Tue, 05 Jul 2022 10:26:29 +0600 |
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>
>> 1. What's the purpose of the following in
>> build_frame_matrix_from_leaf_window? "frame_row->used[TEXT_AREA]" will
>> always end up being equal to "window_matrix->matrix_w" after processing
>> the right-most window of the row.
>
> I don't understand. What about the /matrix_x/ + matrix_w below?
Oh sorry, I meant "it will end up being equal to
*frame_matrix->matrix_w*".
>
>>
>> --8<---------------cut here---------------start------------->8---
>> /* Set number of used glyphs in the frame matrix. Since we fill
>> up with spaces, and visit leaf windows from left to right it
>> can be done simply. */
>> frame_row->used[TEXT_AREA]
>> = window_matrix->matrix_x + window_matrix->matrix_w;
>> --8<---------------cut here---------------end--------------->8---
>>
>>
>> 2. From the documentation of make-terminal-frame:
>>
>> > Note that changing the size of one terminal frame automatically
>> > affects all frames on the same terminal device.
>>
>>
>> But why? Do they share glyph matrices, since only one of them is
>> visible at a single time?
>
> How else should other frames behave? Leave a "hole" on the terminal where
> nothing is displayed when the TTY window is made larger? And what if the
> terminal is made smaller?
The documentation says that something will happen, but I don't know
since I have never tried to do that.
>
>>
>>
>> 3. Why clear the desired matrix in build_frame_matrix? As I understand,
>> that would clear the glyph matrices of windows the frame, because window
>> desired matrix shares memory with frame desired matrix, and its seems
>> like build_frame_matrix is called after window desired matrices are
>> built.
>>
>> --8<---------------cut here---------------start------------->8---
>> /* Clear all rows in the frame matrix covered by window matrices.
>> Menu bar lines are not covered by windows. */
>> for (i = FRAME_TOP_MARGIN (f); i < f->desired_matrix->nrows; ++i)
>> clear_glyph_row (MATRIX_ROW (f->desired_matrix, i));
>> --8<---------------cut here---------------end--------------->8---
>
> In the TTY case, the glyph memory (struct glyph) for desired window matrices
> is sub-allocated from the glyph memory that is allocated for the frame. The
> glyph_row structures on the other hand are different between windows and
> frame. Clear_glyph_row doesn't affect the glyph memory, only the glyh_rows.
I can't understand. What does that glyph memory contain? Individual
glyphs or the glyph matrix? If the glyph memory holds the glyph matrix,
then IIUC glyph row is a row of that glyph matrix, so why clearing that
doesn't affect the glyph matrix?
>
>>
>>
>> 4. And one more question: why don't Emacs is use the window feature of
>> ncurses despite depending on it? Is it inefficient or lack of any
>> feature?
>>
>
> The reasons I can think of are
>
> - ncurses is considerably younger than Emacs
> - Its predecessor 'curses' (from BSD, IIRC) wasn't available everywhere
> (think VMS, MS-DOS, maybe others), when that part of the code was written. I
> would guess that might have been around 1985. What would that be - Emacs 16
> :-).
>
> Maybe there are also other technical reasons that make a rewrite with ncurses
> impossible, I don'T know.
>
> (And there's of course always the consideration of why rewrite something that
> works.)
No, I'm not saying to rewrite, just wanted to know.
>
>
>
--
Akib Azmain Turja
This message is signed by me with my GnuPG key. It's fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
signature.asc
Description: PGP signature