From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server Date: Tue, 14 Jun 2011 13:53:12 +1000 Message-ID: References: <87ei30k5xs.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016369f9ac59b47e304a5a3f97d X-Trace: dough.gmane.org 1308029518 27398 80.91.229.12 (14 Jun 2011 05:31:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Jun 2011 05:31:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Mohsen BANAN Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 14 07:31:54 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QWMED-0002Dz-51 for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2011 07:31:53 +0200 Original-Received: from localhost ([::1]:43538 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWMEC-0008Rc-9x for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2011 01:31:52 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWKgm-000121-5F for emacs-devel@gnu.org; Mon, 13 Jun 2011 23:53:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWKgk-0001WZ-0u for emacs-devel@gnu.org; Mon, 13 Jun 2011 23:53:15 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:45320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWKgj-0001WT-Nj for emacs-devel@gnu.org; Mon, 13 Jun 2011 23:53:13 -0400 Original-Received: by iyl8 with SMTP id 8so6058313iyl.0 for ; Mon, 13 Jun 2011 20:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gnc8U8be1863pVkg4udxp2VXStu1o1uuLgDKm/1K0oM=; b=Ln+fFlOw63OCtssULc6VPqqgJdzImUyj1J50TfyN9uwHlQsCMKoAetvCngJMSRwMa7 LT8xlcuASmGONOSRe4SoP92f7XvXkMCDn2PUJr9HVXTAx+iuPyigPBt/uS/6pKvQ/Ulv aA40NqYRtcmjizkq0HfuxMR0YtjFbqSlOPu1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gwd9/q0OGgkvQ2eSibsAb1AQlm2VCCFSXrUK2U3lq6qFmIrqbBZQeOl2FJxYgV+g2A 838JRfu3Wxh7A2f2S8QvOSZ2a23Hs/ELDnG88T07smZrRTY2UprreygTOYqHFgozq3yF /qqDOm+1QpSbrXiBbBvup++agyQ7269i+n09o= Original-Received: by 10.231.201.81 with SMTP id ez17mr4488079ibb.156.1308023592797; Mon, 13 Jun 2011 20:53:12 -0700 (PDT) Original-Received: by 10.231.32.72 with HTTP; Mon, 13 Jun 2011 20:53:12 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140450 Archived-At: --0016369f9ac59b47e304a5a3f97d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 13, 2011 at 2:53 PM, Mohsen BANAN < list-general@mohsen.1.banan.byname.net> wrote: > > >>>>> On Mon, 13 Jun 2011 12:09:23 +1000, Tim Cross > said: > > Tim> For emacs to really be a good desktop environment in this age, I > think it must > Tim> have the ability to provide access to rich web content - content that > uses > Tim> javascript, html5 etc. It would seem there are two possible > approaches to this > Tim> - do the necessary work in emacs or provide some mechanism that would > allow > Tim> emacs to access and possibly manipulate data that is already > partially > Tim> processed by a web browser such as firefox or chromium. > > This is right on the mark. > > And is consistent with what I meant earlier by > calling Emacs and Mozilla as joint sisters. > > Below are my notes for add-on packages that I > include in firefox to provide some level of > integration with emacs. > > The model of mozrepl is particularly promising. > > http://wiki.github.com/bard/mozrepl/ > > Mozrepl permits considering Mozilla as an emacs coprocess. > Where emacs can execute javascript inside of > mozilla. So, all we need is a lisp interpreter > written in javascript. We can then view Mozilla as > a renderer and an extension of emacs. > > I know that people have tried building a lisp > interpreter in javascript, but as far as I know > such a thing does not exist yet. > > I am very interested in knowing people's thoughts > on this approach. > > ...Mohsen > > > Hi Mohsen, thanks for the info, it will be useful. I do think this has some potential and worth looking at. I would also like to see what cold be done with chrome as I tend to favor it as a browser over firefox these days. The one thing I found when looking at this some time back was that the architecture can be quite fragile. This may be because of the bleeding edge nature of everything I was running, but it is an architecture which has multiple 'failure' points - firefox is upgraded and then mozrepl won't work untio a new version of that is created and then your interface with that won't work until ... .... This may not be as big an issue once things become more stable. However, I'm very keen on interfaces which are as loosely coupled as possible to try and minimize this type of issue. However, I would agree the mozrepl certainly offered some interesting possibilities and something I do plan to look at in more detial when time permits. I do think a lisp interpreter is possible, though not sure it is absolutely necessary. I need to think about it more! Tim --0016369f9ac59b47e304a5a3f97d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 13, 2011 at 2:53 PM, Mohsen = BANAN <list-general@mohsen.1.banan.byname.net> wrote:
=

>>>>> On Mon, 13 Jun 2011 12:09:23 +1000, Tim Cross <theophilusx@gmail.com> said:
=A0Tim> For emacs to really be a good desktop environment in this age, = I think it must
=A0Tim> have the ability to provide access to rich web content - conten= t that uses
=A0Tim> javascript, html5 etc. It would seem there are two possible app= roaches to this
=A0Tim> - do the necessary work in emacs or provide some mechanism that= would allow
=A0Tim> emacs to access and possibly manipulate data that is already pa= rtially
=A0Tim> processed by a web browser such as firefox or chromium.=A0

This is right on the mark.

And is consistent with what I meant earlier by
calling Emacs and Mozilla as joint sisters.

Below are my notes for add-on packages that I
include in firefox to provide some level of
integration with emacs.

The model of mozrepl is particularly promising.

=A0http= ://wiki.github.com/bard/mozrepl/

Mozrepl permits considering Mozilla as an emacs coprocess.
Where emacs can execute javascript inside of
mozilla. So, all we need is a lisp interpreter
written in javascript. We can then view Mozilla as
a renderer and an extension of emacs.

I know that people have tried building a lisp
interpreter in javascript, but as far as I know
such a thing does not exist yet.

I am very interested in knowing people's thoughts
on this approach.

...Mohsen


Hi Mohsen,

thanks for the in= fo, it will be useful. I do think this has some potential and worth looking= at. I would also like to see what cold be done with chrome as I tend to fa= vor it as a browser over firefox these days.=A0

The one thing I found when looking at this some time ba= ck was that the architecture can be quite fragile. This may be because of t= he bleeding edge nature of everything I was running, but it is an architect= ure which has multiple 'failure' points - firefox is upgraded and t= hen mozrepl won't work untio a new version of that is created and then = your interface with that won't work until ... ....

This may not be as big an issue once things become more= stable. However, I'm very keen on interfaces which are as loosely coup= led as possible to try and minimize this type of issue. However, I would ag= ree the mozrepl certainly offered some interesting possibilities and someth= ing I do plan to look at in more detial when time permits. I do think a lis= p interpreter is possible, though not sure it is absolutely necessary. I ne= ed to think about it more!

Tim


--0016369f9ac59b47e304a5a3f97d--