Feature change or bug - Emacs server

Feature change or bug - Emacs server

[Tim Cross]

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

Hi All,

just wanted to check to see if changed functionality I've noticed is a
deliberate feature change or a bug.

Running Emacs GTK+ 24 (recent bzr) under X (xfce wm).

I have my EDITOR environment variable set to emacsclient. Previously, when I
did something like cron -e or git commit -a, emacs would popup a new frame
on the virtual diesktop where I issued the command, I would make the
changes, do the normal C-x 4 and the frame would close, returning me to the
terminal and the command that triggered the edit would complete its work.
All good and I liked the behavior.

However, I now find that doing the exact same workflow causes an existing
emacs fram from another virtual desktop to be moved to the virtual desktop
containing the terminal where I ran cron/git/whatever that triggered the
workflow i.e. not a new frame. When I complete the edit and hit C-x 4, the
emacs buffer closes and switches back to its previous contents, but the
frame stays on this virtual desktop. I now have to move the frame back to
its original virtual desktop or to the side so that I can get back to the
terminal. All behavior which is not as good as it was previously.

My real problem is that I've just switched from Gnome/compiz and don't know
if the changes are observing are due to changes iin emacsclient (I've
noticed some posts concerning emacsclient recently) or is it because of
differences between GNOME and XFCE?  Perhaps I need to add additional
switches/config settings under xfce? Quite happy to do more testing to try
and work things out, but figured I may as well check to see if anyone else
has noticed the same or can offer some advice (especially as there has
recently been a few issues with bzr emacs and X, which now appear to be
resolved i.e. clipboard communication timeouts, slow exiting, random crashes
etc).

Tim

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

Re: Feature change or bug - Emacs server

[Tassilo Horn]

Tim Cross <theophilusx@gmail.com> writes:

Hi Tim,

> just wanted to check to see if changed functionality I've noticed is a
> deliberate feature change or a bug.
>
> Running Emacs GTK+ 24 (recent bzr) under X (xfce wm).
>
> I have my EDITOR environment variable set to emacsclient. Previously,
> when I did something like cron -e or git commit -a, emacs would popup
> a new frame on the virtual diesktop where I issued the command, I
> would make the changes, do the normal C-x 4 and the frame would close,
> returning me to the terminal and the command that triggered the edit
> would complete its work.

That's a bit strange.  emacsclient foo.txt should have always found
foo.txt in an existing frame (possibly on another workspace).  If you
want to use a new frame, you have to provide the -c, --create-frame
option.  Or to use a new terminal frame, use -t, --tty.

I have

  EDITOR=emacsclient -t

and

  VISUAL=emacsclient -c

Bye,
Tassilo

Re: Feature change or bug - Emacs server

[chad]

