Mg: an Emacs-like editor in 160 kb | Hacker News Reader

Mg: an Emacs-like editor in 160 kb

homepage.boetes.org

105 pointssnoopybbt81 comments

> Since it is written completely in C, there is currently _no language in which extensions can be written_; however, keys can be rebound and certain parameters can be changed in startup files.

mg seems almost, but not quite, entirely unlike emacs.

the thing that makes emacs emacs is not the keybindings or the so-called "modeless" editing (which is a misinterpretation by vim folks, emacs is way more modeful than vim), but the built-in scriptability / extensibility.

Not when I'm on some tiny VM or computer and want something nicer than Nano that has something remotely close to Emacs keybindings. Then it's the keybindings, not the scriptability. I just want a reasonable editor.

Learn about Tramp, and for tasks complex enough to need a proper editor, you can edit those files in the same Emacs session you use for everything else. That's what I do with my RPi, for example -- it can pipe edits over an ssh session, so anything with an SSH server is eligible. (Revisiting this comment, it occurs to me to add that all my editing on my main machine is done this way. I play a game or two sometimes, so it runs Windows, but I run Emacs in a Linux VM and edit, in full X11-powered, keyboard-unfettered splendor, via transparent SSH authentication with the Windows host.)

Tramp is terrible. Sshfs is better. I don't think it's hard to think of situations where those options aren't as practical as popping open an editor on the command line that you're on.

> Sshfs is better

In my experience it highly depends on the editor. With Sublime Text 3 on OS X, each keystroke is delayed by SSHFS' latency. It's a pain.

Tramp transfers the files back and forth, always working on a local copy (if I remember correctly). It provides a better experience.

Tramp’s experience gets better when you configure Emacs to keep autosave files somewhere other than alongside their parent in the same directory - unlike the file you’re actually editing, which is indeed only transferred on save or revert, the autosave file is updated very frequently, and this can be painful over a slow link. Keeping autosave files under ~/.emacs.d/auto-save or similar solves that problem; if you can configure Sublime to do something similar, it might improve the experience there as well.

This is a good point about tramp.

I use tramp for minor config file editting, it's not too bad. But when coding remotely, I like to setup 2 copies of code, one local, one remote. I always work on the local copy, then when I need to build, I use rsync to push the local code to the remote server for building remotely (because only the remote server has the os/compiler/cpu resources). It works great😁

It's a bit funny, the most unreasonable thing about emacs are its default key bindings...

Some of the most frequent operations, like switching between buffers or windows takes 3 key strokes!

Vim doesn't appear to be any better in this regard: switching windows is Ctrl+W Ctrl+W (three strokes) and switching buffers is :bn<CR> (five strokes).

Many have opined that that's intended to get people to embrace the built-in malleability and augment the default bindings first thing.

Instead of the usual 2 keystrokes, right?

It can take more keystrokes than that, even, if you have three or more windows.

Or use VIM keybindings on Emacs, so you still benefit from all the extension and scriptability but when you're on a tiny VM you can comfortably use VIM.

You are missing the point of Mg—it's not to replace Emacs as your development powerhouse, but to give you little binary that acts a lot like Emacs but runs in some tiny vm or embedded device somewhere.

You can also cross compile it (which you cannot do to Emacs).

It sounds exactly like all the various attempts people have made over the years to make a vim-alike textarea editor in javascript. They always forget block select mode, or don't implement bookmarks quite right, or something, which ends up in frustration if you're used to using your editor of choice as more than a Notepad.exe-alike.

Lots of people use vi (which lacks block-select mode) as more than a Notepad.exe-alike without frustration

A lot of us only cares about the very basics, and pick emacs (or variations) only because when the choice between editor families that are "always" available it stands between vi/vim and emacs.

Microemacs and derivatives like MG or uemacs dates back to the mid 80's, and has been ported to pretty much any platform and OS you can think of (first time I came across one of them was on the Amiga in the late 80's), so they're practical if you want the same experience "everywhere", including places too limited to bog down with a full emacs, and when you don't want that experience to be vim.

In what sense is Emacs (or emacs-likes) "always" available? In most operating systems it is something will have to be installed explicitly, while I haven't seen a unix-like without a vi-clone or nano in a while. Hopefully the lack of emacs-likes can be addressed with something like mg, but so far I don't see it a lot in the wild.

I believe that Workbench 2+ for the Amiga came bundled with MicroEMACS, though!

In the sense that Emacs-alike's, like vi(m) have been ported to pretty much every OS in existence. It's not necessarily installed, but one will be available.

