Live data from Hacker News

Emacs and Vim

martinklepsch.org

181–190 of 277 posts

Re: Emacs and Vim

#181
post #120

Wanna have fun with emacs? Try to integrate evil mode nicely in different plugins. Especially if you use totally different key bindings in vi (non qwerty layout for example). It was very painful experience for me. Yes, vim is far from ideal, yes neo-vim is looking like to be next iteration in vim evolution, yes no parallel tasks execution is pain. But at the same time there is vimproc. For clojure integration there i…

Yep, pretty much what I have experienced. I'm a vim user who uses emacs for clojure, and I've found a lot of incompatibilities with other plugins. It's not too bad; evil + paredit make up for those deficiencies.

Re: Emacs and Vim

#182
post #100
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.

Displaying code and editing it are two separate things. Sounds like Vim is pretty bloated acting as both an editor and a pager.

Use ed to edit, and pick a side in the more/less wars if you want to read it.

Re: Emacs and Vim

#183

I still do not undertand the devotion that people have with these text editors. I prefer Vim however I could see myself using it soley or even half the time. I feel like I know the basic commands and it is fast but with the ease of a sublime text or something similar why do people still use these pieces of software so frequently? (Not a rhetorical question)

Craftsmen and tools. It is an age old story, you grow to trust and understand a tool. Programmers and text editors are an extreme example, because programmers often spend 30+ hours a week using a single too, their editor. Vim and Emacs have survived because they are "fit for a purpose"... they are really good at editing text! Emacs has a niche in expandability. You can always twist Emacs to do your bidding... and it…

>Vim has much more of a culture of users, people who want to edit text rather that toy with their editor.

I don’t know about that. I really got into Vim because it’s so customizable. The number of general purpose and very specific plugins is pretty amazing.

And the Vim Awesome site that tracks plugins is pretty damn awesome: http://vimawesome.com

Re: Emacs and Vim

#184
post #71

Earlier quoted context omitted.

Then how do you move multiple lines at a time (4, 16, 64, 256)? To move 16 lines down, I press C-u C-u C-n (of course, the control key stays down the whole time). You either have to press C-u C-u then move your forearm to the arrow key and press down, or press the arrow key 16 times. (Each C-u is a power of 4. You can specify any number by typing it after the C-u, for example C-u 100 C-n to move down 100 lines.)

