Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[Stefan Monnier]

>> The question is what benefit is there to having it linked in as
>> a library as opposed to accessing similar functionality via
>> a sub-process.
> One could programmatically render stuff on top of the video;

Sounds highly hypothetical.

> I mean you could code a renderer for video just as you made svg
> renderer; but somebody already created a re-usable, well tested
> library, so why recreate what is already done and tested.  That is how
> I think of it.

Same here: just linking libmpv doesn't magically let you do those things.

Until such things are more concrete, it's hard to justify linking a library.

The emacs-application-framework is an example of what you can do with
sub-processes.

> Yeah, I know; but just playing music is a little bit of playing with a
> closed box. And it does not work with video. Also as I said it is a bit
> about efficiency. I think it would be useful for Emacs to play sound
> files and video files natively.

Yet there are also packages which let you play videos from Emacs, so
it's not limited to music.

> For me Emacs is long past just text editor; for me it is more like an
> über-terminal or we could call it OS-browser ... I don't know.  Just how
> I use it, I understand if others use Emacs differently.

I think this description applies to pretty much all of us here.  It does
not imply that linking is necessarily the better path.

Linking libraries into Emacs tends to be tricky, costly, and come with
a fair bit of consequences, so it needs to justified by fairly
solid evidence.  Linking them via the module interface can be a good
middle-ground BTW.


        Stefan