Re: Concurrency, again

[joakim@verona.se]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Huchler <stefan.huchler@mail.de> writes:
>
>> As far as I understand the xwidget webkit browser is "only" some sort of
>> a Client-server thing where you send messages from emacs to another
>> process and it then does stuff and sends maybe answers back.
>
> Yes.  It's pretty opaque.  I think it's possible to see a way to
> interact with these objects more naturally by creating a Javascript
> bridge that would expose the DOM fully to Emacs, and then you could
> rewrite all Emacs commands to do things to that DOM.  Like `C-t'
> (transpose-chars) with "point" inside one of these objects would look at
> the DOM around point, figure out the necessary changes, and then update
> the DOM inside the widget.
>
> And so on.
>
> But it would be...  er...  a major undertaking, and it would always be a
> toy.

The original idea was to implement a gobject introspection bridge
between elisp and gobjects. The beginings of such a bridge is in the
main xwidget branch. The main flaw with it atm is that it doesnt handle
complex types very well. That would require some work. Anyway, if the
bridge could be made to  work, you could use all functions of the gobject.

If I ever have the time to get back to working on the gobject
introspection bridge, I would try implementing it as an emacs module I
think, which some only minor modification to emacs core(I think you need to
do some initialization early on in emacs startup)

>
> And it's irrelevant to the concurrency discussion, really.  :-)

Yes, sorry.

>
>> Sorry I go OT, but the question is, does ewb need some
>> Concurrency? I guess not really cause the javascript stuff is more a
>> pain than a gain for most cases in such environment.
>
> I'm assuming you're referring to eww, and it sure does need concurrency.
> Computing complicated layouts can be slow, and it would be nice if it
> could take without stopping the user from doing other things.
-- 
Joakim Verona
joakim@verona.se
+46705459454