Hacker News new | comments | show | ask | jobs | submit login

> If you're a developer or sysad... learn VIM

I really don't understand this mindset. You don't want to install Emacs on a server? Fine, install mg, it'll do 90% of what I need. If you whine about a 170k binary when a modern vi is 2MB, by god I am not a violent man but I will throttle you with a CAT5 cable.




As a sysadmin, you have to be capable of quickly editing files no matter what or whose machine you're on.

This means that you often don't have the luxury of installing anything on the machine you find yourself on. You might find yourself on a small Linux-based router that only has busybox on it. This is the case for many resource-starved VPS' and other small Linux installs as well. Busybox comes with vi, but not with emacs (or even vim). If a sysadmin finds himself on one of these, he simply has to make do with what he has. He may not have the time, or an internet connection, or the authority to install anything at all. So familiarity with vi in these circumstances is essential.

On very few machines will the situation be reversed: with emacs or mg available and vi not (I have never run in to such a case). So a sysadmin has little incentive to learn or install emacs.

As for mg, even if you could install it, I'm really not sure what it would buy you over vanilla vi. In the kinds of resource-starved environments where you'd actually prefer mg over emacs, you wouldn't want to spend a lot of time editing anything. A quick in and out edit should really be all you could reasonably be expected to do in such a situation... and that could probably be done equally well with either mg or vi.


vi is part of POSIX (the UNIX standard):

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...

emacs is not

So it's not surprising you find vi more places than emacs.

Tim O'Reilly wrote that ORA sold twice as many vi books as emacs. (http://oreilly.com/pub/a/oreilly/ask_tim/1999/unix_editor.ht...)

In 15 years as a sysadmin, I've never seen a machine that had emacs but not vi. :) Though I agree it's theoretically possible. In which case, knowing ed would get you going quickly. Knowing ed can speed up your work in vi, too, you can handle large amounts of text quickly using short powerful ed commands. (for example, write everything from the start of the file to the current line to file /tmp/save.txt: 1,.w /tmp/save.txt Or delete all lines that have a curly brace: g/{/d)

Peteris's excellent ed sheetsheet: http://www.catonmat.net/blog/ed-unix-text-editor-cheat-sheet...


What if you don't have the rights to install anything on the server and the sysadmin doesn't want to install Emacs there? (For good reasons.)

Vi(m) will be there.


> the sysadmin doesn't want to install Emacs there? (For good reasons.)

As I said, even if he doesn't want to install emacs (not that there's any actual, let alone good, reason to do so save being an asswipe) there is no reason not to install mg[0].

[0] unless you refuse to install any other editor than `ed` and `sed` on servers because you believe no file should ever have to be edited there. That's perfectly reasonable. But then I won't find myself having to edit a file on a server in the first place.


There is a good difference between a sysadmin's workstation and/or what I'll call "management servers" - those we use for our own tools and whatnot, and those that we keep up for production use, where uptime is critical and knowing exactly what is going on is paramount.

I use emacs... all the time. It's my favorite editor, bar none.

I use vi/vim every day, because it's always there.

It's not that no file should ever be edited there, but, especially in today's clustered world, it's good practice to keep your servers as minimal as possible.

It might sound silly, but keeping to principles and controlling as strictly as you can get away with the changes that go into your production servers is a good practice that tends to keep things working.

vi is handy because it's always there. Emacs is fine - but it only REALLY shines for me when I have my custom environment set up - for a quick edit, it's just a quick edit.


There's an actual and very good reason not to install emacs on servers. It has had a persistent bug where on terminal hangup it occasionally won't stop but will keep running and rapidly leaks memory, until the OOM killer is triggered and causes random havoc. I'm a emacs user, and so are all the technical people in our company. Doesn't matter - installing it on production servers would still be unacceptable.


As a dedicated emacs user, I would like to know more about this bug. Is there a bug report or mailing list discussion you could point me to? thanks.