If you're running emacs from bzr, would you mind telling us what (if 
any) configuration you've done around pop-up-frames?  To get the 
behavior you described originally, you probably had some customization 
(perhaps as simple as (setq pop-up-frames 't)), but it'll be tricky to 
figure out what might have caused the problem without knowing.

Thanks,
*Chad

Re: Feature change or bug - Emacs server

[Stefan Monnier]

> My real problem is that I've just switched from Gnome/compiz and don't know
> if the changes are observing are due to changes iin emacsclient (I've
> noticed some posts concerning emacsclient recently) or is it because of
> differences between GNOME and XFCE?  Perhaps I need to add additional

It seems likely it's a difference in WM behavior rather than in Emacs.
Please try to figure that out first, and report back to us it's really
a change in Emacs.


        Stefan

Re: Feature change or bug - Emacs server

[Tim Cross]

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

Thanks everyone for your responses.

I will dig deeper. I too suspect it is a difference in window managers.
The point about needing -c and -t switches is interesting. That is how I
rememberd things having to be in order to have a new frame created (rather
than using an existing frame). However, perhaps in error, I distinctly
remember being surprised when I noticed new frames being created and then
deleted when I finished with them, but was pretty sure I've never used the
-c or -t switch except when connecting remotely and wanting to open a frame
on an existing local instance. However, given all the changes I've been
making lately, I could easily be mistaken.

One thing I am sure about is that previously, with no -c or -t, when running
something like cron -e or git commit, one of the existing frames would be
used BUT would NOT be moved from one virtual deskto to the current desktop.
I can live with either the reuse of an existing frame or opening and closing
of a new frame, but really don't want an existing frame to be moved from its
current virtual desktop to the desktop where I am running the terminal as
this wrecks my setup and I then have to manually move the frame back.

One of the reasons I asked this question on the list rather than logging a
bug report is that I've recently been going through a number of environment
changes in a search for a setup I liked. Unfortunately, this also means a
much larger set of possible problem/change candidates. So, I was hoping a
message here would help me reduce/prioritise the possibilities a bit (which
I think it has).

For some time, I've been getting increasingly frustrated with the increasing
size (both with respect to disk size and memory/cpu footprint) of GNOME and
as an old dog who started with X in the mid 80s, what feels like greatly
increased complexity with little real increase in functionality. I look at
my .xsession-errors file these days with a combination of puzzlement, awe
and confusion as its seems to be full of information messages rather than
errors. When you ask on forums what they mean, you get vague answers and
statements like "Oh, just ignore them".

As a consequence, I've been looking at various alternatives. I tried a
recent GNOME and compiz - pretty but I think bloated. I looked at unity, but
disliked it and hated menu options being in the top task bar rather than the
app window. I've looked at some other and am currently using xfce. So far,
the two I like most have been xfce and sawfish, though openbox also looks
interesting.

Of course, if emacs had a decent web browser able to handle javascript etc
and there was some way of having multiple virtual desktops, my .Xsession
would likely end with something like

exec emacs

In the meantime, I will experiment with various wm until I find the one that
is as light weight as possible while still providing all the features I
want. Then I will craft my own .Xsession and hopefully again reclaim at
least the feeling I know what is going on and am in control! If anyone has
any recommendations on non-GNOME (or KDE for that matter) wm they have found
good, I'd be i9nterested in hearing about it (possibly privately to spare
the list!).

If I am able to confirm significant behavior differences with emacs server,
frames and window managers, I'll report back and if significant enough, will
log a bug report (even if that report just recommends a note in the manual
to alert people to differences in behavior with some window managers).


Tim

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

Re: Feature change or bug - Emacs server

[Ted Zlatanov]

On Sat, 11 Jun 2011 12:48:57 +1000 Tim Cross <theophilusx@gmail.com> wrote: 

TC> Of course, if emacs had a decent web browser able to handle javascript etc
TC> and there was some way of having multiple virtual desktops, my .Xsession
TC> would likely end with something like

TC> exec emacs

TC> In the meantime, I will experiment with various wm until I find the one that
TC> is as light weight as possible while still providing all the features I
TC> want. Then I will craft my own .Xsession and hopefully again reclaim at
TC> least the feeling I know what is going on and am in control! If anyone has
TC> any recommendations on non-GNOME (or KDE for that matter) wm they have found
TC> good, I'd be i9nterested in hearing about it (possibly privately to spare
TC> the list!).

My work on Emacs as a desktop environment is exactly what you're talking
about, I think.  Look at those threads, especially
http://permalink.gmane.org/gmane.emacs.devel/139687 where I list all the
things I think are needed.  I'm just starting now, should have a usable
emacs-panel.el with functional tiles and some WM integration eventually,
and then I will add the rest gradually (help is welcome, of course).

I don't plan to replace the WM, but everything else is fair game.

Ted

Re: Feature change or bug - Emacs server

[Tim Cross]

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

2011/6/11 Ted Zlatanov <tzz@lifelogs.com>

