Re: Implementing child frames on terminal

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

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Akib Azmain Turja <akib@disroot.org>
>> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>>  ibluefocus@outlook.com
>> Date: Wed, 13 Jul 2022 23:55:09 +0600
>> 
>> > You mean, the display margins?  If that is the problem that bothers
>> > you, then yes, the functions in dispnew.c that calculate the
>> > dimensions of each window will have to take the clipping into account.
>> > And again, this calculation happens just once, in the beginning of a
>> > redisplay cycle, and only if needed (i.e. only when the previously
>> > calculated dimensions no longer fit).
>> >
>> > But last_visible_x will still need to be adjusted as I outlined,
>> 
>> I don't think so.  I tried to hard-code last_visible_x to 40.  Then I
>> compiled and started Emacs and found that the lines of *scratch* buffer
>> wrapped at 39th column (and the 40th column being the continuation
>> glyph).
>
> Right.  You just discovered that setting last_visible_x is not the
> only thing that should be done.  But I never said it's the only thing,
> just that it is _one_ thing that needs to be done.  Changing the code
> which produces the continuation/truncation glyphs to support child
> frames is not hard, but it does need some coding.  And there really is
> no way around that, because that's how Emacs display works.
>
> Remember: this all came out of discussions about the design of child
> frames on TTY displays, where you expressed doubt that we could easily
> "clip" child frames where needed.  But that basic design is just the
> beginning; there's more to this than meets the eye.
>
>> It seems that line numbers are also unaffected by that
>> last_visible_x.
>
> Yes, they are.  From maybe_produce_line_number:
>
>   /* We must leave space for 2 glyphs for continuation and truncation,
>      and at least one glyph for buffer text.  */
>   int width_limit =
>     tem_it.last_visible_x - tem_it.first_visible_x
>     - 3 * FRAME_COLUMN_WIDTH (it->f);
>   [...]
>       PRODUCE_GLYPHS (&tem_it);
>
>       /* Stop producing glyphs, and refrain from producing the line
> 	 number, if we don't have enough space on this line.  */
>       if (tem_it.current_x >= width_limit)
> 	{
> 	  it->lnum_width = 0;
> 	  it->lnum_pixel_width = 0;
> 	  bidi_unshelve_cache (itdata, false);
> 	  inhibit_free_realized_faces = save_free_realized_faces;
> 	  return;
> 	}
>
>> > Why produce glyphs that will never get written to the glass?  It's
>> > just a waste of cycles.  And it isn't for free: we'd need to have code
>> > that checks whether a glyph should or shouldn't be written to the
>> > screen, because writing it outside of the terminal could have bad
>> > effects.
>> 
>> IIUC, we won't need additional code.  Because those garbage glyphs are
>> outside of the frame's glyph matrix, so the terminal display code won't
>> notice them at all.
>> 
>> I think we are all trying to do premature optimization.  Do we bother
>> whether a character is clipped on X?
>
> On X, the clipping is a given.  But on text-mode terminal there's no
> clipping: if you write one character too many on a line, it will
> generally wrap to the next line.

There is definitely a misunderstanding here.  Nothing is going to write
outside of the terminal, because the size of the top-level frame's
matrix is the same as the size of the terminal.

My idea is that we write the glyphs to the glyph matrix anyway, and then
decide which glyphs to show on the glass later.

>
>> Or is there any real reason to optimize?
>
> It isn't an optimization, it's safe coding.

You misunderstood my question.  I meant: is there any real reason to
share the glyph memory of the parent and the child frame?  We can just
copy the visible part of child frame matrix to parent frame matrix,
which IMHO won't cause any noticeable slowdown compared to X.

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