davidben/embedded-emacs

Replace your browser textareas with embedded Emacs instances. Please see README before using.

embedded-emacs's Issues

Initial focus is not reflected visually in emacs

When you first attach an emacs, the focus works, but emacs doesn't draw the cursor black as it should. If you unfocus and focus again, the cursor turns back to black. I've no idea what's going on here at all and whose bug it may be.

Allow strings to be translated, etc.

http://code.google.com/chrome/extensions/i18n.html

I doubt I'll actually ever get translations, but hey why not? And at the very least, making the settings page RTL-friendly seems amusing enough.

Remove focusing hack

We currently forcibly focus the editor from the plugin when spawning a new one in. Better to do this in JavaScript. It'll need a fix to this bug in Chrome. The hack was added in 54d2394.

https://code.google.com/p/chromium/issues/detail?id=27868

Move to manifest version 2 when Chrome 18 is stable

http://code.google.com/chrome/extensions/trunk/manifestVersion.html

The only thing that needs to change is background_page is now background. Also resources are no longer accessible to external websites. I don't think this is enough to allow localStorage to be a safe source of config data (since this would have to be enforced at the process level), but it's still good to prevent click-jacking.

Installation Documentation

This is great, exactly what I have been looking for for some time. However, I can't seem to find documentation about how to install it. Even the general Chrome NPAPI installation documentation is non-existant. Any chance you can add something to the readme to point the way?

gVim does not focus immediately

Using gVim requires pressing tab before you can type. This may not be fixable in the extension, but it would be good to understand exactly what's going on with focus here.

Restrict container plugin to chrome extension

Chrome's process model (iframes run in-process) prevent embedding a plugin in a page without making it public. The public container plugin is already simple enough, but it may as well make some attempt to enforce more fine-grained embedding restrictions even if Chrome can't. (It also considerably increases the entropy of the plugin list for people who care about that, but that one's harder to resolve.)

The <embed> element should be replaced with an <iframe> to an extension-owned page which contains the fullscreen container instance. Then the plugin can enforce that random pages can't instantiate it.

Find XEmbed-capable terminal

It'd be good to have a sample configuration using a terminal + console-based editor. Unfortunately, xterm -into doesn't want to take keyboard input (looks like it doesn't actually do XEmbed). urxvt -embed almost works. It claims to support it and everything, but does not send XEMBED_REQUEST_FOCUS when you click in it. This means there's no way to get focus back after it's lost it. (I don't think plugin containers are part of widget tab order. Really they should be part of renderer tab order, but that has the same dependency as bug #5.)

Remove CSP dummy workaround

The background page loads the private plugin with a dummy URL to appease WebKit's CSP implementation. It has since been fixed to handle empty URLs as coming from the embedding page, so when Chrome 17 rolls to stable, that silliness can be dropped.

Restore textarea focus after editor exits

The focus should move back from plugin to textarea after emacs has been closed. Unfortunately, just calling focus() on the element doesn't seem to work from the content script, so I'm not sure what's going on there.

Possibly that a content script isolated world is just not allowed to set DOM focus.

Unify coding style

The coding style here is atrociously inconsistent. Just pick something and stick with it. Maybe just convert it to straight-up Google C++ style since I'm pretty used to it anyway.

Launcher should validate window id

Right now the launcher plugin does not validate the window id in any way. This means that a compromised renderer can, if embedded-emacs is installed, launch a copy of the user's editor with an arbitrary integer as the parent window id. This is probably not horrible, but it's still not nice. Better would be if the container plugin reported an opaque handle to the particular and the launcher could somehow convert that handle to a window id by communicating with the container. (Maybe by querying some control instance of the container, instantiated on the background page.) Or the handle doesn't have to be opaque and just provide an isValidWindow hook?

Unfortunately, this would complicate the container plugin, and I'm not too happy about making the public plugin more complex.

Also, this means I should probably care about race conditions between container instance destroy and editor launch.

Investigate using Command API

http://code.google.com/chrome/extensions/trunk/experimental.commands.html

This could be used to register the keyboard shortcuts. It'd involve more plumbing, but it could plug the hole where a compromised renderer can launch arbitrary many instances of the user's editor. The background page could ensure that every launch corresponded to a real command activation.

Workaround Emacs 23 sizing bug

When using emacs23 (the most recent released version), it seems to get the size wrong. Probably this is some race condition or something that maybe is hidden in usual reparenting window managers? I've heard that it occasionally comes up when using xmonad?

A stupid workaround would be to jitter the size of the window 100ms or so after attaching, but that's kind of lame and flaky. Better would be to find some elisp code and add a note somewhere that you should insert it into your .emacs.

Alternatively, wait for emacs24, whenever that will come around.