> On Sat, 11 Jun 2011 12:48:57 +1000 Tim Cross <theophilusx@gmail.com>
> wrote:
>
> TC> Of course, if emacs had a decent web browser able to handle javascript
> etc
> TC> and there was some way of having multiple virtual desktops, my
> .Xsession
> TC> would likely end with something like
>
> TC> exec emacs
>
> TC> In the meantime, I will experiment with various wm until I find the one
> that
> TC> is as light weight as possible while still providing all the features I
> TC> want. Then I will craft my own .Xsession and hopefully again reclaim at
> TC> least the feeling I know what is going on and am in control! If anyone
> has
> TC> any recommendations on non-GNOME (or KDE for that matter) wm they have
> found
> TC> good, I'd be i9nterested in hearing about it (possibly privately to
> spare
> TC> the list!).
>
> My work on Emacs as a desktop environment is exactly what you're talking
> about, I think.  Look at those threads, especially
> http://permalink.gmane.org/gmane.emacs.devel/139687 where I list all the
> things I think are needed.  I'm just starting now, should have a usable
> emacs-panel.el with functional tiles and some WM integration eventually,
> and then I will add the rest gradually (help is welcome, of course).
>
> I don't plan to replace the WM, but everything else is fair game.
>
> Ted
>
> Hi Ted,


Yes, I saw your posts regarding  emacs as a desktop environment. As someone
who was largely restricted to using emacs as my desktop environment (for
over 13 years, I was pretty much totally blind and used emacs with emacspeak
for nearly everything), I can appreciate where you are coming from. However,
over the last few years, this was becoming increasingly more difficult and
less adequate as more and more things moved to a web based environment using
javascript. As html5 rolls out, I suspet things will become worse.

There has been some interesting work done which tries to create a closer
link between emacs and a sophisticated browser, such as firefox. T. V. Raman
has done some really interesting work in this area which might be worth
looking at.

For emacs to really be a good desktop environment in this age, I think it
must have the ability to provide access to rich web content - content that
uses javascript, html5 etc. It would seem there are two possible approaches
to this - do the necessary work in emacs or provide some mechanism that
would allow emacs to access and possibly manipulate data that is already
partially processed by a web browser such as firefox or chromium.

As we can see from the lack of development with emacs w3, there does not
appear to be much interest in developing a full featured web browser in
emacs. Much of T. V. Raman's work has focused on using a web browser like
firefox to do the heavy lifting of processing the content, javascript, etc
and then providing an interface that emacs can use to obtain the final
result for display. Others have provided browser plugins to allow emacs to
provide editing support etc.

IMO for emacs to be a really useful desktop environment, it will be
necessary to provide some sort of web interface and is able to support rich
web content. I suspect that development and maintenance of a stand-alone
elisp package, similar to w3, is not practical and that the best result
would be to develop interfaces that allow browsers like firefox or chromium
to do what they do best, but allow emacs to access the results of their work
and to provide input so that emacs can drive the browser and 'cherry pick'
bits.

WRT things like an emacs panel, its not clear to me what real benefit such
things would have if you are looking at emacs as the desktop environment.
Essentially, what would an emacs panel provide for emacs that you don't
already have or is it just putting together what we do have in a more
convenient form?

Tim

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

Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server

[Mohsen BANAN]

>>>>> On Mon, 13 Jun 2011 12:09:23 +1000, Tim Cross <theophilusx@gmail.com> 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


