Alex's Adventures on the Infobahn - chrome

Edit with Emacs v1.16 released

2020-12-24T16:10:00+00:00

Despite what I said last time it seems that this is still a useful tool for me. I had some free time to peruse some of the open issues and managed to work out what was breaking the GMail interaction and work out a fix. While Atomic Chrome provides a nicer interactive experience with direct feedback the release of Crostini keeps the Emacs flame alive on my Chromebook. I suspect I still need someone to step up who is more conversant in the web languages of Javascript and CSS to improve the front end experience and maybe tackle the frequently requested feature of interaction with fancy javascript editors. In the meantime I'll continue to bumble along and look at what pull requests do come in and leave the pile of feature requests slowly growing.

Merry Christmas ;-)

v1.16

Extension

allow disabling of switch to settings behaviour
whitelist penguin.linux.test for edit server (ChromeOS/Crostini)
fix context menu on newer Chromes (#158)
honour edit_server_host instead of hard-coding 127.0.0.1
use the Chrome/Firefox extension UI to set keyboard shortcuts.
fix handling of spellcheck=false nodes for Gmail (#171, #162)

edit-server.el

use make-frame (see updated docs for edit-server-new-frame-alist)

Edit with Emacs v1.13 now available

2013-11-08T14:05:00+00:00

I've just pushed the latest version of Edit with Emacs to the Chrome App Store. Hopefully most people are already tracking the latest edit-server.el via MELPA but this does introduce a few minor fixes to the extension itself. A new piece of functionality is the ability to trigger bringing Emacs to the foreground from a key-stroke within Chrome. I added this to support running Emacs on ChromeOS which together with my chromebooks.el package gives me a rather nice development environment without having to dump ChromeOS.

So new for v1.13

Extension

* Change the handling of hidden elements (fix bug #78)
* Add debugging for erroneous hidden text areas (#93)
* Add keyboard shortcut to bring Emacs to foreground
* Pass clipboard contents to foreground request

edit-server.el

* add advice to save-buffers-kill-emacs to avoid prompting on shutdown
* add autoload cookies
* fix bug with format chars in url (#80)
* don't call kill buffer hooks twice (#92)
* don't set-buffer-multibyte on process buffer
* support the "foreground" request with optional clipboard contents

Get the latest from the Chrome Webstore.

Edit with Emacs v1.10 released

2011-11-06T20:25:00+00:00

I received a bunch of feedback and patches from my last announcement but I think all the outstanding bugs are now squashed. The edit-server.el has seen some love to make it more idiomatically correct for elisp. The main change is new code to handle editable DIV tags beloved of such sites as Google+ (which you are welcome to follow me on, maybe I should have an elisp circle?).

A big cosmetic change is a brand new settings page which looks less like a web-form from the early 90's and more like part of Chrome. Alas I can take no credit for this but can thank Frank Kohlhepp's fancy-settings library. In fact a lot of the credit should go to third party libraries like jQuery and of course the growing list of contributors who have submitted code for merging.

So the final changelog for 1.10 is:

Extension

* Ignore textareas marked as read only
* Don't tag areas that are not visible
* General clean-up to use jQuery to find elements
* Explicit CSS for edit button to override page settings
* Handle editable DIV blocks (e.g. Google+)
* Optimise the finding of text areas for highly dynamic pages
* Revamp the settings page with "Fancy Settings"

edit-server.el

* Allow customisation of edit-server-default-major-mode
* Allow edit mode to be set by matched URL
* Tweak detection of MacOS X Emacsen
* Change behaviour of C-x C-s to save to kill-ring
* Persist the buffer-local variables beyond mode changes
* Setup keymap within defvar
* Clean-ups to code to be more idiomatic.

Chromium Privacy Plugin

2011-01-10T14:50:00+00:00

Did you know every time you see a Facebook/Twitter/Social Media-de-jour button on a web-page it's reporting your visiting patterns to home base? If you thought Ad tracking was a worrying invasion of your privacy then just consider how much info Facebook has on you along with your browsing history?

While things like incognito mode have their place I'd rather reduce the amount of information sites collect on me by default. Enter the Disconnect extension for Chrome. Simple and easy to use it offers a single click button to re-enable those buttons should you want to "Like" something.

Edit with Emacs v1.8

2010-08-19T11:10:00+01:00

After a relatively quiet period a number of patches have flowed my way so I thought it was worth pushing out a new version. Perhaps the most "important" feature is the edit box flashing and fading from yellow after being updated (like It's All Text). It wasn't that hard to do given jQuery and the colour animation plugin do all the heavy lifting.

We've added a new hook to the edit-server for pre-edit customisation. If anyone has some nice examples of using the various hooks it would great if you could add examples at the emacs wiki.

As ever the extension can be found at the Chrome Extensions site. Development versions are hosted at github.

Full Change Log

v1.8

Extension

* Added option to enable/disable visual edit boxes
* Improved feedback as editable elements come in and out of focus
* Updated text box will now fade from yellow after an update

edit-server.el

* Added edit-server-start-hook for additional customisation when edit starts

Edit with Emacs v1.7

2010-07-29T15:31:00+01:00

It's been a while so I released a new version of Edit with Emacs for Google Chrome(ium). To be honest most of the changes are to edit-server.el. The most major change is moving all the frame configuration options into a single edit-server-new-frame-alist which might cause confusion if people don't read the change log which is:

Extension

* New icon state. Blue=Waiting, Green=In Progress, Red=Error

* Improved mouse-over text for icon to give more useful feedback

edit-server.el

* Move all frame customisation into edit-server-new-frame-alist
* Don't ask user before closing emacs and network process
* Just skip creating new network process if it's already running
* Make sure edit buffer is selected on new frames
* Prompt window manager to bring new frames to the top of the stack (X windows only)
* Enable multi-byte mode on edit buffers for better unicode handling
* Explicitly fail on XEmacs if make-network-process isn't found (XEmacs patches welcome)

First elisp patch for emacs chrome

2010-01-09T12:40:00+00:00

One of the nice things about putting your coding experiments up early and under a permissive license is people can submit patches. I'd been trying to get the native elisp edit server working but I'd fallen back to the working python script as I've been busy at work. However along comes Riccardo Murri who cleaned up the code and got it working. I've pushed the changes to the repo and with a little extra glue spawn it when emacs is in --daemon mode:

;; Do we want an edit-server?
(if (and (daemonp) (maybe-load-library "edit_server"))
    (edit-server-start))

And bingo you save the cost of 2 unnecessary fork/execve's to get emacs editing your Google Chrome(ium) hosted <textarea>. It seems to have an odd interaction with longlines-mode though which I need to investigate, perhaps longlines mode does magic stuff with the buffer text on save which gets skipped when the edit server does it's thing?

I've submitted the extension to the Google extension gallery although it's currently held up in actual physical paperwork. As my content script needs fairly liberal permissions to work I have to at least demonstrate I'm not an evil hacker/spammer intent on creating browser malware. I may take advantage of the delay to some clean ups to the browser feedback as we will likely be housebound sheltering from the weather. That is of course unless anyone else beats me to it :-)

Update on Emacs Chrome

2009-12-21T13:49:00+00:00

In my spare time I've been mostly bashing away at trying to implement an edit server for the Emacs Chrome extension in Emacs Lisp. It's taking longer than I hoped mainly as it's the first time I've ever tried to use the Emacs Lisp Debugger and it's fairly alien compared to the usual functional GDB's of the world which I'm used to. The current version should be pushing canned response back to every edit request but for some reason it's not working. Once the basics are working the rest is just cleanup :-)

In the meantime I've pushed a few additional updates to the repo. The first makes the extension usable on multiple tabs by passing the "port" back to the XmlHttp handler. You would think being an Emacs user I'd be used to the first class function paradigm by now but it's not something I really get a chance to use much in the day job. I'm not sure if:

function contentTalking(port)
{
    port.onMessage.addListener(function(msg, port) {
        handleContentMessages(msg,port);
    });
}

is the correct way way to pass parameters from the local function's scope to the listener function's scope but I'm not sure how else you'd do it. Certainly the pattern of declaring functions in-line seems to be very common in the world of Javascript (as well as Emacs Lisp via the lambda () directive). If you look at the earlier version of the code you'll see my C habits come through, after all it's just a pointer :-).

I've also tweaked the pycl.py edit server code to handle running on Python 2.5 as my work box is running a fairly old Hardy Heron. Anyway the latest results of my hacking can, as always be seen on github.

EDIT TO ADD: Well that seems to be working now. I was getting confused in my use of car/cdr which is probably a result of too much Forth when I was younger. They are not equivalent to grabbing the first and next bits off the stack. Specifically cdr returns a list, so you had better munge it to what you want if it's not a list.

Chrome and Emacsclient

2009-12-12T13:24:00+00:00

I had a number of things planned to do today, one of which was to go pick up some parcels that the local delivery service failed to do. However some workmen started digging up the road opposite my house. As the un-controlled single lane alternating between inbound and outbound traffic is right outside my drive I decided I couldn't face the horror and stayed in to tinker.

I've switched my default browser settings to Chromium on all my machines. It's just so much faster to launch and get around. I've sacrificed the security of NoScript but I'm less worried about Flash on my netbook now as each tab kills any CPU sucking plugins when deleted. The only major problem left is finding an alternative to It's All Text so I don't have to fire up Firefox every time I post something to the web (like this blog entry).

I decided to have a look into what was involved in getting a Chrome extension running that can call an external editor. I checked the group before I started and stumbled on Dave Hilley's rough cut solution. It's almost exactly what I need so I've started toying with it.

Due to the way Chrome works it doesn't seem possible to spawn additional processes from Chrome itself (unless you want to use the NSAPI sledgehammer). Dave's solution is a simple server script that the Chrome extension can make calls to using XMLHttpRequest's. The server is written in Python but my first thought is there is no reason why the local emacs --daemon couldn't terminate the calls directly. Certainly the example echo server on the Emacs Wiki doesn't look too complicated to hack up.

The other thing that could be improved is the detection of text areas. Currently the Javascript just searches the DOM for text areas and selects the first one as a candidate for editing. I'm fairly sure it would be possible to detect either which text area currently has focus or do something more akin to It's All Text and wrap unique <div>'s around each text area and have a edit content button.

Unfortunately I seem to be having trouble getting the Chrome side to work. Trying to set breakpoints in the extension scripts keeps causing the extension to "crash" so it's hard to follow the sequence and tweak it. I also have to wrap my mind around Chrome's distinction between "content" and extension scripts. Still at least it's something to work from. Of course if anyone else wants to jump in with ideas (or even better a pointer to a better piece of emacs server code for handling XMLHttpRequests) then don't let my stumbling hack attempts hold you back :-)