Not that I know of. (I've seen it happen on Ubuntu 10.04 / Lucid, Debian 6 / Squeeze, Centos 5, RHEL 6, and with no .emacs).


I can maybe - maybe - understand not putting emacs on a low resource machine (something like a WRT54G, etc). This is coming from someone who loves emacs so much that I was considering posting a comment along the lines of "fire the non-emacs-installing sysadmin, or I quit."


OK, but then you'd uninstall vi before you'd refuse to install mg.


Using mg misses the point of using Emacs. I use Emacs because I can customize it deeply and extend it into a near IDE and universal interface. mg is just a text editor with Emacs-like bindings which is not worth much to me.

Also, the 'vi' on most unix/unix-like systems aside from Linux these days is nvi, not vim. which is about 200K, not 2G.


> Using mg misses the point of using Emacs.

And you completely miss the point of mg:

> mg is intended to be a small, fast, and portable editor for people who can't (or don't want to) run emacs for one reason or another, or are not familiar with the vi(1) editor. It is compatible with emacs because there shouldn't be any reason to learn more editor types than emacs or vi(1).

> mg is just a text editor with Emacs-like bindings which is not worth much to me.

It is of worth to me when I need to edit files on an other machine than my own, I've got the basic navigation and edition bindings embedded in my nervous system (even more so as they're also the edition shortcuts of standard Cocoa controls)

> Also, the 'vi' on most unix/unix-like systems aside from Linux these days is nvi, not vim. which is about 200K, not 2G.

I said 2M not 2G. And OSX uses vim as well[0], so most active VIs are probably vim not nvi. But even assuming it's nvi you have, that merely makes it as small as mg, still no justification to not have mg.

[0] I'm not sure any non-BSD unix-like uses nvi actually, MINIX has switched to elvis and OpenSolaris looks like it uses vim.


> Vi(m) will be there.

It’s not on my servers…ed, on the other hand, will be readily available for everyone :)


Well, there's always Tramp :-)

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


You can use SSH + Tramp and not even open a shell on the server.

Edit everything from the comforts of your desktop!


You don't want to install Emacs on a server? Who cares, I use TRAMP anyway.


TRAMP is great if you're editing from an account where you have access to emacs.

But what do you do when you're in front of a machine that doesn't yet have a network connection?

Or what if you're onsite with a client who doesn't have emacs installed and doesn't want you connecting to anything outside his network, much less installing any new packages on his machines?

These are quite common scenarios for many sysadmins. And in either of them you'd be screwed without at least a working knowledge of vi.

Don't get me wrong, emacs and TRAMP are great! They're just not always available when a sysadmin needs them.


I'm actually puzzled by the discussions in this thread. Just use lftp, and the editor of your choice to edit the files?

EDIT: gnosis mentioned why https://news.ycombinator.com/item?id=5730714 . i've only come across those cases a handful of times though


>Fine, install mg, it'll do 90% of what I need.

oh no, mg is pretty crappy. I use a lot of emacs features and the ones I just need on that file are usually not available.

If I need to choose between mg and vim I'll always use vim, it's far superior than any of these cheap emacs clones.

Use a real Emacs or use Vim... that's it.


Ever since I tried OpenBSD I have replaced vi with mg. However, what if you SSH into someone's server and you have no Root access ? Sometimes you just need to know some Vi basics.


> However, what if you SSH into someone's server and you have no Root access?

I'll suggest that mg be installed, as I always do. Or I'll use TRAMP. Hell, if push comes to shove I can scp mg's tarball and compile it there to get a local mg.

> Sometimes you just need to know some Vi basics.

The number of times I've seen that happen is 0. Literally.


mg is super nice, but I wish it had unicode support.


Torvald's Microemacs uEmacs supports Unicode if I remember correctly: https://www.kernel.org/pub/scm/editors/uemacs/

Never tried it, maybe I should.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: