Re: Rethinking the design of xwidgets

[Eli Zaretskii <eliz@gnu.org>]

> From: Akira Kyle <ak@akirakyle.com>
> Date: Mon, 12 Oct 2020 14:58:19 -0600
> 
> One of my primary uses of emacs is as a scientific notebook 
> utilizing org mode's support for literate programming to 
> interweave prose, LaTeX, and code. I find this to be far more 
> powerful and comfortable than using the Jupyter notebooks which 
> have quickly become incredibly popular for such scientific 
> computing. However the biggest pain point I have is due to Emacs' 
> relatively poor capabilities for interfacing with objects other 
> than text. Sure Emacs can display images ok, but I'm not aware of 
> any way to get emacs to display more dynamic content.

Can you tell more about the dynamic content you had in mind, and why
you thought to use xwidgets as the basis for that?  There's IMO a leap
of logic here that I cannot follow, perhaps because I don't have the
necessary background information.

From my POV, xwidgets have several problems which don't allow me to
easily see them as the basis for some much more general set of
features or infrastructure:

  . they depend on GTK and webkit, whose development leaves a lot to
    be desired, and some say parts of that have no future; they are
    definitely less portable than I'd like to see in Emacs

  . their integration in the Emacs display code "needs work", there's
    at least one or two places where the code which handles them is
    clearly wrong -- this is semi-okay for a minor niche feature, but
    not for something on which we want to build our future

So before we decide that xwidgets is the way to go, I'd like to make a
step back and see what other alternatives we can think of, if any, and
carefully consider which alternative is best in the long run.

> That leads me to my following proposal to rethink the design of 
> xwidgets. Given that Emacs now has support for dynamic modules and 
> it is now enabled by default, I propose exposing an interface for 
> dynamic modules to define custom xwidgets. I believe this would be 
> a good way to solve the two fundamental issues with the current 
> xwidgets implementation that I described above. Having a well 
> defined interface means one wouldn't have to deal with debugging 
> subtle redisplay and lisp interpreter issues when creating a 
> custom xwidget type. Furthermore any external library needed for a 
> custom xwidget type will only be required if one chooses to use 
> that xwidget type and would keep such dependencies out of Emacs 
> itself.

Here, too, I'd like first to consider a design that doesn't require
dynamic modules as a prerequisite for the feature.  If we can come up
with something that requires only Lisp (like image display does, for
example), then I think we all win, because it is much easier to write
a Lisp package than a package that requires a module in C or similar
language.

Bottom line, I'd like to understand the problem you are trying to
solve better before we conclude that xwidgets and dynamic modules are
the way to go.

Thanks.