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

[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

[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

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

[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

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

Feature change or bug - Emacs server

[T.V Raman]

Ted,

1+ on not attempting to implement  what you call the pile of
undefined / open-ended Web specs in Emacs -- I say this even
though I would love to have a full-fledged browser in Emacs.

Eventually, I think we should connect emacs to Firefox and / or
Chrome over a socket -- mozrepl for Firefox did a lot of this,
but appears to have stalled. Chrome has a socket-level debugging
protocol that could be leveraged for this -- google searches
showed an early glimpse of this at github.

Tim, that may be something you might want to look at.

As someone who "already" uses Emacs as the desktop (via
Emacspeak), I definitely think emacs-panel.el could make the
Emacspeak Audio Desktop even better -- and I look forward to
it. One of the first things I would want is to mimic things like
nm-applet -- today, that's one of the few things I find
impossible to do without waving a mouse at the Gnome GUI.
-- 

-- 

Re: Feature change or bug - Emacs server

[Mohsen BANAN]

>>>>> On Tue, 14 Jun 2011 01:49:20 +0900, tv.raman.tv@gmail.com (T.V Raman) said:

  Raman> Eventually, I think we should connect emacs to Firefox and / or
  Raman> Chrome over a socket

Agreed.

  Raman> mozrepl for Firefox did a lot of this,
  Raman> but appears to have stalled.

What makes you say that?

What is missing from mozrepl to permit for full
integration?

Thanks.

...Mohsen

Re: Feature change or bug - Emacs server

[Ted Zlatanov]

On Tue, 14 Jun 2011 01:49:20 +0900 tv.raman.tv@gmail.com (T.V Raman) wrote: 

TVR> As someone who "already" uses Emacs as the desktop (via Emacspeak),
TVR> I definitely think emacs-panel.el could make the Emacspeak Audio
TVR> Desktop even better -- and I look forward to it. One of the first
TVR> things I would want is to mimic things like nm-applet -- today,
TVR> that's one of the few things I find impossible to do without waving
TVR> a mouse at the Gnome GUI.  --

Can you or someone else who knows NetworkManager (nmcli,
nm-connection-editor, nm-tool, nm-online, nm-applet, etc.) explain what
needs to be provided and how to do it?  Pointers to specs, docs,
etc. are welcome.  Believe it or not I never use nm-applet so I have no
idea what it can do :)  I'll then add that functionality to
emacs-panel.el.

For the protocol, I found only
http://live.gnome.org/NetworkManagerConfiguration which is a good
explanation and shows the D-BUS protocol to some degree, but not how to
use the protocol directly.

I plan to watch D-BUS anyhow to handle notifications.  So it seems that
using D-BUS is inevitable and probably better than relying on
command-line utilities.  Is it sufficient?  Or are there other pieces?

Thanks
Ted

Re: Feature change or bug - Emacs server

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> For the protocol, I found only
> http://live.gnome.org/NetworkManagerConfiguration which is a good
> explanation and shows the D-BUS protocol to some degree, but not how to
> use the protocol directly.

In this case, you might observe the D-Bus system bus via

  "dbus-monitor --system"

and play with your network. In case you have a wireless connection, you
will see already the signals about the strength of the connection.

> I plan to watch D-BUS anyhow to handle notifications.  So it seems that
> using D-BUS is inevitable and probably better than relying on
> command-line utilities.  Is it sufficient?  Or are there other pieces?

From my understanding, it is the best approach, at least if you intend
to watch for signals. As usual, I'm at your service :-)

> Thanks
> Ted

Best regards, Michael.

Re: Feature change or bug - Emacs server

[Antoine Levitt]

13/06/11 19:18, Ted Zlatanov
> On Tue, 14 Jun 2011 01:49:20 +0900 tv.raman.tv@gmail.com (T.V Raman) wrote: 
>
> TVR> As someone who "already" uses Emacs as the desktop (via Emacspeak),
> TVR> I definitely think emacs-panel.el could make the Emacspeak Audio
> TVR> Desktop even better -- and I look forward to it. One of the first
> TVR> things I would want is to mimic things like nm-applet -- today,
> TVR> that's one of the few things I find impossible to do without waving
> TVR> a mouse at the Gnome GUI.  --
>
> Can you or someone else who knows NetworkManager (nmcli,
> nm-connection-editor, nm-tool, nm-online, nm-applet, etc.) explain what
> needs to be provided and how to do it?  Pointers to specs, docs,
> etc. are welcome.  Believe it or not I never use nm-applet so I have no
> idea what it can do :)  I'll then add that functionality to
> emacs-panel.el.

It looks hard and bug-inducing to reimplement the network manager
applet. A nice alternative would be some way (an M-x, an indicator in
the status line, a binding ...) to pop-up the menu from the applet
inside emacs. In general, having menus (applications, places, system,
network manager, whatever) pop up from emacs looks like a good
compromise, as well as a good "compatibility mode". I have no idea if
that's doable with the xembed branch.

I for one would be very happy to be rid of all that gnome nonsense and
just run emacs and a light fullscreen-oriented wm (that and some kind of
customizable bidirectional emacs <-> rest of the world notification
system are the only thing I really need, and I suspect many people as
well. For notifications, I currently use gnome-osd, which sucks less
than notify-osd, but not by far.) One of the things preventing me from
doing that (aside from laziness, obviously) is the traybar (where apps
can put their little icons, and, on ubuntu, where system thingies
(sound, network, etc.) used to be, before they moved to some new fancy
buggy framework).

I used to file the "move away from gnome and reclaim control on my
desktop" in my "some day" mental TODO list, but ubuntu's plans of
ditching everything that's remotely usable anymore in the next release
might accelerate the process.

In any event, good luck on your endeavour, and I'll be watching closely
in my endless pursuit of having my work done by other people. :-)

