[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency, again
From: |
Perry E. Metzger |
Subject: |
Re: Concurrency, again |
Date: |
Mon, 17 Oct 2016 13:53:53 -0400 |
On Mon, 17 Oct 2016 19:57:37 +0300 Eli Zaretskii <address@hidden> wrote:
> > > > Imagine, though, if in the not too distant future Emacs is
> > > > used by many of us as our web browser thanks to Webkit
> > > > integration. That might change the game a lot.
> > >
> > > Asynchronous network communications are supported already on
> > > master, so I'm not sure what problems you see in that
> > > direction.
> >
> > Every open browser tab (should I say "window", this being emacs?)
> > can potentially be doing all sorts of computation in the
> > background via JavaScript, and that could potentially momentarily
> > hang the editor if they're sharing an underlying thread.
>
> So you are saying the problem is only with URLs that invoke
> JavaScript? Good.
Well, active content like video or audio too. For good or ill, though,
active content is now most of the web. Also, the line between
JavaScript and active content (like HTML5 video) is often thin. If one
wanted to have Emacs be a truly effective browser, it would need the
ability to deal with this. Someone might want to watch HTML5 video in
one Emacs window while reading their mail in another, and why
shouldn't they want to be able to do that? The video might even have
been embedded in one of their mail messages.
I think having Emacs be a truly effective browser is a very useful
goal btw., especially since Webkit, which is already free software,
can do all the hard stuff. The idea of being able to isearch inside
the web page of a blog, mark and copy a short program out of a
posting, c-x o, and yank it, is really tantalizing. I love the idea of
never having to leave emacs again.
Of course, one could do something like wrapping the Webkit instances
in subprocesses, which might not be awful from an isolation
viewpoint. Still, that leaves the question of how to handle the
interaction with such a thing.
I suppose part of the problem here is that the existing Emacs
implementation goes back to an era before such things could have even
been contemplated. This might be what one would want out of Emacs but
it is not what the current code was built to do.
Perry
--
Perry E. Metzger address@hidden
- Re: Concurrency, again, (continued)
- Re: Concurrency, again, Ken Raeburn, 2016/10/17
- Re: Concurrency, again, Stefan Monnier, 2016/10/17
- Re: Concurrency, again, Stefan Huchler, 2016/10/14
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Eli Zaretskii, 2016/10/17
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Eli Zaretskii, 2016/10/17
- Re: Concurrency, again,
Perry E. Metzger <=
- Re: Concurrency, again, Lars Ingebrigtsen, 2016/10/17
- Re: Concurrency, again, Stefan Huchler, 2016/10/17
- Re: Concurrency, again, Lars Ingebrigtsen, 2016/10/18
- Re: Concurrency, again, Eli Zaretskii, 2016/10/18
- Re: Concurrency, again, Lars Ingebrigtsen, 2016/10/18
- Re: Concurrency, again, Eli Zaretskii, 2016/10/18
- Re: Concurrency, again, Lars Ingebrigtsen, 2016/10/18
- Re: Concurrency, again, joakim, 2016/10/18
- Browsers inside Emacs (was Re: Concurrency, again), Perry E. Metzger, 2016/10/18
- Re: Concurrency, again, Stefan Huchler, 2016/10/18