> 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.
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.
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😁
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).
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.
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!
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.
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.
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.
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.
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.
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:
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.
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.
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.
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."
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.
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!
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.
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.
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:
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 :)
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.
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.
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.