Re: Feature change or bug - Emacs server

[Ted Zlatanov]

On Tue, 14 Jun 2011 01:45:11 +0200 Antoine Levitt <antoine.levitt@gmail.com> wrote: 

AL> It looks hard and bug-inducing to reimplement the network manager
AL> applet.

Do you know this for sure?  It seems that the interface is entirely
through D-BUS, which is not a hard protocol to support in ELisp.

AL> In general, having menus (applications, places, system, network
AL> manager, whatever) pop up from emacs looks like a good compromise,
AL> as well as a good "compatibility mode".

I'd really prefer to avoid such hacks, though they may work in the short
term.  They tend to make life very difficult over the long term.

AL> I for one would be very happy to be rid of all that gnome nonsense and
AL> just run emacs and a light fullscreen-oriented wm (that and some kind of
AL> customizable bidirectional emacs <-> rest of the world notification
AL> system are the only thing I really need, and I suspect many people as
AL> well. For notifications, I currently use gnome-osd, which sucks less
AL> than notify-osd, but not by far.)

Ah, you're my notifications.el beta tester then :)  Stay tuned.

AL> One of the things preventing me from doing that (aside from
AL> laziness, obviously) is the traybar (where apps can put their little
AL> icons, and, on ubuntu, where system thingies (sound, network, etc.)
AL> used to be, before they moved to some new fancy buggy framework).

I asked about that and it's unlikely we can support it in Emacs.  
I don't consider that a great loss, though some may want it.  Also note
that on NS/Carbon/Cocoa and W32 this won't be available anyhow.

I think there are standalone apps that can be the icon tray in X.

AL> I used to file the "move away from gnome and reclaim control on my
AL> desktop" in my "some day" mental TODO list, but ubuntu's plans of
AL> ditching everything that's remotely usable anymore in the next release
AL> might accelerate the process.

Yeah, I'm really tired of the balkanization of the X desktop.  It's as
if everyone is simply racing to mimic the W32 and Mac OS X platforms,
which is not a race worth winning.

Ted

Re: Feature change or bug - Emacs server

[Tim Cross]

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

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

