Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[Akira Kyle <akira@akirakyle.com>]

On Mon, Nov 30, 2020 at 11:11 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

>> > No complexity at all, it's almost trivial, because the 
>> > display
>> > code already does that.  As for "satisfactorily" part: what 
>> > can be
>> > unsatisfactory about displaying the widget on the next screen
>> > line?
>> 
>> That's fine, and would be the expected behavior when lines are 
>> supposed to wrap. But when lines are not wrapped, I would not 
>> expect a display element to disappear as soon as one pixel of 
>> it 
>> exceeds the window border.
>
> And yet that's exactly what happens with other display elements, 
> for
> example wide characters on TTY display.
>
> Again, AFAIU we are talking about rare use cases, which you said
> cannot be displayed in any other way, so what do you expect 
> Emacs to
> do in such restrictive situations??
>
>> Already I find the way redisplay doesn't like to display images
>> clipped at the top of the window jarring.
>
> Not sure what you are talking about, but I'm sure whatever is 
> jarring
> can be fixed by relatively simple augmentations to the display 
> code.
>
>> If I wanted to zoom into the widget if it was displaying 
>> something
>> detailed, I wouldn't want it to suddenly disappear.
>
> It doesn't have to, we can scroll the window instead, so that 
> the
> enlarged widget is brought into the viewport.
>
> Again, what else do you expect Emacs to do when you yourself 
> said
> these widgets don't allow any other solution??
>
>> I think Emacs needs to be able to clip the elements its 
>> displays in
>> order to not end up with what I would call surprising and
>> frustrating behavior.
>
> But you yourself said this is not allowed in these cases, so how 
> can
> Emacs do what is not allowed??
>
>> >> What if `window-resize-pixelwise` or 
>> >> `frame-resize-pixelwise`
>> >> non-nil and the element is on the last, partially clipped 
>> >> line?
>> >
>> > We don't display it.  How is this different from a any other 
>> > large
>> > display element that cannot be shown in the viewport?
>> 
>> Images are the only other large display element that I'm aware 
>> of 
>> and images are clipped in such cases
>
> But you yourself said that clipping these widgets is impossible. 
> What
> am I missing in this discussion?

Sorry we've gotten a bit off the original point. I was trying to 
illustrate that for such "rich" display elements clipping would 
seem to be a necessity in order to avoid surprising or frustrating 
behavior. I understand Emacs can work around an element that 
doesn't permit being clipped, but it will be exactly that -- a 
work around to a problem Emacs shouldn't have solve. Thus clipping 
has to happen on the GTK side, which isn't impossible, but 
requires additional complexity. Overriding Widgets so they can be 
clipped is yet another example of trying to draw GTK widgets in 
ways they weren't intended to be drawn (and the GTK folks would 
probably consider this all very bad practice).

My whole point is that I've become more convinced that trying to 
integrate GTK widgets into Emacs redisplay isn't a good way to 
achieve the desired functionality and it would be worth exploring 
other, more portable solutions. I don't think we need to continue 
discussing the finer points on clipping.