emacs or vi

Emacs rooz. Bring it on vi kids~

vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim vim

>>161 is a maid.

Admin: "Well, there's nano and emacs, nano joe and emacs, nano and vim,  nano emacs and vim, nano emacs joe and vim, vim emacs joe and vim, vim nano vim vim joe and vim, vim joe vim vim emacs vim mcedit and vim..."
Cow-orkers: "Vim vim vim vim..."
Admin: "vim vim vim nano and vim, vim vim vim vim vim vim kedit vim vim vim..."
Cow-orkers: "Vim! Lovely vim! Wonderful vim!"
Admin: "or TextWrangler, BBEdit with a TextEdit window in a Xcode IDE with syntax highlighting and code completion, with a localized nano in Terminal.app and vim."
Anonymous: "Have you got anything without vim?"

>>164 lie was told!

>>163
>Anonymous: "Have you got anything without vim?"
Admin: "Well there's emacs and viper, that's not got much vim in it"

PSPad = Ultra-Edit > KEdit = some others > mcedit > Notepad > vim > emacs > ed

ed rocks if you're stoned.
VERY stoned.

vim is a detergent.

>>168
So is Linux. http://en.wikipedia.org/wiki/Linux_(washing_powder)

I don't get why people say vim is hard to learn. It's really not that hard. It's just the multi-modality that people don't expect. Once you understand there's 2 modes that you switch between, you can get a handle on most of the basic commands in like 5 minutes.

The thing that makes emacs and vim superior to most other editors for me is that they can parse compiler output and lets you navigate through the errors and warnings easily. You usually don't get that without having a full-blown IDE.

Oh yeah, also, you get to keep your fingers on the home row. Who the fuck wants to move their hand back and forth between home row, arrow/home/insert/delete/pgup/pgdown keys, and the mouse anyway? How annoying is that?

Once you understand there's 2 modes that you switch between,

Oooh, hard. Oh, wait, it isn't.

you can get a handle on most of the basic commands in like 5 minutes.

How basic is "basic"? Arrow keys, delete letter, delete word, replace, insert, append, start/end line, search? That's about right, I'd say. The question is how much you'll remember tomorrow.

VI, easy to learn? I've been using it for years and no, it's not "easy"; after all this time, I still don't know how to cut and paste in it.

Emacs and VI are made of lose and fail for -among many, many other things- using bizarre and obscure means to do things that are simple in other editors (eg, search and replace, cut and paste).

>>172
copypasta: y for copy, d for cut, p for paste, v for visual mode for fine selection, pasting is a skill

after all this time, I still don't know how to cut and paste in it.

Then you haven't even glanced at the manual.

>>173
In notepad (and most modern editors)
ctrl-arrow for word selection; edit->copy (to copy), edit->cut (to cut), edit->paste to paste. You can also do the whole ^c^v bit too, of course.

But if you don't know about the ^c^v bit, you can simply look at the interface and say "ok, there's a menu called edit, wonder whats there? oh, that's how I cut and paste, ok". Whereas with vi you have to plummet the depths of some manual written in moon language somewhere.

>>174
I looked at it enough to see it is written in moon language.

>>175
GVim has optional menus, enabled by default for dummies. The first thing I do with a fresh GVim install is disable anything that smells of GUI.

GVim has the nastiest GUI that ever graced this planet.

Honestly, as much as I dislike vim, I think they should lose the GUI anyway and stick with CLI. The GUI is fugly.

>>177
The nastiest? That would go to Emacs ;)

>>175
So what exactly are you saying? You've been using an editor for years, even though you never figured out how to cut and paste? Man, I hope nobody is paying you for this.

