Emacs in a Chrome Tab? (related to NaCl Support for Emacs discussion)

Emacs in a Chrome Tab? (related to NaCl Support for Emacs discussion)

[Paul Michael Reilly]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

My curiosity peaked recently with the thread on NaCl support for Emacs.
 Not having a clue what NaCl was all about, I took to Google to find out
more.  And if I read it right, it is all about having a HTML/Javascript/CSS
wrapper around a C/C++ native code application running in the browser.
 Very cool in its own right but simply awesome if that wrapped code happens
to be Emacs.  The NaCl Support for Emacs discussion seems to be focused on
security/library  (crypto) issues which tend to make my brain hurt so a new
thread seems appropriate to discuss this notion of Emacs running in a
Chrome tab.  For all I know the current NaCl thread might be a totally
different NaCl thing than NativeClient.

I raised this issue last year (Emacs in the Cloud) but I don't recollect
any mention of NativeClient at that time.  The notion of opening up a new
machine, installing Chrome (if it is not already installed), heading off to
the Chrome Web Store to get the latest NaCl version of Gnu Emacs, and then
using an Emacs tab to edit files/run shells/install ELPA packages is very
appealing to me.

Is anyone aware of technical "gotchas" that make this notion unrealizable
by a mere mortal in just one lifetime?

-pmr

[-- Attachment #2: Type: text/html, Size: 1301 bytes --]

Re: Emacs in a Chrome Tab? (related to NaCl Support for Emacs discussion)

[Antoine Levitt]

09/01/12 21:41, Paul Michael Reilly
> My curiosity peaked recently with the thread on NaCl support for
> Emacs.  Not having a clue what NaCl was all about, I took to Google to
> find out more.  And if I read it right, it is all about having a
> HTML/Javascript/CSS wrapper around a C/C++ native code application
> running in the browser.
>  Very cool in its own right but simply awesome
> if that wrapped code happens to be Emacs.  The NaCl Support for Emacs
> discussion seems to be focused on security/library  (crypto) issues
> which tend to make my brain hurt so a new thread seems appropriate to
> discuss this notion of Emacs running in a Chrome tab.  For all I know
> the current NaCl thread might be a totally different NaCl thing than
> NativeClient.

It is. NaCl is a crypto lib, see http://nacl.cr.yp.to/

> I raised this issue last year (Emacs in the Cloud) but I don't
> recollect any mention of NativeClient at that time.  The notion of
> opening up a new machine, installing Chrome (if it is not already
> installed), heading off to the Chrome Web Store to get the latest NaCl
> version of Gnu Emacs, and then using an Emacs tab to edit files/run
> shells/install ELPA packages is very appealing to me.
>
> Is anyone aware of technical "gotchas" that make this notion
> unrealizable by a mere mortal in just one lifetime?

Isn't that an issue to be tackled by the window managers? Why would it
be emacs-specific? I'm not sure I see the point anyway.

Re: Emacs in a Chrome Tab? (related to NaCl Support for Emacs discussion)

[Paul Michael Reilly]

[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]

On Mon, Jan 9, 2012 at 4:08 PM, Antoine Levitt <antoine.levitt@gmail.com>wrote:

Isn't that an issue to be tackled by the window managers? Why would it
> be emacs-specific? I'm not sure I see the point anyway.
>

Window Managers?  Maybe you missed my point.

A little history: for years engineers from coast to coast (me on the East
and Steve Yegge on the West) have primarily used two tools every day: Emacs
and (some) Browser (Chrome for Steve and I).  Steve once asked the pointed
question: Wouldn't it be great if Emacs could browse (taking for granted
that Emacs w3 doesn't count as a real browser) or a Browser could do what
Emacs does?  I answered the question with a definite Yes and posited that
Emacs will never provide a real WWW browsing experience, at least not in
our lifetime and not in Gnu Emacs' current implementation.  So clearly that
leaves Emacs to run inside the Browser.  But this was clearly not a
priority with the Brpwser developers so the two wonderful tools have lived
apart lo these many years.  With the advent of NativeClient, there is now a
more likely path to realizing Emacs functionality inside a browser tab but
that path could be filled with all kinds of roadside bombs that will make
it impossible to get there from here.  To me this means targeting Gnu Emacs
to build on a "NativeClient" platform and thus producing a set of bits that
will be found in an App Store like the Chrome Web Store.

Another relevant piece of history:  I tried using a ChromeBook device last
year.  Other than the fact that they were under powered and I could not run
Emacs on them, it is a great model --- no machine maintenance, cheap, easy
access to apps (lots of freely available software) and a very simple
interface.  Emacs in a tab would make a ChromeBook much more attractive.
 And Emacs in a tab would be able to leverage browser APIs to a much higher
degree than we see in Emacs out of a tab.  Now it might be the case that
you don't see the point in a ChromeBook device or Chrome OS software model.
 If so you can take comfort in the fact that that probably puts you in a
90% category.  But then, on the other hand, didn't IE own 90% of the
browser market a short while ago? :-)

-pmr

