Emacs vs Vim

[firewood]

The tiny ESC key on the MBA 11 keyboard is just a bit harder to hit than might be desired for a vi user.

[SuperMiguel]

the professor uses Ubuntu and he uses XEmacs.. but cant seem to find any way of getting that install on OSX, will try port in a bit

[thundersteele]

Originally Posted by SuperMiguel

the professor uses Ubuntu and he uses XEmacs.. but cant seem to find any way of getting that install on OSX, will try port in a bit

Aquaemacs

You can't install ubuntu on OSX. Ubuntu is an operating system. You can install ubuntu on a Mac though, or you can run a virtual machine inside OSX (virtualbox, vmware, parallels) and install Ubuntu on that virtual machine.

[dmi]

Originally Posted by SuperMiguel

the professor uses Ubuntu and he uses XEmacs.. but cant seem to find any way of getting that install on OSX, will try port in a bit

XEmacs runs in OSX without Ubuntu

[jiminaus]

Originally Posted by SuperMiguel

the professor uses Ubuntu and he uses XEmacs.. but cant seem to find any way of getting that install on OSX, will try port in a bit

If you're going to install emacs via port, you don't want xemacs, you want emacs-app.

emacs-app @23.3, Revision 4 (aqua, editors)

Description: GNU Emacs is a self-documenting, customizable, extensible real-time display editor. This is a port of the latest GNU Emacs source to the OpenStep (or NeXTstep) APIs, as implemented by Cocoa on OS X. It differs from Carbon ports of GNU Emacs in that it makes a more concerted attempt from the ground up to follow OS X desktop and UI conventions.
Homepage: http://www.gnu.org/software/emacs/
Library Dependencies: ncurses
Platforms: darwin
License: GPL-3+

Variants:
fullscreen: Add fullscreen patch
inline: Add inline patch from MacEmacsJP
jpfont: Add Japanese font patch from MacEmacsJP
patches: Add all patches: fullscreen, inline and jpfont * requires fullscreen inline jpfont
universal: Build for multiple architectures

[SuperMiguel]

Originally Posted by jiminaus

If you're going to install emacs via port, you don't want xemacs, you want emacs-app.

well xemacs got installed and ran trough ports

but still not sure which one should i learn...

i mean i dont even know why i should learn one or the other... people just tell me to but dont tell me why... i been using nano for a while and it works fine.. so not sure why to switch

[balamw]

Originally Posted by SuperMiguel

but still not sure which one should i learn...

Learn both.

vi is useful as you never know when you end up on a Unix system that doesn't support curses and you just have to edit some file.

emacs is better at IDE-like language support, but if you're on a Mac or Windows box there are better native solutions. (e.g. if I need to compare a couple of files and merge them, nothing beats emacs + ediff)!

Then, continue to use what makes you productive.

B

[jiminaus]

Originally Posted by balamw

continue to use what makes you productive

This is the important point. For some, emacs is better because they're more productive in emacs. For some, vi is better because they're more productive in vi.

If there was a definitive answer that one is better than the other, then one would have faded off into history.

[balamw]

Originally Posted by jiminaus

If there was a definitive answer that one is better than the other, then one would have faded off into history.

Nah, the butterflies (see xkcd strip posted above) would just keep recreating it.

B

[chown33]

Originally Posted by SuperMiguel

i been using nano for a while and it works fine.. so not sure why to switch

If it works fine for you, then there is no reason to switch.

There's no reason to solve problems that don't exist. If you were having some problem with nano, such as you ended up on a Unix system that didn't have ncurses, then learning to use vi would be worthwhile. Or as an exercise in broadening your perspective, learning vi might be worthwhile. But as a problem that needs a solution, for you, there isn't a problem, so you already have the solution.

The most efficient software design possible is none at all.
The fastest and most bug-free code is the code you don't write.
The shortest learning curve is the one you don't have to go through.

[SuperMiguel]

Originally Posted by chown33

If it works fine for you, then there is no reason to switch.

There's no reason to solve problems that don't exist. If you were having some problem with nano, such as you ended up on a Unix system that didn't have ncurses, then learning to use vi would be worthwhile. Or as an exercise in broadening your perspective, learning vi might be worthwhile. But as a problem that needs a solution, for you, there isn't a problem, so you already have the solution.