>>179
It's (obviously) not my primary editor, I learned just enough to use it as it's primarily advocated for: Unix systems in single-user mode (where it's the only thing you have, and usually you only need to replace a word or two).

For real editing; I use a modern editor; fuck this zOMG I'M GONNA GEEK LIKE IT'S 1979!!!1 shit.

Why does everyone think that people would only want to use Vi or Emacs because they want to pretend to be leet? I think that once you learn one of these, they really are easier to use.

The trend in modern editors of involving the mouse in more and more aspects of user input is ridiculous. If you think about it, the mouse is only really useful when the input domain involves some kind of pseudo-continuous (x,y) coordinate system. For example, drawing (manipulation of pixels in a matrix) and text-selection (highlighting characters arranged in terms of row, column) really benefit from mouse input. However, things like menus, toolbars, and dialog boxes are just made up excuses to use the mouse. These are all just hacks that map a set of discrete input options onto regions of a coordinate plane. While the objects themselves may be called intuitive (as in they are analogous to real world forms of input, such as push buttons), employing them for input is completely counter-intuitive, as it is a very round-about way of doing things.

I think that once you learn one of these, they really are easier to use.

I'm one of the guys who learned vi. Quite well, actually. And while it's exceptional in a few circumstances, overall I'd say it sucks pretty awful. Simply put, modal editing should rot in hell. We're not using 300 baud modems anymore, guys.

I'm not adept at emacs so this is more tenuous, but I believe it's the opposite extreme: it has one mode (great!), but way too many key combinations.

No, you don't need GUI to make a decent text editor. Having two modes, or several hundred key combinations is not the way to go though.

>>170
Yes, it's hard, because you don't have menus for the less frequent tasks you don't remember what goddamned commands and keys did they use; because the online help sucks grossly; because it doesn't have anything in common with other editors you may already know; because configuring it is just insane; because the several modes and how everything is done is absolutely insane and illogical; and several other reasons I'm surely missing right now. Oh and HJKL is more Unix retardedness. Why not WSAD, like all rational beings would use?

>>171
You even need a command to join lines. Talk about useless editors. I don't want to work for the editor, I want the editor to work for me.

>>174
One shouldn't need a manual to use a text editor. The interface should be self-explanatory and should show you the hotkeys so that you'll learn them with use; keys should be logical enough to be figured out once you know a bit; advanced features should have a quick cheat sheet and should be trivial to figure out. Editors like PSPad or UltraEdit can do almost as much as what vim does plus other things vim doesn't, and they never require you to read anything, just play around and in 5 minutes you'll be doing what vim hackers with years of experience manage to do with vim and fap to as a great accomplishment.

>>176
GVim sucks, wish it didn't, but it does.

>>178
Not denying that; but vim and emacs should share the place.

>>180
Use mcedit for goodness sake, it's nearly decent.

>>181
I use modern editors that don't suck and I never even touch the mouse. Mouse is slow. I work fast. If I need to use menus for something I rarely use, I consider the keyboard first.

>>183
Easy to figure out != easy to use. Perhaps you would advocate replacing a keyboard with a picture of the alphabet, allowing people to click on the appropriate button with the mouse to input the letter of their choice. So much easier than having to learn that elitist QWERTY nonsense amirite?

>>184
That's where you're wrong, usually the things that make the 1970s editors hard to use are things which also make them hard to figure out.

Again, as >>183 excellently put it; the computer works for you, not you for it. If you have to read a manual to figure out how to do basic functions (cut and paste) then the editor FAILS.

We're not talking about advanced functions here; we're talking about cut and fucking paste.

Again, it all has nothing to do with mice; it has to do with the way in wich information is presented to the user. With a decent editor the user has to spend a very minimal amount of time figuring out what he needs to do to do the tasks he started the thing up for.

Again, VI and Emacs are pure, unadulturated Geek Wank. They serve no other purpose in this day and age than to display HOW FUCKING HARDCORE I AM LOL. Want something lightweight to throw on to a boot disk? there's nano or mcedit. Want something more powerful that you can use as an IDE? get UltraEdit. Want word processing? Get a word processor.

There is nothing which either emacs or vi is good at which is not done *better* by more modern editors with far better UIs (often CLI ones, at that) which don't require 500 hours in the manual or give you carpal-tunnel syndrome trying to save a file and quit (I'm looking at you, emacs).

>>185
Don't forget: Want to do some seriously wierd shit to your text? Use a scripting language!

