Re: Implementing child frames on terminal

[Akib Azmain Turja <akib@disroot.org>]

[-- Attachment #1: Type: text/plain, Size: 3269 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> But this problem is different than that.  In your too-long line case,
>> redisplay code checks whether a glyph is inside the window.  But for
>> child frames, it needs to check whether a glyph is inside the parent
>> frame (i.e. safe to write to), write it if it is and always assume
>> that it was written successfully.
>> 
>> For example, if we have a 30 chars wide child frames displaying a 40
>> chars wide line and the child frame's left edge is 20 char away from
>> it's parent right edge, the redisplay code has to write the first 20
>> chars to the glyph matrix and don't write the next 10 chars, but still
>> think that they were written, and finally truncate the last 10 chars or
>> wrap it depending on the value of "truncate-lines".
>
> The way redisplay of a window works, it starts by determining how wide
> can each screen line be before it overflows the right edge of the
> window.  The result of this is the member of 'struct it' called
> 'last_visible_x'.  It is computed once (see init_iterator), and then
> used everywhere when we need to decide whether there's place in the
> screen line for one more glyph.
>
> So to support the above, we'd just need to modify the calculation of
> last_visible_x in init_iterator such that it takes into consideration
> the edge of the parent frame.  And that shouldn't be hard, given that
> we know the offset of the child frame from its parent frame.
>

What do you mean?  Set last_visible_x to the last x position not
clipped?  That won't work, since last_visible_x has no effect on
margins AFAIK.  Same for first_visible_x.

I have another idea, we can make the glyph matrix memory larger than the
top-level (i.e. not a child) frame:

--8<---------------cut here---------------start------------->8---
+--------------------------------------+
|+------------------------------------+|
||                                    ||<<< glyph matrix memory
||<<< frame glyph matrix              ||
||                                    ||
||                                    ||
||                                    ||
||    +-----------------------------+ ||
||    |<<< child frame glyph matrix | ||
||    |                             | ||
|+----|.............................|-+|
|     |                             |  |
|     +-----------------------------+  |
+--------------------------------------+
--8<---------------cut here---------------end--------------->8---

According to the figure above, rendering glyphs for part of child frame
outside the top-level frame's edges won't cause any error because it
will write to allocated memory, but still those glyph won't appear on
the glass because they are outside the glyph matrix of the top-level
frame.  This technique won't allow to clip a nested child frame to the
edges of it parent (which is also a child frame) and also wastes some
memory, however.

Do you have a list of functions that directly writes to glyph matrix?
It is much easier to work with function than to work with dynamic
memory.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]