Re: Implementing child frames on terminal

[Eli Zaretskii <eliz@gnu.org>]

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

> Or is there any real reason to optimize?

It isn't an optimization, it's safe coding.