(defun blee:blee:doc:howto:browser:config-desc ()
  "

\\subsection{Browser (Mozilla/Firefox) Configuration for BLEE}

\\begin{verbatim}

CONFIGURATION
=============

Major Packages Used Are:
 - httpheaders:    mozmail.el plus about:config protocol ...
 - firemacs:       Emacs Keyboard Mapping
 - mozex:          Textbox editing, Source View, Send Email, Send Link (does not work)
 - It's All Text:  Textbox Editing
 - mozmail:        mozmail.el plus gnome prefered application
 - mozrepl:        Control the browser with javascript from inside

Live HTTP Headers
-----------------
--- View HTTP headers of a page and while browsing. (Used for Plone Reverse Engineering) ---
https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/
Click -- Add to Firefox

FIREMACS Installation
---------------------
--- Emacs Key Bindings for Mozilla/Firefox ---
download firemacs
https://addons.mozilla.org/en-US/firefox/addon/4141
Click -- Add to Firefox
Click -- Install Now
Click -- Restart Firefox
After Install Verify --  Firefox/Tools/Add-Ons/Extensions/Firemacs


plugin: It's All Text -- Text Box Editor (Replaces Mozex)
----------------------------------------

https://addons.mozilla.org/en-US/firefox/addon/its-all-text/contribute/roadblock/?src=addondetail&version=1.5

Tools -> It's All Text -> Preferences

    Editor=/usr/bin/emacsclient

When done with the buffer, C-X #


MOZREPL
-------

- http://wiki.github.com/bard/mozrepl/

Install the released version  -- Click on Allow

In Firefox go to Tools -> MozRepl -> Activate on Startup



View Sources Editor Specification (Firefox's Own Configuration)
---------------------------------------------------------------

about:config

view_source.editor.external (toggle it -- right mouse)

view_source.editor.path (/usr/bin/emacsclient)  -- leave .editor.args empty


Send Link -- For MOZMAIL -- On The Browser Side:
------------------------------------------------

On The Desktop of the target machine -- NOT REMOTELEY

Go To:  Gnome (Desktop) -> System -> Preferences -> Preferred Applications == Mail Reader Custom
   Command: /opt/public/osmt/bin/lcaMozillaProc.sh -p url=%s -i SendLink
   Select Run in Terminal


TESTING YOUR BROWSER ENVIRONMENT:
---------------------------------

A) (FIREMACS) Emacs Key Bindings
   Try C-s instead of find

B) Edit a Box
   Should See The (edit) option under the box

C) View Sources
   View > Page Source  (make sure that (server-start) was done on emacs side)
   Should Throw you in emacs

D) MozRepl

E) (MOZMAIL)
   1- On The Emacs side run M-x server-start -- (server-start)
   2) Get Some Sample Addresses From
      http://mc-computing.com/HTML_Examples/MailTo.htm
   3) Click on one of the mailto: addresses

USEFUL INFO:

http://kb.mozillazine.org/About:config_Entries

OBSOLETED - JUNKYARD - HISTORIC:
================================

Plugin: MOZEX -- OBSOLETED by it's all text
-------------------------------------------
http://mozex.mozdev.org/installation.html
## (Not Normally Used )http://mozex.mozdev.org/development.html

Under *NIX installation
Click -- here
Click -- ALLOW
Click -- Install Now
Click -- Restart Firefox

After Install Verify -- Firefox/Tools/Add-Ons/Extensions/Mozex 1.9.9
After Restart
Right Mouse Click
Mozex-Configration
Textarea
    Text editor: /usr/bin/emacsclient.emacs-snapshot %t
Source
    Source editor: /usr/bin/emacsclient.emacs-snapshot %t
close window

B) (MOZEX)
   1- On The Emacs side run M-x server-start -- (server-start)
   2- On The Browser Side -- Right Mouse Click - Mozex - View Page Source

\\end{verbatim}

"
  (interactive)
  )

Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server

[chad]

On Jun 12, 2011, at 9:53 PM, Mohsen BANAN wrote:

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

I can tell you that we talked about this sort of thing in 
1994, and I suspect that people's thoughts are the 
same as they were back then:  It's an interesting idea, 
and we'll certainly look at the code when someone 
else writes it.

*Chad

Re: Feature change or bug - Emacs server

[Ted Zlatanov]

On Mon, 13 Jun 2011 12:09:23 +1000 Tim Cross <theophilusx@gmail.com> wrote: 

TC> For emacs to really be a good desktop environment in this age, I
TC> think it must have the ability to provide access to rich web content
TC> - content that uses javascript, html5 etc.

I think within Emacs, w3m and shr.el are sufficient; Firefox and Chrome
are usable in the Emacs-based desktop environment I propose.

Trying to track the pile of... standards... that is HTML plus Javascript
plus CSS is IMO a waste of time.  The battle was lost in 1993 or so; a
web browser is today not so much a program as a compromise over which
standards to follow and to what extent.  So I'd rather let web browsers
do that, and Emacs should not try to do it.