The most efficient software design possible is none at all.
The fastest and most bug-free code is the code you don't write.
The shortest learning curve is the one you don't have to go through.

Well if i didnt know car existed and ride a bike to school everyday... It takes me 6 hours to get there but i dont know any other way... People tell me to try a car but dont give a reason why i should.. No one tells me that i can go x mph and that i can get there in 40 min instead of 6 hours... Then if i can still make it there in 6h and been doing it for a long timee why fix a problem that dont exist???

Of course i would love a car... But i know to know what they are, and why they are faster??

[robvas]

You can do a lot of neat things with vim

http://www.youtube.com/watch?v=BPDoI...35DDC3477A316E

There are lots of plugins available to do all kinds of stuff:

http://www.youtube.com/watch?v=_galF...eature=related

Those two videos only scratch the surface.

[seepel]

I have to say, I'm quite surprised/pleased to see how civilized this thread has been. Kudos everyone!

[pilotError]

If your a professional, learn vi(m) as it is installed on just about every flavor of *nix out there. Nothing worse than being asked to check out a problem and not being able to edit a file. Doubly true if you use a hosting agent like Savvis where you can't get X Windows through the firewall.

If you just talking about your personal Mac, it really doesn't matter. Get a visual tool like TextMate or TextWrangler. Vi and emacs are both handy if your living life in the terminal.

If your a Sadist, use Ed the line editor.

[AlanShutko]

Vi and Emacs are both extremely powerful text editors that can make editing things a whole lot easier. If you're just changing a config file once in a while, nano is fine. If you're editing longer documents, or are programming, or need to process larger amounts of text, vi and Emacs both give you more powerful tools to do that.

Here's an example of something I did last week with Emacs. I sync my home directory between multiple computers, and some files keep conflicting because they're modified on both computers. To fix that, I loaded the log file into Emacs, used M-x keep-lines to keep only the lines of the log file that had the conflict filenames, and used a keyboard macro that I recorded on the spot to delete the extra log message text around the filename, and then convert the filename into the appropriate syntax to put into a plist to exclude a file. Elapsed time, about 5 minutes.

Vi and vim can both do very similar things. If you're programming, I'd really recommend learning a more powerful editor than nano. You could go for one of the mac-specific ones, which are certainly friendlier. I like the fact that both Emacs and vi are cross platform and I can use them on Unix, Windows, or Mac.

I'm a very experienced Emacs user (18 years) and a middling vi user, so I use vi for any minor quick edits to files, and Emacs for anything bigger. One bonus of both of these tools is that they've been around a long time and will continue to be around a long time. Time spent invested learning them will last you for years. Even with new IDEs coming out, most offer some level of Emacs or vi keybinding.

[SuperMiguel]

which one is easier to learn?

[chown33]

Originally Posted by SuperMiguel

which one is easier to learn?

How would we know which one is easier for you to learn?

That's a serious question. Think about how you'd answer it. What have you told us about yourself and your experience that would let us know enough about you to answer the question?


In my experience, I think they're roughly the same in ease of learning. I reached about the same level of proficiency after a couple weeks of each. This doesn't mean everyone else will find the same thing.

What this really means is they both take dedication and practice in order to become proficient. And you will almost certainly need to become proficient in order to benefit greatly. Or you'll have to find recipes (macros) written by others, and I don't think there are vastly more macros for one editor or the other out there on the internetz.

At the moderate to advanced levels, they share similar principles, which is they're both languages dedicated to editing. In the same way, Forth and Lisp are both languages dedicated to programming, but I wouldn't say either one is easier to learn than the other. They have different strengths and weaknesses, different goals, and different logical syntax. They're also both perceived as quirky for casual reading and writing, but with very different quirks.

In the long run, I wouldn't pick a tool just because it's easier to learn. TextEdit is easy to learn, but there are more powerful programming editors with more powerful search & replace capabilities (to pick just one example feature). For example, Xcode's editor has regex, multi-file search, etc. TextWrangler also has a powerful search-and-replace. BBEdit is another. Yet they all are GUI-oriented editors using windows and mouse clicks for basic editing, the same as TextEdit. So in a sense, they are all just as easy to learn as TextEdit. It's only in the advanced capabilities that differences appear.

