Re: Removing the `window-id' frame parameter on non-Core Input platforms

[Akira Kyle <akira@akirakyle.com>]

On Mon, Dec 20, 2021 at 9:38 PM Po Lu <luangruo@yahoo.com> wrote:
>
> > I would argue that most users would expect scrolling an xwidget webkit
> > buffer that is visible in two windows to behave like eww, not like
> > advancing a frame in a GIF.  That paradigm being that each window is a
> > separate view into a buffer where the position in the buffer that the
> > window displays is independent of any other window (ie is window
> > local).
>
> The only paradigm I see is that a single glyph (such as an xwidget
> glyph, produced by a display property) should be able to display in
> multiple windows, which this implementation (and the GIF display as
> well) fulfils.

Yes that's the obvious paradigm with respect to the implementation
details of emacs' display. I'm trying to argue purely in terms of what
a user might expect given the way normal text buffers behave in emacs.
With an xwidget webkit window where the single glyph is sized to
always fill the window (however it often gets confused on which window
to size when there are multiple windows of different sizes displaying
it), as a user I don't know or care that the window is only displaying
a single glyph. I see what looks like a window displaying a buffer's
contents in a pretty way (just like eww or doc-view), then I would
expect the mechanics of scrolling to be similar, however I am
surprised when they don't behave in the way I've come to expect for
other emacs modes that display some "rendered" version of the raw
buffer contents.