And Nano is only an option for me to escape the horror of vi if I for some reason can't install an emacs-like.

Mac OS X comes with GNU Emacs. Generally installing GNU Emacs is about one of the first things I do on any machine I use.

Other than that I use Emacs variants in Common Lisp for programming. Mostly derivatives of Hemlock, an Emacs editor written in Common Lisp by CMU in the early 80s.

    crontab -e 
    Select an editor: 4. /usr/bin/mg

there it is, that's why sometimes we need this program.

I'm lost; why wouldn't vim be suitable in this case?

Because some of us use Emacs on a daily basis and don't have vi keys seared into our brains. I know the basics, just for these kind of cases, but given the choice I'd use mg any day over vi.

shouldn't your config management system be doing this ;P

I don't even know if there is an IDE to edit a crontab file. I mean, it's not even remotely difficult.

I think his point is that on most systems, except localhost, you shouldn't be touching the config files with an editor. Those files should be managed by an automated system (config management system). Such as chef, puppet, ansible, salt, cfengine & the lot.

Which begs the following question: what is the smallest programmable editor ?

A Forth REPL ?

Related: Fabrice Bellard[0]'s QEmacs. http://bellard.org/qemacs/ - a 160KB executable provides a mostly complete Emacs experience (sans scripting .. sort of like Mg), but does include syntax coloring, unicode, and watching video inside the editor. A 60KB stripped down version has a feature set comparable to Mg as far as I can tell.

[0] of FFMPEG, QEMU, BPG, TCC, JSLINUX and more fame.

> a mostly complete Emacs experience (sans scripting ...),

That is mostly not like not Emacs? Or did Zwei and other emacsen had the same key bindings as emacs and gnu's readline?

"sans scripting"

The Lisp scripting is the entire point of Emacs. Who cares about the keybindings. I don't really see the point. Can't you just compile emacs? I remember 25 years ago when people thought emacs was too big, and small emacs clones were popular, but in 2015 no one cares, right?

Rather than solving these easier useless problems, why doesn't someone solve the harder problem of making a better emacs clone with a high-performance Emacs Lisp clone. Then Emacs could be used to replace Visual Studio, Xcode, etc. Emacs is an editor construction kit:

http://ergoemacs.org/features.html

https://github.com/syl20bnr/spacemacs

I was thinking the same thing.

I mean, I can run full GNU Emacs on my Raspberry Pi. What's the point of a "micro emacs" missing all the good parts?

You cannot, however, install full blown Emacs on your Netgear router running OpenWRT. Mg is heaven sent in cases like that. Tiny linux machines still exist (Raspberry Pi is not tiny, resource-wise).

Emacs should be able to run on 16MB machines without X linked.

http://superuser.com/questions/313105/ram-requirements-of-em...

A dozen Emacs "clones" already exist for even lower memory machines:

https://www.gnu.org/software/zile/

http://www.emacswiki.org/emacs/Jove

Anyway, like I mentioned, wouldn't time be better spent creating a high-performance clone rather than a partially functional tiny clone?

> Emacs should be able to run on 16MB machines without X linked.

My point exactly. These little routers have just a few megs of RAM. Emacs also has ~70MB of (compressed!) elisp files. On a machine with single digit MBs of flash, that's just not workable.

And! Even if you do have 70MB of disk and 16MB of RAM available, Emacs isn't necessarily performant. Emacs was dog slow when I had a $5/month prgmr vm, but Mg was blazing fast.

> A dozen Emacs "clones" already exist for even lower memory machines

Mg isn't new, in case that is what you are thinking (it's at least 10 years old).

I tried a bunch of tiny emacs clones a few years ago and Mg was the absolute best. All the rest had weird gratuitous differences or were missing obvious important keys (one of them didn't have M-d). Mg isn't complete (obviously) but it has a surprising number of plain editing keystrokes built in and functions perfectly for editing conf files or crontabs or other small remote tasks.

> Anyway, like I mentioned, wouldn't time be better spent creating a high-performance clone rather than a partially functional tiny clone?

Whose time? And what do you mean by high-performance clone?

Edit: I see, I missed your (way) above comment. To re-answer: Those tasks are orthogonal. Nifty higher level editing junk is certainly a good idea, and people are working on it. I don't see why it would need to be an Emacs clone though, why not just make Emacs itself better? That's the whole point of it in the first place.

> Mg isn't new, in case that is what you are thinking (it's at least 10 years old).

