Is there any way to debug the progress of editing with this extension? Just can't get it running. After exiting Emacs (C-x C-c) the textfield in Chromium flashes yellow, but theres no text in it :-(

Thanks for the great extension, I'm frequently using the Developer Tools in Chrome and each time the extension is updated I have to manually comment out the console.log statements in order to avoid being swamped with logging in the Console. Any chance they could be removed from the released code?

Thanks,

Matt.

Changing major mode of the buffer makes the server commands stop working.
This is fixed by making the appropriate variables have a permanent-local property of t.

I suspect this is a built in limitation to Chrome to prevent malicious extensions taking control and preventing the user from ever seeing a safe extensions page. This limitation doesn't seem to be shared across the rest of the Google domain though (thankfully).

It would be awesome if the popup frame's font, width and height could exactly match with the text box. I tried for a while but didn't get anywhere.

Go to any discussion thread you're a member of. Pick a post and click
"Reply", observe that the text area is correctly tagged with an "edit"
icon. Clicking on it doesn't trigger emacs, however.

If I quit an emacs via C-x C-c which has the edit server running, then I always get Active processes exist; kill them and exit anyway? (yes or no) even when there are no active clients of the server. It is annoying to have to type yes each time in this case.

I use AquaMacs with to emacs-server, and want to edit some non-ascii UTF-8 characters. These are replaced by spaces, in the text-area.

Alt-E is a standard Chrome keyboard shortcut for opening one of the two main Chrome menus (the other is opened with Alt-F). So I'm not sure how Alt-E in this extension could ever invoke the editor. So the default shortcut should be better, but more importantly it should be configurable by the user. Thanks!

I am using Chrome on 64-bit Ubuntu Linux. I get an absurdly huge button sometimes. For instance:

http://www.thegatesnotes.com/Personal/Steve-Jobs

Hi,
Thanks again for the great extension!
I edit a lot of wikipages and this is a life savor.
Now, one thing I wish was possible would be to update the textarea each time I save BUT not quit the session. A 'C-x C-x' could sever the connection once fully done
Another wish along the same line would be to save the buffer in a predetermine location on the disk and allow to not delete it. I have been saved by those "temporary files" a few time when I was using mozdev in the past.

Thanks!

Following the example of It's All Text might not be a bad idea. It creates an object for each tagged node of the DOM. to track each text area. This object tracks the listeners added to each event and will remove and re-add the listener each time it is iterated through.

I recently upgraded my Ubuntu Linux from 10.10 to 11.10 and now edit-server does not work.
I've verified that it is running on port 9292 in Emacs via M-x list-processes :

Proc Status Buffer Tty Command

edit-server listen edit-server (network stream server on 9292)

but using the edit button in Chrome turns the status icon red and the hover says

Un-handled response: 502

Also, when I try the Test button from chrome://settings/extensions -> options -> Test
I get the same error.

I have the latest edit-server.el from this github site.

The original ticket.

I think this extension (having an "edit-server" inside emacs!) is the right place to add the functionality of opening local files for editing in emacs.
For additional info, please see this note, etc.

Regarding using file: protocol instead. First, it's not working (not out-of-the-box, not here, on osx, at least). I think it's because of righteous security reasons.
Even if it had been working, it wouldn't cut it. For many reasons — I'll go into detail if requested.

In the future, please don't close a ticket until the reporting party has a chance to review your non-/resolution.

Thank you. I'm positive that implementing this feature will make this extension even more popular.

This is my preferred way of using It's All Text under FF. If you did this, I'd be one step closer to switching to Chrome. Thanks!

When I click the "edit" button and an Emacs frame is launched, the buffer is not in edit-server mode. I can manually enable it using M-x edit-server-mode.

Output from Messages buffer when I click 'edit' in Chrome:

Ispell process killed
Starting new Ispell process [default] ...
Modification-flag cleared
Toggling edit-server-edit-mode off; better pass an explicit argument.

