Dogfooding Ymacs
Why would I want to use Ymacs? Its purpose was to enable me to write code in a browser, but in the comfort of my desktop, I can use the real thing. And indeed, Emacs is almost irreplaceable, because it's not just about the editor itself, but the immense ecosystem around it. How can one program in an editor without Magit, for example?
But there are reasons. First, to me, there's this pleasure of using a tool that I created. Then, I'm a strong believer in manual testing — the only way to ensure it's reasonably stable is to actually use it (yes, I'm typing in Ymacs right now). Then, some things might even be better than in Emacs, depending on case and setup — for example I noticed that Emacs with js2-mode (that's what I use) will mismatch quotes of nested template strings. That works properly in Ymacs (including indentation in nested expressions).
I thought that if I could quickly switch between the two, I could use Ymacs for editing work, and go to Emacs for anything else, like Magit. Thus came the idea of a dogfood server — Ymacs would connect to a running Emacs instance, and provide a way to load/save buffers via Emacs. That was pretty easy to write. Yes of course there is a HTTP server for Emacs.
Setup
The server requires simple-httpd, but it also loads the color theme generator (because yes, you even get your favorite colors!) and this in turn loads company and ef-themes. Requirement for these could be relaxed, but it's just easy to install them (use standard package.el).
If you have the dependencies, just eval ymacs-dogfood.el in Emacs and then point your browser to http://localhost:8977/dogfood/dogfood.html. If all goes well, you'll get a full-page editor with an empty *scratch* buffer. Press C-x C-f to load a buffer from Emacs. It'll display the buffer list in a popup (fuzzy search is available). Only buffers with an associated file are served. Press C-x C-s to save the current buffer back to Emacs (and to disk!) or C-x s to save all modified buffers. That's all for now.
To make it comfortable you should do two more things:
1. Fix the Ctrl-w situation
Shortly after whining about it, I did more research and I managed to fix the keyboard insanity in Firefox. That doesn't make it less horrible; users should not be doing this crap to a graphical program in 2024. But at least it's fixable. These links should help:
- Customizing Firefox using AutoConfig.
- Disable the sandbox, in order to gain access to the sacred keybindings.
If you happen to use Arch Linux, install AUR package firefox-user-autoconfig-no-sandbox, and then
place the following code in ~/.mozilla/firefox/user.js
:
let { classes: Cc, interfaces: Ci, manager: Cm } = Components;
let Services = globalThis.Services || ChromeUtils.import("resource://gre/modules/Services.jsm").Services;
class ConfigJS {
constructor() {
Services.obs.addObserver(this, "chrome-document-global-created", false);
}
observe(aSubject) {
aSubject.addEventListener("DOMContentLoaded", this, { once: true });
}
handleEvent(ev) {
let document = ev.originalTarget;
let window = document.defaultView;
let location = window.location;
if (/^(chrome:(?!\/\/(global\/content\/commonDialog|browser\/content\/webext-panels)\.x?html)|about:(?!blank))/i.test(location.href)) {
if (window._gBrowser) {
[...window.document.querySelectorAll('key[reserved="true"]')]
.forEach(key => key.removeAttribute("reserved"));
}
}
}
}
if (!Services.appinfo.inSafeMode) {
new ConfigJS();
}
Then restart Firefox, and if all goes well, websites should now receive keydown events for Ctrl-w, Ctrl-n and Ctrl-t (as they should have had since approximately 1997).
2. Enable clipboard API
Open about:config in Firefox and search for asyncClipboard, make sure the following are set to true:
dom.events.asyncClipboard.clipboardItem
dom.events.asyncClipboard.readText
dom.events.testing.asyncClipboard
Also, as per MDN: “The Clipboard API
allows users to programmatically read and write text and other kinds of data to and from the system clipboard in
secure contexts, provided the user has met the criteria outlined in the Security considerations.” — which really
means that your page should be served over HTTPS. I don't know what's the motivation for this, other than to piss off
developers, but oh well. I configured nginx, with a local domain defined in /etc/hosts
, to forward
requests to localhost:8977
. My vhost looks like this (but of course, use Google or ChatGPT to sort this
out):
server {
listen 443 ssl;
server_name ymacs.local; # defined in /etc/hosts to 127.0.0.1
charset utf-8;
ssl_certificate /home/nginx/ssl/test.crt;
ssl_certificate_key /home/nginx/ssl/test.key;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://localhost:8977;
expires off;
proxy_buffering off;
chunked_transfer_encoding off;
}
}
With a proper setup, C-v should paste into Ymacs from OS clipboard, and Ymacs' own cut/copy functions will also update the OS clipboard. The browser will ask for confirmation once.