Re: Rethinking the design of xwidgets

[Eli Zaretskii]

> From: Akira Kyle <ak@akirakyle.com>
> Cc: qhong@mit.edu, emacs-devel@gnu.org
> Date: Tue, 13 Oct 2020 15:00:18 -0600
> 
> >> Is it possible to display a slider which can be dragged by the
> >> mouse to update values on the plot or have a drop down menu to
> >> select a data series?
> >
> > You'd need to regenerate the plot with the updated values.
> 
> What if the computation that generates the plot is expensive?

We don't need to worry about that until we actually see it's
expensive.  No premature optimizations, remember?

> I think my point is more that a gtk widget already does all of this,
> so rather than reimplementing such functionality between python and
> elisp which will only be useful for one specific python plotting
> library, why not have the ability to display the dynamic widget of
> any given plotting library?

Yes, it's tempting to reuse functionality that someone else developed,
but let's not forget the flip side: the need to integrate such objects
into the Emacs display code.  If that integration is hard, or if it
imposes serious limitations on displaying buffers with such objects,
we need to consider the pros vs the cons.

> >> It seems it may also be difficult to find a way to have elisp
> >> interact with the matplotlib fast enough to not introduce
> >> noticable delay as such actions update the view.
> >
> > And doing this via a module that is called by a widget won't bump
> > into the same problems?  After all, all the interaction with Emacs
> > goes through the same mechanism, no matter what the callback does.
> 
> I don't think so. In this case the user events don't have to go 
> through elisp, they can go directly through the GUI toolkit to 
> code behind it.

How is this possible?  You will intentionally exempt these events from
the "normal" Emacs customizations, keymaps, etc.?  You believe users
will let us do that?

> My experience is that elisp is pretty poor at handling real time
> events.

The input events in Emacs are handled in C, not in Lisp.  The C code
is part of the Lisp machine, but it isn't in Lisp, at least not its
lower layers.