Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs and Vim

martinklepsch.org

Post reply on HN
Print view View original

121–130 of 277 posts

Re: Emacs and Vim

#121

Post by gnuvince »

asuffield wrote: post #4

Gah, the tutorial keybindings! They are mad. I've been using emacs for a very long time, and I can't imagine using those to navigate. Emacs has perfectly reasonable default keybindings these days, they just aren't the ones mentioned in the tutorial. Command: move down one line What vi uses: j What the emacs tutorial suggests: C-n What I use in emacs: the down arrow

Tell you the truth, I've used Emacs for a long time now (~10 years) and I don't know if I use the C-{n,p,f,b} or arrow keys. I'm more likely to move in larger chunks: search, move by word (M-f, M-b), line (C-a, C-e), etc. If I need to edit a word, I will kill it entirely and re-write it.

Re: Emacs and Vim

#122

Post by pyre »

cies wrote: post #17

Emacs+Evil is the next Vim. And yes, CtrlP is probably the thing you'll miss most. But all the other things I got from switching from Vim to Emacs+Evil easily outweigh the missing CtrlP. Vim was great, until I wanted to customize it heavily. It is simply not made to facilitate things like: child processes, SSH, understanding my code, a visual interface for Git.

> understanding my code

Both Vim and Emacs have a horrible time trying to syntax highlight Perl, but I find Vim's flaws to be more tolerable. Emacs isn't some sort of panacea.

Re: Emacs and Vim

#123

Post by rthomas6 »

Dewie wrote: post #114
akerl_ wrote: post #100

Earlier quoted context omitted.

Do one thing well. My text editor shouldn't be managing child processes or SSHing or trying to be a visual Git interface, and Vim does a great job displaying my code so I can understand it.

> Do one thing well. Do you really demand that an OS should only 'do one thing well'? :ø)

Well, yes. That's what makes Unix OSes so great. Programs all the way down to the command line are separate from the OS. Modules and drivers are also semantically separate from the core.

Re: Emacs and Vim

#124

Post by mmorris »

aaronem wrote: post #74
athenot wrote: post #70

Whether it's vim or emacs, I've always been amazed how these tools can become an extension of the brain like an instrument whose purpose is to materialize a thought process. Framed that way, the editor wars look like a pianist debating with a violinist of the superiority of their respective instruments to convey human emotion. Watching a seasoned vim or emacs user create, mold, shape, reformat text like it was a piec…

> I think there are some mac-centric UX patterns that I have a hard time giving up. I can certainly understand that; I'm a relative newcomer to the platform, and while Emacs (of course) continues to behave regarding meta keys in the fashion I've spent a lifetime learning, getting used to Option-arrows for "move to next/previous word", and Command instead of Control for shortcuts, is really bothering me. (Of course, t…

If you'd like to properly remap move to next/previous word and other commands in Mac OS X, I'd recommend Karabiner (which was previously called KeyRemap4Macbook).

https://pqrs.org/osx/karabiner/

I use it to map the emacs navigation keys for use across the OS, and find it really improves my experience. If you're interested in that set up, I use the following options, which are all listed under Emacs Mode: - Control + PNBF to Up/Down/Left/Right - Control + A/E to Command + Left/Right - Option + B/F to Option + Left/Right - Control + D to Forward Delete

Of course, I have caps lock remapped to Control.

There are also Vi remap options in Karabiner, plus tons of other stuff.

Disclaimer: I'm a bit of an emacs lightweight, so it might be that the remapping options aren't as full-featured as what a more advanced user would like.

Re: Emacs and Vim

#126

Post by austintaylor »

mklappstuhl wrote: post #5
laichzeit0 wrote: post #3

I like that he mentioned CtrlP. It's the single plugin that prevents me from switching to Emacs. There is currently nothing in Emacs (last I played with this was 3 months ago) that is 100% equivalent to CtrlP. There are some close approximations but they're not as good the real deal. I can understand how Emacs guys won't even notice this because they've not worked with something that's better than the best they have,…

Agree. I'm using projectile[1] for now but that somehow messes things up with caching files so that I actually cannot search my project files. I assume that might be a fault on my side though. Have you tried projectile? From reading the Readme this was exactly what I was looking for as a Ctrl-P replacement. [1] https://github.com/bbatsov/projectile

I use projectile with caching turned off with flx-ido for sorting. I heavily favor (projectile-find-buffer) once I get going since loading the whole tree is pretty slow on a large project. I'm way more happy with this setup than I was with CtrlP.

Re: Emacs and Vim

#127

Post by rthomas6 »

athenot wrote: post #70

Whether it's vim or emacs, I've always been amazed how these tools can become an extension of the brain like an instrument whose purpose is to materialize a thought process. Framed that way, the editor wars look like a pianist debating with a violinist of the superiority of their respective instruments to convey human emotion. Watching a seasoned vim or emacs user create, mold, shape, reformat text like it was a piec…

What's wrong with flute players?

Re: Emacs and Vim

#129

Post by clarry »

yulaow wrote: post #9
asuffield wrote: post #4

Gah, the tutorial keybindings! They are mad. I've been using emacs for a very long time, and I can't imagine using those to navigate. Emacs has perfectly reasonable default keybindings these days, they just aren't the ones mentioned in the tutorial. Command: move down one line What vi uses: j What the emacs tutorial suggests: C-n What I use in emacs: the down arrow

Usually the strong defenders of emacs tell you that you must use c-n c-p c-b c-f to move because those are better and you will adapt in a short time. Then the strongest defenders of emacs tell you that you must use whatever you want because the purpose of emacs is that the editor must adapt to you and not the opposite.

Actually I think the strongest defenders of emacs say you use C-s and the like for most navigation. Moving character-by-character is slow and inefficient, so the argument about whether C-n C-p etc. are better or worse than hjkl is irrelevant.

I have my own code editor which is more like vi than emacs, but I'm using interactive search in it.

Re: Emacs and Vim

#130

Post by clarry »

akerl_ wrote: post #100
cies wrote: post #17

Emacs+Evil is the next Vim. And yes, CtrlP is probably the thing you'll miss most. But all the other things I got from switching from Vim to Emacs+Evil easily outweigh the missing CtrlP. Vim was great, until I wanted to customize it heavily. It is simply not made to facilitate things like: child processes, SSH, understanding my code, a visual interface for Git.

Do one thing well. My text editor shouldn't be managing child processes or SSHing or trying to be a visual Git interface, and Vim does a great job displaying my code so I can understand it.

Do one thing well does not really apply to larger user-interface applications that inherently have to aggregate lots of unrelated functionality. It applies to one-shot commands that you'd use in shell pipelines; that's why the other commandment is to use text streams. The point is that by combining these small utilities which do one thing well, you can create the aggregated functionality you need to perform a higher level task. Whereas if you didn't have these little utilities which do one thing well, you'd be scratching your head trying to figure out how to do something that a big monolithic application can do for you but which you need in a different context, i.e. where running that big monolithic application to do that one thing is very very incovenient if not impossible. Why do people quote this out of context?

If you stop and think about it, it's really pretty much impossible to define the "one thing" a code editor does.

Forcing the user build everything out of shell pipelines is not the goal, and achieves nothing. At some point, it is appropriate to build the aggregate and combine these functionalities for the user so that he doesn't have to do it himself. And in many cases, you end up reimplementing the thing because it is more efficient that way. The shell utility is still there for the user should he need it.

Post reply on HN