* Feature change or bug - Emacs server @ 2011-06-09 6:47 Tim Cross 2011-06-09 7:17 ` Tassilo Horn 2011-06-09 15:21 ` Stefan Monnier 0 siblings, 2 replies; 18+ messages in thread From: Tim Cross @ 2011-06-09 6:47 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-09 6:47 Feature change or bug - Emacs server Tim Cross @ 2011-06-09 7:17 ` Tassilo Horn 2011-06-09 8:13 ` chad 2011-06-09 15:21 ` Stefan Monnier 1 sibling, 1 reply; 18+ messages in thread From: Tassilo Horn @ 2011-06-09 7:17 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-09 7:17 ` Tassilo Horn @ 2011-06-09 8:13 ` chad 0 siblings, 0 replies; 18+ messages in thread From: chad @ 2011-06-09 8:13 UTC (permalink / raw) To: Tim Cross; +Cc: Emacs development discussions 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-09 6:47 Feature change or bug - Emacs server Tim Cross 2011-06-09 7:17 ` Tassilo Horn @ 2011-06-09 15:21 ` Stefan Monnier 2011-06-11 2:48 ` Tim Cross 1 sibling, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2011-06-09 15:21 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-09 15:21 ` Stefan Monnier @ 2011-06-11 2:48 ` Tim Cross 2011-06-11 10:39 ` Ted Zlatanov 0 siblings, 1 reply; 18+ messages in thread From: Tim Cross @ 2011-06-11 2:48 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-11 2:48 ` Tim Cross @ 2011-06-11 10:39 ` Ted Zlatanov 2011-06-13 2:09 ` Tim Cross 0 siblings, 1 reply; 18+ messages in thread From: Ted Zlatanov @ 2011-06-11 10:39 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-11 10:39 ` Ted Zlatanov @ 2011-06-13 2:09 ` Tim Cross 2011-06-13 4:53 ` Now: Emacs<->Mozilla Integration -- Was: " Mohsen BANAN 2011-06-13 15:47 ` Ted Zlatanov 0 siblings, 2 replies; 18+ messages in thread From: Tim Cross @ 2011-06-13 2:09 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server 2011-06-13 2:09 ` Tim Cross @ 2011-06-13 4:53 ` Mohsen BANAN 2011-06-13 7:37 ` chad ` (2 more replies) 2011-06-13 15:47 ` Ted Zlatanov 1 sibling, 3 replies; 18+ messages in thread From: Mohsen BANAN @ 2011-06-13 4:53 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-devel >>>>> 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) ) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server 2011-06-13 4:53 ` Now: Emacs<->Mozilla Integration -- Was: " Mohsen BANAN @ 2011-06-13 7:37 ` chad 2011-06-14 3:57 ` Tim Cross 2011-06-14 3:53 ` Tim Cross 2011-06-14 8:37 ` Daniel Colascione 2 siblings, 1 reply; 18+ messages in thread From: chad @ 2011-06-13 7:37 UTC (permalink / raw) To: Mohsen BANAN; +Cc: Tim Cross, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server 2011-06-13 7:37 ` chad @ 2011-06-14 3:57 ` Tim Cross 0 siblings, 0 replies; 18+ messages in thread From: Tim Cross @ 2011-06-14 3:57 UTC (permalink / raw) To: chad; +Cc: Mohsen BANAN, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server 2011-06-13 4:53 ` Now: Emacs<->Mozilla Integration -- Was: " Mohsen BANAN 2011-06-13 7:37 ` chad @ 2011-06-14 3:53 ` Tim Cross 2011-06-14 8:37 ` Daniel Colascione 2 siblings, 0 replies; 18+ messages in thread From: Tim Cross @ 2011-06-14 3:53 UTC (permalink / raw) To: Mohsen BANAN; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Now: Emacs<->Mozilla Integration -- Was: Re: Feature change or bug - Emacs server 2011-06-13 4:53 ` Now: Emacs<->Mozilla Integration -- Was: " Mohsen BANAN 2011-06-13 7:37 ` chad 2011-06-14 3:53 ` Tim Cross @ 2011-06-14 8:37 ` Daniel Colascione 2 siblings, 0 replies; 18+ messages in thread From: Daniel Colascione @ 2011-06-14 8:37 UTC (permalink / raw) To: Mohsen BANAN; +Cc: Tim Cross, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-13 2:09 ` Tim Cross 2011-06-13 4:53 ` Now: Emacs<->Mozilla Integration -- Was: " Mohsen BANAN @ 2011-06-13 15:47 ` Ted Zlatanov 2011-06-14 3:42 ` Tim Cross 1 sibling, 1 reply; 18+ messages in thread From: Ted Zlatanov @ 2011-06-13 15:47 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-13 15:47 ` Ted Zlatanov @ 2011-06-14 3:42 ` Tim Cross 2011-06-14 14:53 ` Lars Magne Ingebrigtsen 2011-06-14 16:17 ` Ted Zlatanov 0 siblings, 2 replies; 18+ messages in thread From: Tim Cross @ 2011-06-14 3:42 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-14 3:42 ` Tim Cross @ 2011-06-14 14:53 ` Lars Magne Ingebrigtsen 2011-06-14 15:01 ` Julien Danjou 2011-06-14 16:17 ` Ted Zlatanov 1 sibling, 1 reply; 18+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-06-14 14:53 UTC (permalink / raw) To: emacs-devel 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/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-14 14:53 ` Lars Magne Ingebrigtsen @ 2011-06-14 15:01 ` Julien Danjou 2011-06-14 17:08 ` joakim 0 siblings, 1 reply; 18+ messages in thread From: Julien Danjou @ 2011-06-14 15:01 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-14 15:01 ` Julien Danjou @ 2011-06-14 17:08 ` joakim 0 siblings, 0 replies; 18+ messages in thread From: joakim @ 2011-06-14 17:08 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feature change or bug - Emacs server 2011-06-14 3:42 ` Tim Cross 2011-06-14 14:53 ` Lars Magne Ingebrigtsen @ 2011-06-14 16:17 ` Ted Zlatanov 1 sibling, 0 replies; 18+ messages in thread From: Ted Zlatanov @ 2011-06-14 16:17 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-06-14 17:08 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-09 6:47 Feature change or bug - Emacs server Tim Cross 2011-06-09 7:17 ` Tassilo Horn 2011-06-09 8:13 ` chad 2011-06-09 15:21 ` Stefan Monnier 2011-06-11 2:48 ` Tim Cross 2011-06-11 10:39 ` Ted Zlatanov 2011-06-13 2:09 ` Tim Cross 2011-06-13 4:53 ` Now: Emacs<->Mozilla Integration -- Was: " Mohsen BANAN 2011-06-13 7:37 ` chad 2011-06-14 3:57 ` Tim Cross 2011-06-14 3:53 ` Tim Cross 2011-06-14 8:37 ` Daniel Colascione 2011-06-13 15:47 ` Ted Zlatanov 2011-06-14 3:42 ` Tim Cross 2011-06-14 14:53 ` Lars Magne Ingebrigtsen 2011-06-14 15:01 ` Julien Danjou 2011-06-14 17:08 ` joakim 2011-06-14 16:17 ` Ted Zlatanov
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.