> Can acme run without a graphics layer (e.g. X11) beyond VGA?

It would not be hard to make the underlying graphics code work on top of linuxfb. I think a patch for that might be floating around.

> Why does it need more than VGA text if it entirely text-based?

Did you really watch the video? You can see that while acme is entirely about editing text, the UI itself is graphical.

Russ, you probably remember that Aki did a linuxfb version of drawterm for Tiny Horrible Xen; I'd bet the changes could be adapted to Plan 9 Port without too much trouble, really the Linux framebuffer is pretty simple.

I would be incredibly interested in a version of Acme that would not require X windows. Hell, I'd even pay for it.

(I currently run emacs on arch linux with no x)

If you install Plan 9 Ports, check out /usr/local/plan9/src/cmd/devdraw. Russ can correct me if I'm wrong, but I think that's the only place the graphical programs interface with X. You'll need to find the places where devdraw is using X, and replace them with framebuffer code.

Not only have I watched the video, I've used acme.

VGA text is everywhere. No need to switch to Linux (and patch it), switch to OSX, use hardware than runs Plan 9, or any other restrictions. No need to run X11.

It just works.

You have a better imagination than I do, then. I don't see how you can make acme run in text mode and still be acme.

Hmm? Apart from the proportional text what would you lose? Even IBM line drawing characters should be able to simulate the scrollbars and dividing lines. Given a sufficiently high-resolution text mode, multiple columns should pose no problem, either.

Granted, I see no real reason for it, as you might as well hook the existing code into e.g. Linux' framebuffer mode, instead of porting it to curses. It would run over ssh, of course, but so does acme with X forwarding, and the best general solution would probably involve merging sam's client/server mode with acme.