Using the emacs edit server on the local machine which is Debian Linux. Server is running as same user who is browsing. I've enabled the double-click and Alt-E invocations as well. Nothing I've done seems to launch the editor.

There should be an option in the extension to disable insertion of the little blue edit icon. This messes up websites and is not necessary if double-click-to-edit or the keyboard shortcut are enabled.

This is my release:

Aquamacs:
GNU Emacs 23.3.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
of 2011-10-25 on braeburn.aquamacs.org - Aquamacs Distribution 2.4
Copyright (C) 2011 Free Software Foundation, Inc.

Chrome: 17.0.963.79

MacOS: 10.7.3

Just noticed recently, so I'm not sure what "event" caused it to stop working. When I kill the buffer, the textarea in Chrome highlights yellow (as expected), but the text doesn't return.

I've also noticed that some webpages I used to edit with this plugin (specifically Redmine) is no longer recognized.

Thanks.

The extension works great for me in general. One special case I'd love that isn't working is gmail's web interface (mail.google.com). I think they aren't using a simple TextArea directly as the mail body entry widget or at least its obfuscated in some way.

Hi, I edit files from it's all text, as well, and have my major-mode all set up through auto-mode-alist. Can you mention in the docs that people can use the following to not fracture their major-mode setting into different variables?

(setq edit-server-default-major-mode
        (lambda ()
          (let ((buffer-file-name (buffer-name)))
            (normal-mode))))

On some random site like this that's only serving up a text file Chrome gets an exception in this code:

    if(theme && theme != '') {
        var el = document.createElement('link');
        el.href = chrome.extension.getURL( 'css/sh_' + theme + '.min.css');
        el.type = "text/stylesheet"; el.rel = "stylesheet"; el.async = false;
        document.getElementsByTagName("head")[0].appendChild(el);

The problem is the last part:

document.getElementsByTagName("head")
[]
document.getElementsByTagName("head")[0]
undefined

You can't call appendChild on undefined.

The solution is to check if ("head") yields an array, and if not just stop there.

I recently updated emacs_chrome and found that GMail became really
slow, as in opening it takes ~20 seconds more, just scrolling up and
down takes 5 seconds instead of being instantaneous, when start typing
an address to send mail to the auto-complete takes several seconds
instead of showing up right away.

I tracked this down to recent changes in findTextAreas(), when I get
rid of this code (which I seemingly don't need, as I can edit normal
text forms and forms on GMail which is all I use anyway) things just
start working normally again:

diff --git a/textareas.js b/textareas.js
index c9bdf21..d784620 100644
--- a/textareas.js
+++ b/textareas.js
@@ -292,20 +292,6 @@ function findTextAreas() {
                        tagTextArea(texts[i]);
                }

-               // lets see if we can find any contenteditable stuff
-               var editable = $('*').find("div[contenteditable='true']");
-               for (var i=0; i<editable.length; i++) {
-                       tagTextArea(editable[i]);
-               }
-
-               // According to http://www.w3.org/TR/html5/editing.html#contenteditable
-               // we should only see true/false or inherit. However G+ seems to ignore
-               // that so lets look for those here.
-               var editable = $('*').find("div[contenteditable='plaintext-only']");
-               for (var i=0; i<editable.length; i++) {
-                       tagTextArea(editable[i]);
-               }
-               
                findingTextAreas = false;
     }

Great project!

I am going to fork it and use it to communicate between my emacs and my chrome, in order to manage bookmarks, etc in org mode. If I were to create a number of other requests, etc, and hooks for them, would you accept a pull request?

This is probably not a bug in Edit with Emacs, but I'm hoping I could get some pointers on how to fix this.

I've added this function to edit-server-start-hook:

(defun my-process-buffer ()
  "Replace the current buffer with the result of running it through an external python command."
  (interactive)
   (save-excursion
    (shell-command-on-region
     (point-min) ; start of region
     (point-max) ; end of region
     "python ~/somecode.py"
     nil ; don't put output in separate buffer
     t)
    ) ; replace current buffer contents with output
  )

