Re: Rethinking the design of xwidgets

[Akira Kyle]

Sorry I missed this when replying to all the other subthreads 
earlier.

On Wed, Oct 14, 2020 at 08:44 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

> > >> 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 didn't mean the code that actually draws the plot the, but 
rather the computation that was run to generate the data that the 
plot is displaying as in principle that could be very expensive, 
which is why I was talking about having to cache the data that the 
plot is working from. 

> > 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.

Certainly. I just have yet to be convinced that the integration is 
so hard or would be so limited that it isn't worth the effort to 
try, but then again, I haven't been working on this for a very 
long time.

> > >> 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?

I should have clarified that I was referring only to actions with 
the mouse (or pen input if one wanted to draw) where latency is 
often far more noticeable, and there is less of a reason for Emacs 
to intercept the mouse actions. I think there would be very few, 
if any, instances where an xwidget would want to capture keyboard 
events. But I think the point is that each xwidget has both the 
power and responsibility to determine which events to handle 
itself and which to let Emacs handle and I imagine that decision 
will be informed by the which events for which latency is critical 
- such as drawing on a canvas.

> > 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.

I meant that when the input event must be processed by elisp code 
which then subsequently does something with that event, it can 
potentially add considerable latency, and one must be careful to 
ensure that non-deterministic behavior such as garbage collection 
is controlled.