If you're trying to pick only one to learn, then flip a coin. Study the winner for one week. Work with it. Make it do things. Then switch to the other one and study it for a week. Make it do the same things you made the other do. Then decide for yourself which one you want to continue learning. Or switch back to the other for another week, and repeat.

[McGiord]

Wirelessly posted (Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3)

Mac Write

[ThomasJL]

Forgive me for my ignorance, but when I saw the title of this thread, I assumed that it may be about Apple's eMac desktop computers.

[iEdd]

Originally Posted by SuperMiguel

which one is easier to learn?

Do the following:

- Open terminal
- Type vimtutor
- Go through the whole tutorial (couple of hours?)

- Type emacs
- Type C-h t (hold ctrl, press h, release both, then type t)
- Go through the tutorial

That will give you a feel for the basics of each one, and I think at that point, you will probably form your own opinion about which you prefer to use.

[murrayE]

Originally Posted by talmy

Which is why I assign the useless caps lock key to be a CTRL key. I also normally use a 23 year old Northgate Omnikey keyboard which has CTRL to the left of the A and also has an easily reachable ESC key for VI users.

I used Northgate Omnikey keyboards for years with Windows PCs, and later essentially the same thing now branded as Avant Stellar, made by Creative Vision Technologies. And, having learned to type (as it was called back then, not "to keyboard") on a manual typewriter, I swore I'd only give up the manual feedback of such mechanical-switch keyboards when they were pried out of my cold, dead hands.

But then I junked my PC for an iMac with an Apple wireless keyboard last year, and I'll never go back!

I do agree with you that having the Ctrl key next to the 'A' is the sensible location. (It was one of IBM's several redesigns of their keyboards that forced everybody to follow suit.) But on the Mac, the Cmd key is essential. Where do you map that on your Omnikey?

[SuperMiguel]

Originally Posted by iEdd

Do the following:

- Open terminal
- Type vimtutor
- Go through the whole tutorial (couple of hours?)

- Type emacs
- Type C-h t (hold ctrl, press h, release both, then type t)
- Go through the tutorial

That will give you a feel for the basics of each one, and I think at that point, you will probably form your own opinion about which you prefer to use.

i did this for about 5-10 mins on each and atm vim seems alot easier/faster 1 key > 2 keys =)

[talmy]

Originally Posted by murrayE

I do agree with you that having the Ctrl key next to the 'A' is the sensible location. (It was one of IBM's several redesigns of their keyboards that forced everybody to follow suit.) But on the Mac, the Cmd key is essential. Where do you map that on your Omnikey?

The caps lock key on the Omnikey keyboard is mapped to the Cmd function. The caps lock key on the Omnikey keyboard is in the same location as the Cmd key on the Apple so it's easy to go back and forth between the Omnikey and the Apple keyboards (at least after I've mapped the caps lock key on the Apple keyboard to be Control).

I'll use my wireless Apple keyboard when I'm not doing heavy typing, but switch in the Omnikey for heavy work. I know I'm faster with the Omnikey. I've got a second Omnikey on my Window PC at work, and several more "spares" in the closet, although I've never needed one.

[ratsg]

Originally Posted by subsonix

But both vim and emacs are included in OS X.

And, IMHO, those both suck.

That is why I download/compile/install the original vi code and/or nvi.

If you like the built in editors, thats great. I don't, so I look to other options. That is what makes Unix great IMHO, choices.

[subsonix]

Originally Posted by ratsg

And, IMHO, those both suck.

That is why I download/compile/install the original vi code and/or nvi.

If you like the built in editors, thats great. I don't, so I look to other options. That is what makes Unix great IMHO, choices.

Don't you feel that you over exagerate a tad now? New vi, vi improved and the original vi is similar enough to be dealt with in the same vi editor reference I have here. The purpose of my post was intended for the OP who may not know better and download and compile from source just to try the editor. The original vi could apparently only deal with one open file at a time.