TC> As we can see from the lack of development with emacs w3, there does not
TC> appear to be much interest in developing a full featured web browser in
TC> emacs.

I think w3m has provided 95% of what's needed, and the rest is external.

TC> IMO for emacs to be a really useful desktop environment, it will be
TC> necessary to provide some sort of web interface and is able to
TC> support rich web content.

You said that already :)

TC> WRT things like an emacs panel, its not clear to me what real benefit such
TC> things would have if you are looking at emacs as the desktop environment.
TC> Essentially, what would an emacs panel provide for emacs that you don't
TC> already have or is it just putting together what we do have in a more
TC> convenient form?

emacs-panel.el will provide several things that gnome-panel and friends
provide today.  The goal is to reduce the need for GNOME and KDE (and
others, like XFCE), in the process saving memory, resources, and
providing a richer, more customizable environment.  I listed all the
things emacs-panel.el should provide in
http://permalink.gmane.org/gmane.emacs.devel/139687 and am working
(slowly) on implementing them.

Ted

Re: Feature change or bug - Emacs server

[Tim Cross]

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

2011/6/14 Ted Zlatanov <tzz@lifelogs.com>

> On Mon, 13 Jun 2011 12:09:23 +1000 Tim Cross <theophilusx@gmail.com>
> wrote:
>
> TC> For emacs to really be a good desktop environment in this age, I
> TC> think it must have the ability to provide access to rich web content
> TC> - content that uses javascript, html5 etc.
>
> I think within Emacs, w3m and shr.el are sufficient; Firefox and Chrome
> are usable in the Emacs-based desktop environment I propose.
>
> Trying to track the pile of... standards... that is HTML plus Javascript
> plus CSS is IMO a waste of time.  The battle was lost in 1993 or so; a
> web browser is today not so much a program as a compromise over which
> standards to follow and to what extent.  So I'd rather let web browsers
> do that, and Emacs should not try to do it.
>
> TC> As we can see from the lack of development with emacs w3, there does
> not
> TC> appear to be much interest in developing a full featured web browser in
> TC> emacs.
>
> I think w3m has provided 95% of what's needed, and the rest is external.
>
> TC> IMO for emacs to be a really useful desktop environment, it will be
> TC> necessary to provide some sort of web interface and is able to
> TC> support rich web content.
>
> You said that already :)
>

Yes, perhaps not well structured. Unfortunately, you seem to have cut out
the main point - I am not arguing for an emacs based web browser because
that is not practical. However, we do need some sort of emacs interface to
web content that is able to handle the increasing amount of content which
w3m is unable to process. What I'm suggesting is that interface is provided
by creating an interface between emacs and web browsers like firefox and
chrome. Allow the web browser to do all the heavy lifting, but provide a
channel that enables emacs to retrieve all/part of this content for
processing/display with elisp and a channel that would allow the browser to
be driven by emacs.  Some work, possibly best described as proof of concept
work, has bee done in this area using mozrepl by T. V. Raman as part of
emacspeak. In fact, if you want to see the range of things that can be done
with emacs as a deskto environment, checking out emacspeak would not be a
waste of time as this is an emacs package which has been providing an
advanced desktop environment which doesn't even need a display for over 15
years!

Tim

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

Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server

[Tim Cross]

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

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:
>
>  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

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

Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server

[Tim Cross]

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

On Mon, Jun 13, 2011 at 5:37 PM, chad <yandros@mit.edu> wrote:

> On Jun 12, 2011, at 9:53 PM, Mohsen BANAN wrote:
>
> > I am very interested in knowing people's thoughts
> > on this approach.
> >
> > ...Mohsen
>
> I can tell you that we talked about this sort of thing in
> 1994, and I suspect that people's thoughts are the
> same as they were back then:  It's an interesting idea,
> and we'll certainly look at the code when someone
> else writes it.
>
> *Chad
>
> I don't think anyone has suggested others do the work or are even asking
for others to do the work. I would characterise the current discussion as an
exploration of ideas and discovery of what others have been doing (such as
the webkit wrapper package mentioned elsewhere) which may be relevant.