I cannot recall the last time I wanted to move 16 lines - that would imply I stopped to count the lines. What I invariably want to do is "move down one paragraph" (C-down) or "move to that spot I can see on the screen" (1-6 lines, tap up/down; 6-30 lines, hold the down key for about a second until I'm within a line or two, then tap up/down a couple times; >30 lines and use pgup/pgdown to get closer). For anything fur…

Shoot! I meant to upvote you! (I'm sorry.)

Re: Emacs and Vim

#185
post #153

Earlier quoted context omitted.

I cannot recall the last time I wanted to move 16 lines - that would imply I stopped to count the lines. What I invariably want to do is "move down one paragraph" (C-down) or "move to that spot I can see on the screen" (1-6 lines, tap up/down; 6-30 lines, hold the down key for about a second until I'm within a line or two, then tap up/down a couple times; >30 lines and use pgup/pgdown to get closer). For anything fur…

> I cannot recall the last time I wanted to move 16 lines - that would imply I stopped to count the lines I'm sure something like this is possible in Emacs, but in vim I have it set up so that my current line shows the absolute line number and other lines show the relative line number. If I'm eyeing a particular line that I want to jump to, I just read off its relative line number and hit j or k, according to whether…

I like the idea of knowing relative line numbers, but I have been unwilling to relinqish seeing absolute ones due to how prevalent it is to see them -- diffs, linting errors, and stack traces often include line numbers, and I find it really helpful to be able to easily find that. Go-to-line is supremely useful, but I also find the visual reminder helpful as well.

Re: Emacs and Vim

#186
post #179

Another option for "modal" editing in emacs is god-mode(1). It lets you use emacs commands without modifier keys. I have it set to change my mode-line color when it's activated, it's great if you want a little taste of vim but not the problem of trying to shoehorn vim key-bindings into emacs. 1. https://github.com/chrisdone/god-mode

I used to use this, but I found that a lot of the convenience of modal editing comes from the ability to compose commands. I took the time to learn Vim keybindings; now I use evil-mode and I like it a lot better than god-mode.

Re: Emacs and Vim

#187
post #182
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.

Displaying code and editing it are two separate things. Sounds like Vim is pretty bloated acting as both an editor and a pager. Use ed to edit, and pick a side in the more/less wars if you want to read it.

I realize that you're joking, but... vim is a better less than less is, in almost all cases, for viewing code, because you get syntax highlighting.

I'm not a vim user, but I use it to replace less because syntax highlighting is the bee's knees: (you may need to change `vim74` to whatever it is on your system.)

  alias less='/usr/share/vim/vim74/macros/less.sh'
You can then do things like:

  less Makefile +400
which pairs very nicely with `grep -n`.

Re: Emacs and Vim

#188
post #182
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.

Displaying code and editing it are two separate things. Sounds like Vim is pretty bloated acting as both an editor and a pager. Use ed to edit, and pick a side in the more/less wars if you want to read it.

But ed also displays code. I think you're looking for some way of editing code without displaying it on the screen at all.

Re: Emacs and Vim

#189
post #169

Earlier quoted context omitted.

Because it means you don't have to jump in and out of different modes. The biggest thing that kept me from using vim was _constantly_ typing in normal mode and trying to issue commands in insert mode. Is constantly hitting the Escape key (even remapped to Caps Lock, or using ^[) really any better on your pinky?

I use ^[, and I use my pinky a lot less than I would in emacs, because I do a lot more in command mode than I do in a single emacs chord. I view "insert some text" as its own command. Vim's commands are structured so you can combine orthogonal pieces, where emacs has a separate chord for everything.

Vim does the orthogonality thing better, I'll admit, but Emacs' separate chords tend to follow useful patterns, too.

For example, moving forward a character is C-f, moving forward a word is M-f, and moving a balanced expression forward is C-M-f. Same with b for backwards movement. C-a moves to the previous beginning-of-line, C-e to the next end-of-line. M-a and M-e do the same with statements in place of lines.

I can't even remember at this point how much of this is standard, but I've replicated the forward/backward movement for killing: C-d deletes a character forward, M-d kills a word, and C-M-d an expression. C-h deletes a character backward. Guess what M-h and C-M-h do.

Of course, both editors let you do basically whatever you want, so really the text input issue is just one of whether you prefer chording or modal input. And I'm not saying modal input isn't useful; Magit's input system is closer to vim's than to the rest of Emacs, as is Ediff's, and I like it that way, but I prefer chords for editing -- less state to hold in my head.

Sequential chords, though, like C-c C-v C-d, are right out, and using C-n and C-p and co. for up and down sucks, especially when I try to use M-p to select the last input in minibuffer history and hit M-o instead, prompting me to select Bold, Italic, or Other. I'll change them eventually; the hardest part is deciding what to replace them with.

/aimlessramble. I guess it all just boils down to "Use the tool you can best configure to work the way _you_ want it to." I think the linked article was trying to make the case that Emacs can be that tool for vim users.

Re: Emacs and Vim

#190

I still do not undertand the devotion that people have with these text editors. I prefer Vim however I could see myself using it soley or even half the time. I feel like I know the basic commands and it is fast but with the ease of a sublime text or something similar why do people still use these pieces of software so frequently? (Not a rhetorical question)

Because UNIX shell is the most powerful integrated programming environment for development with any language/technology combination. Instead of your typical menu commands (you are lucky if you have 100 or so commands to do very basic and limited things on a selection that you must build with mouse manually) you literally have tens of thousands of extremely sophisticated commands that can easily be chained together to…

But typing speed is never an issue when programming. It's just not the bottleneck.
Post reply on HN