Re: [Emacs-diffs] xwidget updated (1d8b8a2 -> 5f46725)

[Eli Zaretskii <eliz@gnu.org>]

> From: joakim@verona.se
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 29 Dec 2014 10:48:00 +0100
> 
> I'm extatic that you found time to review it! Thanks Eli!

That's the least we could do to help you finish the job.

> > 5) xdisp.c:produce_xwidget_glyph needs to account for bidirectional
> >    display in the same way produce_image_glyph does: swao the left and
> >    right box edges, and populate the bidi members of struct glyph.

> I havent thought about bidi at all.

Just look at what produce_image_glyph does, it should tell you enough.

> Do you have a simple test case [for bidi]?

Type a few Arabic or Hebrew characters, then insert a widget, then
type some more Arabic or Hebrew.  Try this both in a buffer that has
bidi-paragraph-direction set to nil and in a buffer that has it set to
left-to-right or right-to-left.

> > 6) Did you test what happens with xwidgets when the lines are
> >    truncated, and only part of the xwidget fits on the line?  Are the
> >    results reasonable?  I see that produce_xwidget_glyph does attempt
> >    to crop the xwidget to fit in the line, but then display_line
> >    should handle xwidget glyphs the same as it does with image glyphs,
> >    when it decides how to go about truncation/continuation.
> 
> Truncation works same as for an image, which I think is reasonable. Or
> did you mean something else?

No, this is what I meant.

> I dont understand your comment about display_line.

My comment has to deal with truncation marks, when the lines are
truncated and the widget gets truncated as result.  Around line 20690
in xdisp.c (this is from master; the number could be different on your
branch), you will see this code fragment:

      /* If we truncate lines, we are done when the last displayed
	 glyphs reach past the right margin of the window.  */
      if (it->line_wrap == TRUNCATE
	  && ((FRAME_WINDOW_P (it->f)
	       /* Images are preprocessed in produce_image_glyph such
		  that they are cropped at the right edge of the
		  window, so an image glyph will always end exactly at
		  last_visible_x, even if there's no right fringe.  */
	       && ((row->reversed_p
		    ? WINDOW_LEFT_FRINGE_WIDTH (it->w)
		    : WINDOW_RIGHT_FRINGE_WIDTH (it->w))
		   || it->what == IT_IMAGE))
	      ? (it->current_x >= it->last_visible_x)
	      : (it->current_x > it->last_visible_x)))
	{
	  /* Maybe add truncation glyphs.  */

It currently treats specially only image glyphs, for the reasons
explained in the comment.  Based on your response and on what I saw in
the code, the xwidget glyphs should be handled in the same manner
there.

To see this code in action, turn on truncate-lines, disable the
fringes, and see if you get the truncation glyph when the line ends in
an xwidget (you shouldn't).

> Eli, how difficult do you suppose it would be to get a GTK3 emacs
> running on Windows?

I don't know.  A Windows port of GTK3 does exist (see
http://www.gtk.org/download/win32_tutorial.php), but the GTK related
code in Emacs was never tried on Windows, so Someone(TM) will have to
get their hands dirty before it will work.  I'm guessing that the
event loop will give that Someone the most grief, unless the GTK folks
already solved that.

Alternatively, Someone Else(TM) could port your xwidget code to the
corresponding Windows features, but it will take a Windows GUI expert
to do that, and I don't think we have such a person on board.

> And thanks again for the review!

You are welcome.