Mg is based on MicroEmacs, as far as I know, which makes it roughly 30 years old.

Zile is a fauxmacs that's only twice as big as Mg but also provides scripting.

Why would you want to install _any_ editor on a router? If you can ssh into it, you can use Tramp to edit files on it in your full-sized Emacs session, and save what must be scarce storage space on the router besides.

Back in the day I used ange-ftp for such things. My emacs lived where I did and transferred the files hither and thither.

That said, I do use jove every single day...

Would be even smaller without all the weird quotes in theo.c

    "Stop slacking you lazy bum!",
    "slacker slacker lazy bum bum bum slacker!",
    "I could search... but I'm a lazy bum ;)",
    "sshutup sshithead, ssharpsshooting susshi sshplats ssharking assholes.",
    "Lazy bums slacking on your asses."

etc!

i you're lonely, just M-x theo ^M ^M ^M ...

Standard text editor in OpenBSD. As an emacs user for 20+ years, mg feels good and not lacking like the other tiny emacs clones.

I use mg all the time. It only takes half a second to launch and lets me use the emacs keyboard muscle memory I built up over 20 years. Happily I'm able to use a modern editor for most real editing.

Did it ever occur to people that less can be more in terms of features? There might be a reason why people like Torvalds (Linux and de Raadt (OpenBSD, OpenSSH) specifically don't use the stock Emacs.

Here are some other data points: Hickey (Clojure) uses the stock Acqumacs with zero customization and Graham (creator of HN and the first real web app) uses plain vi to edit Lisp.

If you want to use a text editor to get work done, sane defaults and an editor that gets out of the way is king.

> Did it ever occur to people that less can be more in terms of features?

It can be, but it doesn't have to be. Sometimes more is more.

As for your examples...

> Here are some other data points: ... Graham (creator of HN and the first real web app) uses plain vi to edit Lisp.

And you can tell the great amount of effort that makes him put into this very fine website, can't you?

This is probably the worst website I frequently visit in terms of features, design, technical basis and mobile readability. It sucks in all respects except community.

If this is the pinnacle of websites which vi can get us, please move everyone everywhere to anything else, notepad included. I've created better websites than this in Notepad (during my early university years), and that's not a joke.

This has been done before, most notably as JOVE, Jonathan's Own Version of EMACS for the PDP-11. JOVE was written by Jonathan Payne while in high school, around 1980. That had to fit in a 16-bit machine, with 128KB of RAM available to the program.

Mg's lineage is almost as old, coming out of MicroEMACS, first published in 1985. The first version of MicroGNUEmacs, now Mg, was published in 1986.

I use emacs for most of my daily development, but always rely on nano or vi in the terminal due to emacs startup time. I'm going to give mg a shot this week!

1. Tramp.

2. Emacs daemon - as many suggest, why would you ever quit emacs?

But if you do find you shut Emacs down...

3. Slimmed down alternative init eg. https://github.com/ocodo/.emacs.d/blob/master/emacsq & https://github.com/ocodo/.emacs.d/blob/master/emacsq.el (note this init could be even slimmer, but the start time is about 2.5 seconds, which is fast enough, and I get a very well configured environment)

Or just ...

4. emacs -Q - no init.

One of these are going to solve your issue, without having to interrupt your emacs flow.

You could also look at your init for bottlenecks and have a secondary script. Which you can optionally run when you want those features. Keep the real init minimal.

There's many strategies.

You could also run Emacs as a server.

I've actually looked into this, but it seemed like far too much overhead to simply open, edit and save a file; especially remotely.

Remotely, sure (though I usually use joe for that), but for local edits, I start emacs --daemon as part of my regular login procedure (along with creating multiple terminal windows) and thereafter use emacsclient (aliased to 'e') for almost all file editing.

Only annoying thing is the way it retains buffers for modified files when you exit, even if you choose not to save them.

emacs -q (or faster, -Q) could be used in a pinch, but I find default emacs almost unusable.

You can edit remote files directly in Emacs or simply use sshfs.

My .mg file -

global-set-key "\^h" delete-backward-char

global-set-key "\e[1~" beginning-of-line

global-set-key "\e[4~" end-of-line

set-default-mode fill

set-fill-column 72

Been using it for quite some time and really dig it.

For some curious reason all my browser right-click download efforts on that webpage resulted in a wrong-sized corrupted file. Yet good old curl does the job just fine:

    curl -O http://homepage.boetes.org/software/mg/mg-20150316.tar.gz

And I can't remember when the last time i've had a program compile with just 'make' and no messing about. It's quite impressive. Thank you!

As an Emacs guy, I really like mg(1). The one missing feature is Unicode support.

I'm an mg guy who uses Emacs when he has to. Unlike Emacs, mg is an editor. I don't know what tool-class Emacs properly falls into, but as many people here have pointed out, it's closer to a general-purpose scriptable environment than an editor. Editing is a side-effect of the other capabilities, very nearly. I know at least one person who uses Emacs as their shell.

For those of us who just want a clean, fast, light-weight editor, mg is great. It's what Emacs would have been had it been an editor, instead of something else.

"I just want an editor" is the vi philosophy, and has been since olden times. Emacs users tend to write a lot of emacs modes and lisp macros, whereas vi users generally use external programs or the shell.

The thing is, vi is much better at being "just an editor" than emacs is. The key bindings for vi are highly ergonomic and let you keep your fingers on the home row almost all the time. With emacs, you're playing "twister" with your fingers, often pressing 3 or 4 keys simultaneously just do to some simple task like quitting or indenting a paragaph. vi also supports things like deleting to the end of the line, going to the end of the file, or even appending to the end of a line with a single keypress.

If you're using something with emacs key bindings but no emacs-like extensibility, you're really getting the worst of both worlds. You really should just be using vi. And you will find a lot of people with your philsophy who use it, and it is installed on nearly every system out there.

Patches welcome. The first step would be iconv in OpenBSD base (there are existing BSD-licensed implementations to start from). Then have mg make use of it. http://marc.info/?l=openbsd-tech&m=134581162518146&w=2 (Edit: Or try adding a pure UTF-8 mode)

Lacking the time at the moment, but I've been meaning to hone my C skills and Hacking on OpenBSD seems like the best idea. Hopefully, I can finish this M.Sc. soon :)

Check out Fabrice Bellard's QEmacs. Has unicode, at least.

Try jmacs (part of JOE). It supports Unicode.

It is no wonder that Richard Stallman asked them to change their name away from MicroGnuEmacs, especially when mg is not under GPL.

I would suggest 'jed' as a small alternative to Emacs. Its keybindings are mostly the same, and it's extensible.

http://www.jedsoft.org/jed/

I happily used it on my first Linux computer, which only had 4 megs of ram.

I really like Mg. I tried a bunch of mini-emacsen at one point and Mg was the only one that had a decent set of Emacs key-bindings and didn't have weird gratuitous differences. It's so small that it launches instantaneously, even on tiny, slow computers.

how does this compare to torvalds emacs? https://git.kernel.org/cgit/editors/uemacs/uemacs.git

Hey, OP's point on the topic:

I like GNU Emacs, and I run GNU Emacs most of the time.

I _do_ know how to use vi/vim and I'm quite pragmatic on the matter.

When I am doing server configurations, by the way, vi/vim start up way, way more quickly than GNU Emacs.

This is good, but as I use emacs most of the time, I end up in mixing keyboard shortcuts.

Thus, on my system, $EDITOR is /usr/bin/mg and /usr/bin/vi (vi, not vim) is a symlink to /usr/bin/mg.

So I get emacs keybindings and a fast-starting editor.

If i __do__ need syntax highlighting or anything, i run vim (not a symmlink) or the full GNU Emacs.

Put simply.

At 160k it's not really in the true spirit of Emacs. ducks

really interesting how this tiny, old editor provokes so much "just use emacs" "just use vim" comments. kind of missing the point

How does it compare with Jmacs (part of JOE)?

BTW, anyone have a copy of Gosling's emacs? I know it went closed source, but I doubt it matters at this point.

FYI: the list of Emacs implementations:

http://www.finseth.com/emacs.html

Easier just to learn enough of vi to get around. I mean, if I need a more familiar editor, I'm just going. to visit the file remotely via Tramp, and for simple stuff like quick config edits on remote machines, quicker just to use vi or sed or a Perl one-liner.

Also it's still available for Archlinux (via AUR)

https://www.archlinux.org/packages/community/i686/mg/

Community repo is a different thing from AUR

Cleanng up software older than me: http://blog.anthrobsd.net/043.html

off topic but related: Has anyone had any luck getting emacs to run on an ipad+keyboard, with sensible key-bindings (including a mapping for meta)?

Very neat, I really wanted something like this

Is this toó big for busybox?

It should be ok for a busybox.

But does it have Tetris?

I'd be happier if it just had Zap to Char.

Does it run FTP to read/write remote files?

Reply on news.ycombinator.com