This all works beautifully, however the operating system (Ubuntu 11.04) leaves the keyboard focus back in the original TEXTAREA in Chrome, rather than in the Emacs frame.

Any suggestions as to what I can do to prevent Emacs from losing the input focus, or to get it back?

I have the text-based version of emacs installed, and when I try to open a textarea from Google Chrome, it gives the error

error in process filter: Don't know how to create a frame on window system x

However, emacs is creating buffers for the textareas. I'm probably doing something wrong; I'm not sure how to fix this problem.

It seems like the Disqus text area doesn't work with edit with Emacs. I think it's becoming pretty popular. Do you think edit with Emacs can be made to work with Disqus?

It would be very helpful to know either:

• what edit with Emacs needs from a textarea like theirs,
• or how they need to structure their code to make it compatible with your extension

In either case, it would be great to have some boilerplate to send to textarea developers to make sure it can work with your extension, since (at least) I have a vested interest in making sure edit with Emacs works with as many textareas as possible.

Thanks,
Krishna

example (scroll to bottom): http://venturebeat.com/2007/08/08/disqus-to-launch-new-features/

Nice extension! Thanks!

Can this be made to use the native emacsclient server? I use that (on Windows) to have one instance up and send file edit requests to it, and it'd be nice to use the server.el that I'm already using rather than both server.el and edit-server.el. (I tried setting the extension port to the server.el port and got authentication failed - I believe the extension would need to look for the EMACS_SERVER_FILE env var, read that file and provide the key as the first communication to the server.)

Rob

Emacs 24 adds package.el which makes it easy to install packages and scripts in emacs. package.el supports multiple repositories, one of which is http://marmalade-repo.org/.

It would be trivial to upload edit-server.el to this repository and that would make it a lot easier for users to install the script. While I could do this, I believe it is better if it's done by the author of the script.

Alf

On Wikipedia (and I suspect other MediaWiki sites), the edit button does nothing. The context menu brings up an empty buffer.
Upon saving, the textbox isn't updated.

I have just used edit-server.el again after a very long time. Unfortunately I was quickly reminded of why I stopped using it:

I used edit-server to write a really long message. It was very pleasant much more pleasant than using a textarea.

Then out of habit I tried to save my work - and it's a good habit. I pressed C-x C-s to save the current buffer. Unfortunately I had previously somehow closed the chrome tab containing the textarea. So edit-server killed the buffer and send it's content into nirvana because the textarea where it was supposed to yank the buffer-string had vanished.

Many things can go wrong when editing text - some can be user errors like me removing the output textarea or it could be Emacs or Chrome crashing. Emacs is usually very good at dealing with crashes - a recent version of files being edited can always be recovered.

I tried to do the this here too but in this case I could not recover anything. Maybe I have done something wrong since I was panicking a bit. But it does not mater because

I pressed Emacs' default key binding for SAVING resulting in edit-server DESTROYING my data.

This should simply not happen.

First step: do NOT rebind C-x C-s to a command that under some circumstances destroys data.

Step two: ensure that edit-server uses Emacs backup facility to the fullest. I believe this means that the buffer has to be associated with a file. So be it. Create a file in ~/.emacs.d/edit-server-saves/ for each textarea being edited. By default NEVER remove any files from there. Maybe provide an option to clean out files older than x days or something like that - but default to not destroying the user's data.

Well, the subject says all, really: with Edit With Emacs extension enabled, pressing 'r' in Google Reader spikes the CPU meter and sends the fan howling for like 5 seconds, during which the Google Reader tab is unresponsive. This suggests that the extension is busy combing the page's content for some reason (looking for text entry widgets?), but I'm really not a web programming expert so I dunno.

Disabling Edit With Emacs and restarting Chrome clears up the slowdown, which is why I'm pretty sure I'm complaining at the right bug tracker.