[-- Attachment #2: Type: text/html, Size: 2616 bytes --]

Re: Emacs in a Chrome Tab? (related to NaCl Support for Emacs discussion)

[chad]

NativeClient is mostly about using the local processor to cut out server round-trips for computations.  Unfortunately for your idea, it doesn't address the idea of the display engine; native client nexe's are expected to use the browser's ui.  There is some experimental 3D support for nexe's via their alternative to NSAPI, but this is far enough away from Emacs that a port would be complex.  For your goals, I'd guess that xembed (ala the xembed branch) is an easier practical path to a prototype.

This idea, like Tom Tromey's `rebase emacs on Common Lisp', Steve's `Emacs in JavaScript', and the various Guilemacs attempts point out (yet again) something I would not have guessed when I started with emacs ~22 years ago: while the most technically valuable piece of Emacs (aside from its freedom) is the extensive libraries of elisp code, the most critical piece is actually the display engine.  It's very hard to move Emacs anywhere that the display engine won't go, and it seems to be very hard to move the display engine.  

*Chad

P.S. This makes the herculean efforts of things like epoch, multi-tty, and bidi all the more impressive.  Thanks again to all the wonderful emacs hackers out there.

Re: Emacs in a Chrome Tab? (related to NaCl Support for Emacs discussion)

[Antoine Levitt]

09/01/12 22:56, Paul Michael Reilly
> On Mon, Jan 9, 2012 at 4:08 PM, Antoine Levitt
> <antoine.levitt@gmail.com> wrote:
>
>     Isn't that an issue to be tackled by the window managers? Why
>     would it
>     be emacs-specific? I'm not sure I see the point anyway.
>     
>
> Window Managers?  Maybe you missed my point.
>
> A little history: for years engineers from coast to coast (me on the
> East and Steve Yegge on the West) have primarily used two tools every
> day: Emacs and (some) Browser (Chrome for Steve and I).

I suspect that is the case of most "serious" emacs users.

>  Steve once asked the pointed question: Wouldn't it be great if Emacs
> could browse (taking for granted that Emacs w3 doesn't count as a real
> browser) or a Browser could do what Emacs does?  I answered the
> question with a definite Yes

I agree with that.

> and posited that Emacs will never provide a real WWW
> browsing experience, at least not in our lifetime and not in Gnu
> Emacs' current implementation.

I don't agree. Have you checked out the xembed branch, as well as the
ezbl project? That seems like the way forward to me.

>  So clearly that leaves Emacs to run
> inside the Browser.  But this was clearly not a priority with the
> Brpwser developers so the two wonderful tools have lived apart lo
> these many years.  With the advent of NativeClient, there is now a
> more likely path to realizing Emacs functionality inside a browser tab
> but that path could be filled with all kinds of roadside bombs that
> will make it impossible to get there from here.  To me this means
> targeting Gnu Emacs to build on a "NativeClient" platform and thus
> producing a set of bits that will be found in an App Store like the
> Chrome Web Store.

What I don't see is : how is it better to have emacs in a tab rather
than emacs in a window? If emacs/browser communication is what you need,
take a look at mozrepl.

> Another relevant piece of history:  I tried using a ChromeBook device
> last year.  Other than the fact that they were under powered and I
> could not run Emacs on them, it is a great model --- no machine
> maintenance, cheap, easy access to apps (lots of freely available
> software) and a very simple interface.  Emacs in a tab would make a
> ChromeBook much more attractive.

If you can't run emacs on it, NaCl probably won't help. The way I see
it, the solution is to open ChromeBook and such enough that the user can
actually run its own programs. Then, plug in some minimalist "window
manager" (a keybinding to toggle between chrome and emacs), and there
you go. Easy to implement, no messy developments on emacs side, and
works with every app (that can be ported to the platform).

Re: Emacs in a Chrome Tab? (related to NaCl Support for Emacs discussion)

[Paul Michael Reilly]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

Chad, this is an excellent reply.  Thanks,

-pmr

On Mon, Jan 9, 2012 at 5:42 PM, chad <yandros@gmail.com> wrote:

> NativeClient is mostly about using the local processor to cut out server
> round-trips for computations.  Unfortunately for your idea, it doesn't
> address the idea of the display engine; native client nexe's are expected
> to use the browser's ui.  There is some experimental 3D support for nexe's
> via their alternative to NSAPI, but this is far enough away from Emacs that
> a port would be complex.  For your goals, I'd guess that xembed (ala the
> xembed branch) is an easier practical path to a prototype.
>
> This idea, like Tom Tromey's `rebase emacs on Common Lisp', Steve's `Emacs
> in JavaScript', and the various Guilemacs attempts point out (yet again)
> something I would not have guessed when I started with emacs ~22 years ago:
> while the most technically valuable piece of Emacs (aside from its freedom)
> is the extensive libraries of elisp code, the most critical piece is
> actually the display engine.  It's very hard to move Emacs anywhere that
> the display engine won't go, and it seems to be very hard to move the
> display engine.
>
> *Chad
>
> P.S. This makes the herculean efforts of things like epoch, multi-tty, and
> bidi all the more impressive.  Thanks again to all the wonderful emacs
> hackers out there.

[-- Attachment #2: Type: text/html, Size: 1706 bytes --]

Re: Emacs in a Chrome Tab? (related to NaCl Support for Emacs discussion)

[Paul Michael Reilly]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Mon, Jan 9, 2012 at 6:26 PM, Antoine Levitt <antoine.levitt@gmail.com>wrote:

> 09/01/12 22:56, Paul Michael Reilly
> > On Mon, Jan 9, 2012 at 4:08 PM, Antoine Levitt
> > <antoine.levitt@gmail.com> wrote:
> >
> >     Isn't that an issue to be tackled by the window managers? Why
> >     would it
> >     be emacs-specific? I'm not sure I see the point anyway.
> >
> >
> > Window Managers?  Maybe you missed my point.
> >...
> > and posited that Emacs will never provide a real WWW
> > browsing experience, at least not in our lifetime and not in Gnu
> > Emacs' current implementation.
>
> I don't agree. Have you checked out the xembed branch, as well as the
> ezbl project? That seems like the way forward to me.
>

No, not yet but it would appear this xembed approach has merit.

Thanks,

-pmr

[-- Attachment #2: Type: text/html, Size: 1315 bytes --]