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

[Akira Kyle <akira@akirakyle.com>]

On Mon, Dec 20, 2021 at 6:15 PM Po Lu <luangruo@yahoo.com> wrote:
>
> > But even with a buffer showing an image, I can scroll it independently
> > in two windows, so xwidgets don't even behave like images.
>
> If you play a GIF that depicts a scrolling WebKitWebView, you can't
> really "scroll" it independently either.  Ditto for xwidgets.

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. In fact I would further argue that the way
emacs handles displaying a GIF also does not fit the paradigm for
emacs buffers and windows. 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). If, for a GIF, I reasonably say that a buffer's position in a
GIF should be its frame number, then I would expect the above
buffer-window paradigm to hold. Yet currently it does not. This in
contrast to what I would say would be a conceptually similar situation
in doc-view which does obey this paradigm.