If I'm somehow unique in being afflicted by this, please tell me how I can help debug this.

This issue posting is a direct copy / paste of an e-mail conversation with the extensions maintainer.

Just a minor question / point to make regarding your chrome extension
edit with emacs. (which is stellar BTW).

Many thanks.

It seems to act strangely with Facebook of all things. I'll use the
Status Update box for an example.

Clicking the "edit" button bring us the editor and as noraml, etc...
but when C-c C-c is used to end the editing, the text in a FB comment
box or whathave you changes from:

"What's on your mind" (for a status update) to the edited text. But,
the text is the same faded gray as the "What's on your mind" v.s. the
heavy black text you get withs regular edit of the status box. When
you click post, nothing gets posted.

I suspect it's Facebook's auto-complete stuff being clever. Both
status and comment boxes are quite JavaScript heavy to deal with name
auto-completion. I suspect there needs to be some sort of poking of
the DOM by Edit with Emacs to cleanly let Facebook's javascript know
the text area has been updated.

I'm not sure if this can be done programatically - I suspect we'll
need some sort of site-specific workaround for these sites.

This seemed (if I recall) to be the same issue with "It's all Text" in FireFox.

Any work arounds for this?

Not that I'm aware of at the moment. I'm afraid my time is a little
limited at the moment so I can't promise to look at it anytime soon.
However if you could create an issue on the development page:

https://github.com/stsquad/emacs_chrome/issues

at least I won't forget. If your lucky someone else might even

propose a fix for it!

Hi,

Three nice features in It's All Text were:

1. You could save the file in the editor. This was nice in case of a browser or editor exit or crash -- didn't happen often, but I've fat-fingered an exit key on occasion and this was a lifesaver.
2. It's All Text would update the text area in the browser whenever the saved file contents changed.
3. It's All Text would flash the text area -- yellow, fading to background -- when it updated the text area.

It seems straightforward enough to implement 1 in the emacs server -- we associate a file with the existing buffer. I can implement this if you folks think it useful. Given the current architecture, this can be better than It's All Text since we can save to a user-settable location from the emacs side. My preference is to create a emacs-chrome-edits directory under user-emacs-directory ("~/.emacs.d" in recent emacsen). C-c C-c would nuke this file on exit. We could pop-up warnings if files are found w/o corresponding connections, exposing potentially lost edits to the user.

2 would require sending "update of WIP" notifications to the browser, which would then update the text area as is the case. 3 would happen as a consequence of such a notification.

What do you think? Worthwhile addition?

-Sudish

Sorry if this is obvious or the wrong place to post this sort of thing, but:

So C-C C-C exits, returning the contents of the emacs buffer to the text box in chrome.
C-X C-S copies the emacs buffer to the kill ring, doesn't kill the emacs.
But C-X C-C destroys the emacs buffer and returns to chrome ... even if the buffer is modified! Shouldn't it do the emacs-standard thing of saying "this buffer is modified, do you really want to destroy it?"

XEmacs does not have make-network-process, so edit-server.el won't work there.

After installing Edit with Emacs (EwE), I'm finding that when I save a linked file via "Save Link As", the resulting download is either corrupted or cropped. I didn't see this problem before installing EwE. I don't see the problem with Firefox. And, I can temporarly fix the problem by disabling EwE and restarting Chrome. But, as soon as I re-enable and do an EwE edit, I get the cropped/corrupted saved files again.

Sorry if this is not the right place to start a discussion on this problem---I didn't see a mailing list, didn't see any related issues and figured the main Chrome issue db or help forum would be the right place if it's determined not to be an EwE issue.

I did look through Chromium bugs and noted this one which looked like it might be related:

http://code.google.com/p/chromium/issues/detail?id=30439

FYI, I'm running Chrome 8.0.552.224 on Ubuntu 10.10. Only other extension I have installed is PageRank. I just installed EwE today.

