Re: SVG widget in GNU Emacs

[Akira Kyle]

On Wed, Oct 20, 2021 at 8:28 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > > Apart of the above, just look at xwidget.c and xwidget.el, and you
> > > will see the FIXMEs, the incomplete doc strings, and other stuff left
> > > unfinished.  The idea was that those will get finished once the
> > > feature is in the sources, but unfortunately it didn't happen.
> >
> > Indeed, I see your point.  Thanks.
> >
> > I will probably work on this once I get the time.
>
> Thanks, cleanup in that area will be appreciated.

IMHO the current xwidget implementation in emacs should deprecated. A
year ago I spent some time digging into all of this and the result was
my proof of concept emacs module that implemented the webkitgtk
functionally independent of xwidgets, called emac-webkit
(https://github.com/akirakyle/emacs-webkit and there's a thread that I
started here about a year ago to discuss this). The webkitgtk part of
xwidgets really is the only functional part, since the buttons and
other widgets have only an incomplete lisp interface and
implementation.

Po, if you're seriously considering cleaning up this code, it might be
wise to take a step back and consider what features its trying to
provide and how. There's a fundamental tension between the
buffer/window model of emacs and the way gtk implements a MVC paradigm
that makes it nontrivial for them to be compatible. This situation has
only worsened as gtk has been moving its api's to better support a
future with heavy reliance on gpu rendering. IIRC this means the
offscreen rendering technique employed by xwidgets is being deprecated
in gtk. Furthermore xwidgets was implemented before webkit was
transitioned to a containerized worker process architecture so there's
bugs one has to work through as gtk attempts to take back control of
things like signal masks that emacs controls when it initializes gtk.
My impression has actually been that the nsxwidgets have worked far
better and reliably since that was merged (in fact I remember coming
across some emacs package out there that relied on xwidgets, but that
only supported it on macOS as something or another was broken with
xwidgets on gtk). I suspect the transition from x11 to wayland has
introduced a lot of bugs and difficulties for really complex gtk
widgets like webkitgtk.

Ultimately I'd rather see effort go into getting pure gtk merged and
working to eliminate the mess of inpure mixtures of gtk and x11 code
from emacs (there could of course still be a "pure" X backend for
those who desire to run emacs with motif). I think as time goes on, it
will look worse and worse for emacs to need xwayland to run, as
distributions will stop including it by default.

Also I think there's a lot of work to be done on xdisp.c. As I've seen
here and elsewhere, there seems to be sustained interest in richer,
flexible display options to support things like multicolumns or
buffers in buffers without resorting to clever hacks that work around
around the limitations of the current linear character arrays that
emacs represents buffer data as. Browsers with the DOM have obviously
already solved this problem in a very general way, and it's quite
popular these days to leave such complexity and optimization effort to
the browser engine devs and use something like electron. I doubt the
emacs devs or maintainers would ever consent to running emacs on top
of chromium or webkit (although there's already the effort to have
emacs run on servo here https://github.com/emacs-ng/emacs-ng but that
just adds servo as a gui toolkit and doesn't attempt to touch
xdisp.c). So that leaves it to someone to really understand xdisp.c
enough to extend it in such a way that maintains the optimizations
people care about for text terminals, while allowing richer data
structures to be displayed efficiently by the modern gui toolkit
paradigms. No easy task.

Sorry for the long reply. I end up thinking about this topic whenever
I get frustrated with emacs' display engine. I wish I had the time to
work on this, but alas I've started grad school and don't even have
time to work emacs-webkit much.