It amazes me that people come up with bloody arcane sequences that would be easier to throw together in a real language. Of course, 99.9% of the time, you won't need to resort to this. Why waste time?

>>185

So, you're saying there are editors better than Vim?

Recommend me one for Linux that is as good as Vim at every task and I will try it out. After 3 seconds I will post back here saying how much it sucks.

>>185
I've never tried UltraEdit, but I know it's not free, it's not available on anything except windows, and even on windows, very few people have even heard of it (nobody I know).

On the other hand, vim and emacs are practically on every installation of *nix, they are free and they are more powerful than any other editor in *nix. I agree that some of their aspects could use updating, but this doesn't illegitimize their use.

So for people who use *nix, yes, there is a purpose for vim and emacs other than, how did you put it, Geek Wank? Believe it or not, there are many real companies that consist of 90% emacs or 90% vim users.

Maybe the people you see everyday are idiots, but there are people who use emacs or vim just because it's the best they have to work with, not because they want to show off. Why is that so hard for you to accept?

Menus aren't terribly useful if your editor is very powerful and offers hundreds of functions. It's even worse if your editor is extendible; if the user defines a new function, where do you put it in the menu system?

>>188
UltraEdit is fairly popular in Windows, but PSPad is free and it's about as good (even better when it comes to macros - fully scriptable in the language of your choice - JS/Python/Perl/VB/...).

As for Unix editors, mcedit is better than vim and emacs, that's not saying much, but it is. It's open sauce, available on all unices worth using, and character mode.

>>189
Uh, that's *exactly* when menus are useful: if your editor has 1000 features, you don't want to learn escape gee sixty four slash colon for every one, you learn the ones you use 99.9% of the time, and arrange the rest in a menu you can quickly navigate.

Good extensible editors let you edit your menus or create shortcut keys for your macros very easily...

>>190
How the crap do you navigate through menus containing 1000 features? Fuck that shit.

>>190
If mc means Midnight Commander, I'm not even going to try it out.

Alright I am now...
Bad things:
* Mouse support.
* Single mode.
* Can't figure out how to open a file.
* Can't figure out how to delete other than del or bs.
* Pops up some retarded dialog when I press esc, containing an option called "Cancel quit"... (Hm? I want to cancel my current action and quit? OK.)
* Can't quit without that dialog, use C-c... same... HELP!! Switch to another terminal and kill the process.
* Didn't clean up the terminal when I killed it. Run reset.
* Open a Ruby file. Almost unreadable due to the blue background with syntax highlighting. Can't figure out how I accidentally opened the menu, so I can't change the background color. Alright, I used the mouse, LOL! Didn't find anything color-related.
* Add a method... no smart indenting. OK, figured out how to open a file... use the mouse LOL! Yet another stupid popup. No tab-completion in the open file dialog...
* Long lines not wrapped in display...
* Replace dialog has too many fields and buttons.

OK, I give up, back up Vim :p

I'm not saying Vim is perfect though, it's Ruby indentation could be improved a bit, and I'm too lazy to fix it. The colors are a bit dim sometimes too, but that's due to my terminal emulator. PuTTY works great... hm, I think I changed dark blue to a lighter shade there >_< Can't figure out how do the same in Konsole, I should switch to some real terminal like rxvt, but I like the S-Arrow session switching, sure beats the ^A^A of GNU Screen... hm, I could map it, and I think I will... although Konsole will probably get the input first :X

>>191
How the crap do you read a 200 page manual and memorize shortcuts for 1000 features? Fuck that shit.

>>193
You don't. Need a feature, search for it from within the editor. Least that's what you do with emacs. You don't bind a key to every single function, just the most commonly used ones. The rest you just call by typing them in to the minibuffer.

>>194
Which you happen to magically know by name.

>>195
:h cut^D
x11-cut-buffer   executable()     autocmd-execute
:execute         execute-menus
Umm... that's not helping my point, damn.

>>195
apropos motherfucker, do you use it?

>>197
That's a joke for a manual system

>>198
Faster than digging through menus trying to figure out what you need.

>>199
Not really. Particularly when you consider the fact that you'd have to do run apropos for even the most basic of editing commands.