First of all, thank you very much for your efforts.

I'm interested in the browser-editor integration, especially in the chrome-emacs one. I want both to use it personally and to develop some web-development tools around it (both to use personally... etc).

I'm using Carbon Emacs and your extension is working as described.
I wonder if there's a problem to "raise-frame" without opening a new one --
emacsclient --eval "(raise-frame)"
works for me, and there should be no problem to call it right from the edit server code.

The second feature request is opening local files for editing.
Ideally, your extension would (optionally) intercept edit:// links and open the files in emacs (e.g. edit:///Users/johndoe/proj/foo/views/index.haml).

Implementing those will make this world a better place for web app developers :)

If there are no frame visible (i.e. a --daemon invocation) the
edit_server.el code seems to have a problem creating a new frame. The
code actually ends up in the invisible debugger when the frame is
created.

I can see this if I start a fresh daemonised emacs and manually call
(make-frame) from emacs client:

emacsclient -e '(make-frame)'
ERROR: Unknown terminal type

Apparently this should be worked around with (make-frame-on-display)
but I haven't been able to get this to work reliably. I have yet to
rule out my emacs-snapshot being broken itself.

When clicking on the edit-server.el link, It just 404's

the URL is:

chrome-extension://ljobjlafonikaiipfkggjbhkghgicgoh/fancy-settings/source/servers/edit-server.el

Wondering if this can be modified to trigger something like Sublime Text (http://www.sublimetext.com/) rather than be so focused on Emacs?

The installation documentation is confusing in that it suggests you need to run Emacs in daemon mode when using the native extension. That's incorrect, here's how I set up my Emacs to run the native extension in native/server mode:

(if (locate-library "edit-server")
    (progn
      (require 'edit-server)
      (setq edit-server-new-frame nil)
      (edit-server-start)))

Setting edit-server-new-frame to nil will suppress the starting of new frames so editing buffers will be spawned in whatever existing Emacs instance emacsclient can find.

There's really nothing emacs specific about this extension aside from the edit-server.el. To support other editors it would be nice to present the user with a configuration option to change the path to the editor. This would then be passed to the edit server who'd call that instead of the hardcoded "emacsclient" program.

Pressing emacs button results in multiple edit buttons.

Just open up a page with a textbox and press the "emacs" button multiple times.

If edit-server-proc becomes set to nil or a non-process-p value, one can't execute edit-server-done and try again. This shouldn't be the case, but it happened a couple times when I was trying to add some hook code and made it impossible to proceed.

Con: I've needed this functionality since even before Chrome was available. What took you so long?
Pro: It's immediately and significantly improved my web experience, and works very reliably. I'm using it right now to compose this. Truly grateful.

Thanks for a great utility,
Krishna Sethuraman

Currently the edit server is hard-coded to 127.0.0.1 so it cannot be run on a separate "computer" from the computer that chrome is running on. This would be handy for me because I am currently running emacs under AndLinux which basically acts like a virtual machine with the IP 192.168.11.150.

I've spent some time trying to run it with this alternate IP address, if I navigate to the IP in a browser it says that the edit server is running. But the options page of emacs chrome is unable to find the emacs server, although the log in the emacs server (using edit.el) looks fine and reports that it is returning a 200 ok message.

I will try to post my code on Saturday if anyone wants to look at it. Of course, enabling this may be considered a security hole, perhaps it would be better to tunnel the traffic, which I actually should have tried first.

With this extension enabled, I cannot login to http://clipperz.com - it's a free service, so you should be able to sign up and test this.

For some people the browser action button takes up precious space on an already crowded toolbar area. However it is useful for people who want to trigger edit requests for the focused text area direct from the text bar. It also provides useful feedback when there are problems talking to the edit server.

One solution would be to follow what the AdBlock extension does. It installs a separate extension (from it's options page) that works as a companion to the main extension.

Because (provide 'edit-server) doesn't match the file name.