Hacker News new | ask | show | jobs
by philsnow 4103 days ago
> 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.

5 comments

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 ?