Tim

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

Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server

[Daniel Colascione]

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

On 6/12/11 9:53 PM, Mohsen BANAN wrote:
> 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.
> 

js-mode contains code to integrate with mozrepl. It provides an
elisp<->JavaScript bridge that allows Elisp components to interoperate
with code running in a Mozilla instance. It contains a few applications
of this infrastructure, including a facility to define and update (using
C-M-x) JavaScript functions in Mozilla as one would Lisp functions in Emacs.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Feature change or bug - Emacs server

[Lars Magne Ingebrigtsen]

Tim Cross <theophilusx@gmail.com> writes:

> I am not arguing for an emacs based web browser
> because that is not practical.

I'm wondering to what extent it isn't practical, these days.

Parsing HTML is a solved problem.  Interpreting JS in elisp sound like a
fun project.  We have the DOM, and parsing JS can probably be done via
CEDET?  So it just mainly emulating the language itself, and writing all
the library functions, which sounds like fun fun fun, so I would kinda
be surprised if anybody hasn't done that already.

So the problem really is rendering.  Rendering HTML in a sensible way
would be easy if Emacs had a comprehensive rendering engine.  But Emacs
doesn't even have a way to line up two columns if you're mixing fonts.

So I agree that doing a real browser (where "real" means "you can use
gmail") in Emacs isn't feasible now, but that's not because html/css/js
is complicated. but just because Emacs has a weak rendering engine.

Sent from my Nokia at the airport

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Feature change or bug - Emacs server

[Julien Danjou]

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

On Tue, Jun 14 2011, Lars Magne Ingebrigtsen wrote:

> Parsing HTML is a solved problem.  Interpreting JS in elisp sound like a
> fun project.  We have the DOM, and parsing JS can probably be done via
> CEDET?  So it just mainly emulating the language itself, and writing all
> the library functions, which sounds like fun fun fun, so I would kinda
> be surprised if anybody hasn't done that already.

What'd be better is that Emacs would use Guile even for its Lisp, so it
would have JS interpreter for free. :-)

Just dreaming… :-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Feature change or bug - Emacs server

[Ted Zlatanov]

On Tue, 14 Jun 2011 13:42:23 +1000 Tim Cross <theophilusx@gmail.com> wrote: 

TC> we do need some sort of emacs interface to web content that is able
TC> to handle the increasing amount of content which w3m is unable to
TC> process. What I'm suggesting is that interface is provided by
TC> creating an interface between emacs and web browsers like firefox
TC> and chrome. Allow the web browser to do all the heavy lifting, but
TC> provide a channel that enables emacs to retrieve all/part of this
TC> content for processing/display with elisp and a channel that would
TC> allow the browser to be driven by emacs.

I see what you mean.  Yeah, that is useful, but I don't think I want to
get involved in that effort until emacs-panel.el is usable in other
ways.  Implementing web browsing is like a muddy stick... no matter how
you touch it, you'll get dirty :)

Ted

Re: Feature change or bug - Emacs server

[joakim]

Julien Danjou <julien@danjou.info> writes:

> On Tue, Jun 14 2011, Lars Magne Ingebrigtsen wrote:
>
>> Parsing HTML is a solved problem.  Interpreting JS in elisp sound like a
>> fun project.  We have the DOM, and parsing JS can probably be done via
>> CEDET?  So it just mainly emulating the language itself, and writing all
>> the library functions, which sounds like fun fun fun, so I would kinda
>> be surprised if anybody hasn't done that already.
>
> What'd be better is that Emacs would use Guile even for its Lisp, so it
> would have JS interpreter for free. :-)
>
> Just dreaming… :-)

There is a Guile Emacs Gsoc now, so things are at least happening.

Apropos rendering I'm doing some experiments with embedding
Cairo. Nothing fancy yet, but maybe it would be possible to render HTML
to Cairo in some distant future. 

-- 
Joakim Verona