> On Tue, 14 Jun 2011 01:45:11 +0200 Antoine Levitt <
> antoine.levitt@gmail.com> wrote:
>
> AL> It looks hard and bug-inducing to reimplement the network manager
> AL> applet.
>
> Do you know this for sure?  It seems that the interface is entirely
> through D-BUS, which is not a hard protocol to support in ELisp.
>
> I would tend to agree. D-Bus seems very promising and I have a couple of
TODO items to look at D-Bus more closely when time permits (specifically,
I'd like to find the time to look at D-Bus for emacspeak speech server
communication, but suspect that journey would also provide the necessary
knowledge to exploit the protocol for other applications.


> AL> In general, having menus (applications, places, system, network
> AL> manager, whatever) pop up from emacs looks like a good compromise,
> AL> as well as a good "compatibility mode".
>
> I'd really prefer to avoid such hacks, though they may work in the short
> term.  They tend to make life very difficult over the long term.
>
> From an accessibility perspective, I would also have to say that such
solutions are not great.


> AL> I for one would be very happy to be rid of all that gnome nonsense and
> AL> just run emacs and a light fullscreen-oriented wm (that and some kind
> of
> AL> customizable bidirectional emacs <-> rest of the world notification
> AL> system are the only thing I really need, and I suspect many people as
> AL> well. For notifications, I currently use gnome-osd, which sucks less
> AL> than notify-osd, but not by far.)
>
> Ah, you're my notifications.el beta tester then :)  Stay tuned.
>
> AL> One of the things preventing me from doing that (aside from
> AL> laziness, obviously) is the traybar (where apps can put their little
> AL> icons, and, on ubuntu, where system thingies (sound, network, etc.)
> AL> used to be, before they moved to some new fancy buggy framework).
>
> I asked about that and it's unlikely we can support it in Emacs.
> I don't consider that a great loss, though some may want it.  Also note
> that on NS/Carbon/Cocoa and W32 this won't be available anyhow.
>
> I think there are standalone apps that can be the icon tray in X.
>
> Yep, thats may feeling as well. Much of this 'essential' stuff is really
just what we have gotten use to. Much of it is what has added the complexity
which now appears to make many things that were simple much more complicated
while making a few rarely required/changing things easier - at least thats
how it feels to me.

You can survive using a modern Linux distro without having to have all the
Gnome stuff and there are alternatives for most of the things it offers.
Yes, at this time, it may take a little more effort to setup initially.


> AL> I used to file the "move away from gnome and reclaim control on my
> AL> desktop" in my "some day" mental TODO list, but ubuntu's plans of
> AL> ditching everything that's remotely usable anymore in the next release
> AL> might accelerate the process.
>
> Yeah, I'm really tired of the balkanization of the X desktop.  It's as
> if everyone is simply racing to mimic the W32 and Mac OS X platforms,
> which is not a race worth winning.
>
> It does seem odd for this tendency to exist. The thing which originally
attracted me to the X environment was tts flexibility and potential to
create the environment you wanted and to work the way you wanted rather than
having something imposed from some large anonymous vendor. It seems now,
possibly through desires to reduce support costs, even larger Linux distros
are trying to channel as many users into a standard desktop environment -
after all, this would make it easier to support.  The problem is as you
highlight - everyone is converging to the same result and we lose
originality and innovation. I miss the days when I'd walk into one of our
computer labs running X and see 20 screens, all looking distinct (and I
don't just mean different colours and icon themes) with different use of
screen real estate, unusual menus, such as spiral  menus, mice controlled by
foot pedals, innovative embedding of local and remote services etc.

I have no idea what the ideal interface will be, but I'd make a bet its
unlikely to be the same for everyone and is almost certainly drastically
different from what we are currently seeing.

Tim

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

Re: Feature change or bug - Emacs server

[Antoine Levitt]

14/06/11 02:57, Ted Zlatanov
> On Tue, 14 Jun 2011 01:45:11 +0200 Antoine Levitt <antoine.levitt@gmail.com> wrote: 
>
> AL> It looks hard and bug-inducing to reimplement the network manager
> AL> applet.
>
> Do you know this for sure?  It seems that the interface is entirely
> through D-BUS, which is not a hard protocol to support in ELisp.

True, but nm-applet has changed substiantially over the last year or so,
and if they keep it up the elisp code might need constant fixing. Plus,
nm-applet does quite a lot of things (wifi authentification, VPN
management, connection configuration, etc.) and has just recently
started to do it well (previous versions were riddled with bugs), so
presumably it's not trivial to implement. Also, if the API is only used
by nm-applet, it might not be as generic as you'd like. But then again I
haven't looked at the spec.

> AL> In general, having menus (applications, places, system, network
> AL> manager, whatever) pop up from emacs looks like a good compromise,
> AL> as well as a good "compatibility mode".
>
> I'd really prefer to avoid such hacks, though they may work in the short
> term.  They tend to make life very difficult over the long term.

But going for the low-hanging fruit (if it is - I don't know if the
xembed code is mature enough to handle this) is usually good to get
things started. Plus, it'd provide compatibility with stuff that doesn't
use dbus.

Also, how are going to implement the apps/places/system menus? (assuming
you want them) Apps should be easy enough (just parse
/usr/share/applications/), but "system" looks hardcoded.

> AL> I for one would be very happy to be rid of all that gnome nonsense and
> AL> just run emacs and a light fullscreen-oriented wm (that and some kind of
> AL> customizable bidirectional emacs <-> rest of the world notification
> AL> system are the only thing I really need, and I suspect many people as
> AL> well. For notifications, I currently use gnome-osd, which sucks less
> AL> than notify-osd, but not by far.)
>
> Ah, you're my notifications.el beta tester then :)  Stay tuned.

Bring it on!

My beef with notify-osd is that the ubuntu devs have for some reason
decided that apps should not be free to set whatever timeout they want
for their notification messages, hence making it totally unusable (and
also that their stacking interface does not work over shell commands,
though that's fixable using dbus). My beef with gnome-osd is that it
looks ugly.

> AL> One of the things preventing me from doing that (aside from
> AL> laziness, obviously) is the traybar (where apps can put their little
> AL> icons, and, on ubuntu, where system thingies (sound, network, etc.)
> AL> used to be, before they moved to some new fancy buggy framework).
>
> I asked about that and it's unlikely we can support it in Emacs.  
> I don't consider that a great loss, though some may want it.  Also note
> that on NS/Carbon/Cocoa and W32 this won't be available anyhow.
>
> I think there are standalone apps that can be the icon tray in X.

Ok, it's probably not that crucial, you're right.

Re: Feature change or bug - Emacs server

[joakim]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> 14/06/11 02:57, Ted Zlatanov
>> On Tue, 14 Jun 2011 01:45:11 +0200 Antoine Levitt <antoine.levitt@gmail.com> wrote: 
>>
>> AL> It looks hard and bug-inducing to reimplement the network manager
>> AL> applet.
>>
>> Do you know this for sure?  It seems that the interface is entirely
>> through D-BUS, which is not a hard protocol to support in ELisp.
>
> True, but nm-applet has changed substiantially over the last year or so,
> and if they keep it up the elisp code might need constant fixing. Plus,
> nm-applet does quite a lot of things (wifi authentification, VPN
> management, connection configuration, etc.) and has just recently
> started to do it well (previous versions were riddled with bugs), so
> presumably it's not trivial to implement. Also, if the API is only used
> by nm-applet, it might not be as generic as you'd like. But then again I
> haven't looked at the spec.
>
>> AL> In general, having menus (applications, places, system, network
>> AL> manager, whatever) pop up from emacs looks like a good compromise,
>> AL> as well as a good "compatibility mode".
>>
>> I'd really prefer to avoid such hacks, though they may work in the short
>> term.  They tend to make life very difficult over the long term.
>
> But going for the low-hanging fruit (if it is - I don't know if the
> xembed code is mature enough to handle this) is usually good to get

It's not. Lately I've come to realise I'm on the wrong track and need to
revert the last 10 commits or so and go down another track. Basically I
thought composition would be a fantastic fit but it wasn't so I'll use a MVC
aproach instead. But GTK doesn't come with a MVC framework out of the
box so I need to implement a rudimentary one using signals it seems. For
the advanced case of embedding an application that doesn't support MVC
and only xembed composition can still be used but that is not robust
enough in the general case. Applications like Inkscape that support
multiple views can be modified to use xembed and use a separate xembed
widgets per view. I think that case can be made to be robust.

> things started. Plus, it'd provide compatibility with stuff that doesn't
> use dbus.
> Also, how are going to implement the apps/places/system menus? (assuming
> you want them) Apps should be easy enough (just parse
> /usr/share/applications/), but "system" looks hardcoded.
>
>> AL> I for one would be very happy to be rid of all that gnome nonsense and
>> AL> just run emacs and a light fullscreen-oriented wm (that and some kind of
>> AL> customizable bidirectional emacs <-> rest of the world notification
>> AL> system are the only thing I really need, and I suspect many people as
>> AL> well. For notifications, I currently use gnome-osd, which sucks less
>> AL> than notify-osd, but not by far.)
>>
>> Ah, you're my notifications.el beta tester then :)  Stay tuned.
>
> Bring it on!
>
> My beef with notify-osd is that the ubuntu devs have for some reason
> decided that apps should not be free to set whatever timeout they want
> for their notification messages, hence making it totally unusable (and
> also that their stacking interface does not work over shell commands,
> though that's fixable using dbus). My beef with gnome-osd is that it
> looks ugly.
>
>> AL> One of the things preventing me from doing that (aside from
>> AL> laziness, obviously) is the traybar (where apps can put their little
>> AL> icons, and, on ubuntu, where system thingies (sound, network, etc.)
>> AL> used to be, before they moved to some new fancy buggy framework).
>>
>> I asked about that and it's unlikely we can support it in Emacs.  
>> I don't consider that a great loss, though some may want it.  Also note
>> that on NS/Carbon/Cocoa and W32 this won't be available anyhow.
>>
>> I think there are standalone apps that can be the icon tray in X.
>
> Ok, it's probably not that crucial, you're right.
>

-- 
Joakim Verona

Re: Feature change or bug - Emacs server

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> AL> One of the things preventing me from doing that (aside from
> AL> laziness, obviously) is the traybar (where apps can put their little
> AL> icons, and, on ubuntu, where system thingies (sound, network, etc.)
> AL> used to be, before they moved to some new fancy buggy framework).
>
> I asked about that and it's unlikely we can support it in Emacs.  
> I don't consider that a great loss, though some may want it.  Also note
> that on NS/Carbon/Cocoa and W32 this won't be available anyhow.

See <http://www.freedesktop.org/wiki/Specifications/StatusNotifierIcon>, 
there are two proposal for a specification. I don't know whether one of
them has been implemented, though.

> Ted

Best regards, Michael.

Re: Feature change or bug - Emacs server

[joakim]

tv.raman.tv@gmail.com (T.V Raman) writes:

> Ted,
>
> 1+ on not attempting to implement  what you call the pile of
> undefined / open-ended Web specs in Emacs -- I say this even
> though I would love to have a full-fledged browser in Emacs.
>
> Eventually, I think we should connect emacs to Firefox and / or
> Chrome over a socket -- mozrepl for Firefox did a lot of this,
> but appears to have stalled. Chrome has a socket-level debugging
> protocol that could be leveraged for this -- google searches
> showed an early glimpse of this at github.
>
> Tim, that may be something you might want to look at.
>
> As someone who "already" uses Emacs as the desktop (via
> Emacspeak), I definitely think emacs-panel.el could make the
> Emacspeak Audio Desktop even better -- and I look forward to
> it. One of the first things I would want is to mimic things like
> nm-applet -- today, that's one of the few things I find
> impossible to do without waving a mouse at the Gnome GUI.
> -- 

Also one can have a look at Ezbl which is an experimental project
bringing Emacs and Uzbl tegether. Uzbl is a wrapper on top of Webkit.

-- 
Joakim Verona

Re: Feature change or bug - Emacs server

[Tim Cross]

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

On Tue, Jun 14, 2011 at 2:49 AM, T.V Raman <tv.raman.tv@gmail.com> wrote:

> Ted,
>
> 1+ on not attempting to implement  what you call the pile of
> undefined / open-ended Web specs in Emacs -- I say this even
> though I would love to have a full-fledged browser in Emacs.
>
> Eventually, I think we should connect emacs to Firefox and / or
> Chrome over a socket -- mozrepl for Firefox did a lot of this,
> but appears to have stalled. Chrome has a socket-level debugging
> protocol that could be leveraged for this -- google searches
> showed an early glimpse of this at github.
>
> Tim, that may be something you might want to look at.
>
> As someone who "already" uses Emacs as the desktop (via
> Emacspeak), I definitely think emacs-panel.el could make the
> Emacspeak Audio Desktop even better -- and I look forward to
> it. One of the first things I would want is to mimic things like
> nm-applet -- today, that's one of the few things I find
> impossible to do without waving a mouse at the Gnome GUI.
>
> Yes, looking at how emacs to interface with existing browsers would be
something I'd enjoy looking at and is already on the TODO list. I have a
cople of other projects to complete first. One thing I really need to do is
get back up to speed in web technology. For the last 10 years, nearly all my
work has been focused on other areas, noteably database development and more
recently identity and access management. Meanwhile, the web world has moved
on quite a long way from what I was doing in the late 90s.

One thing I really want to do first is get up to speed with D-Bus. In
particular, I want to see if it can be used to improve the interface to an
espeak based speech server for emacspeak. Just got to make the space to do
it!

Tim

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