Live data from Hacker News

Emacs and Vim

martinklepsch.org

81–90 of 277 posts

Re: Emacs and Vim

#81

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,…

I used Vim before switching to Emacs, and also used CtrlP. I've also had the pain of not being able to find a good replacement for CtrlP until I discovered Helm and more specific Helm-ls-git https://github.com/emacs-helm/helm-ls-git . Now I have the opposite problem that Vim doesn't have anything as good as the collection of Helm plugins that I use.

Re: Emacs and Vim

#82
post #55
post #8

Earlier quoted context omitted.

But that means your fingers have leave home row! :(

What key do you press in Vim more often than any other? Esc! Not on the home row (although I'm sure you'll say you remap it to tab).

Remap to tab? Insanity!

I remap it to Caps Lock of course.

Re: Emacs and Vim

#83

Earlier quoted context omitted.

You mean startup time without using the server and client setup is too slow, right? (That's easily solved by, well, using the server and client setup, of course.) I find that in actual operation Emacs is faster and that's the reason I switched from Vim to Emacs. Even after using all the tricks in Vim's :help tex-slow, Vim still lagged when I scrolled or even typed into LaTeX files (unless I turned off syntax highligh…

Ah, I'm not a Latex person. In my experience, vim works fine, even on very large files, unless you combine syntax highlighting with very long lines, in which case you're going to suffer. But yes, I admit that I find silly that I should need a 'server' for a text editor. Not to mention that I remote into various VMs regularly which would also need to get their own server/client setup if I wanted a homogeneous working…

I only found Vim syntax highlighting annoyingly slow on TeX, LaTeX and Pandoc Markdown (which supports embedded TeX math formulas), so maybe the TeX syntax highlighter is the single source of slowness. (Also, there is a tex-slow section of the Vim manual, but I think there aren't sections like that for other languages...)

But moving to Emacs had many other benefits, so I'm definitely glad I did it. The LaTeX is just what made me look for other editors, being the one thing that really bothered me about Vim.

And about the remote VMs: as user jerf said, you only run one Emacs, on a local machine, and use Tramp [1] to edit remote files as if they were local. It's great!

[1]: http://www.gnu.org/software/tramp/

Re: Emacs and Vim

#84
post #19

Earlier quoted context omitted.

> Until it goes wrong Why? Emacs reports errors fine in my experience and if not it includes a debugger. > or you have to delve into elisp What's the problem with elisp? I guess its a matter of preference, but in my opinion elisp is easier to understand than vim script. Emacs includes extensive(!) documentation for it in it's base distribution. Granted, it's a dated language nowadays, but 3rd party libraries - easily…

>What's the problem with elisp? So I was trying to make Emacs not drop its stupid temp files next to the opened file and found this piece of incomprehensible code: (setq backup-directory-alist `((".*" . ,temporary-file-directory))) While in Vim: set backupdir=~/.vim/backups Oh, and it seems I'm missing line numbers, let's google on how to enable them and found this page http://www.emacswiki.org/emacs/LineNumbers I st…

This seems to boil down to "I don't understand things written in a language I don't understand" which is fine and all but haven't you ever been curious why so many people will assert it is worth the time to learn?

I think the second part kind of misses the point, as someone in vim has already implemented the feature you wanted, the way that you wanted. So you are basically turning on a parameter.

What is much more important to ask here is how would I implement that functionality [in whichever editor] from scratch, and can I even do that?

Re: Emacs and Vim

#85
post #49
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.

I thought that neovim was the next vim.

It might be the next one after Evil. Evil is already here, neovim is coming.

Re: Emacs and Vim

#86
post #55

Earlier quoted context omitted.

What key do you press in Vim more often than any other? Esc! Not on the home row (although I'm sure you'll say you remap it to tab).

If you remap Esc to jk you don't even have to lift your fingers.

Another common one is Capslock.

Re: Emacs and Vim

#87
post #68

Earlier quoted context omitted.

What is jk?

Just key 'j' followed by 'k'. I have this in my vimrc for quickly jumping out of insert mode: inoremap jk

To each his own. I'm very fluid with my esc key hitting. I find it to be a very satisfying motion.

Re: Emacs and Vim

#88
post #82
post #55

Earlier quoted context omitted.

What key do you press in Vim more often than any other? Esc! Not on the home row (although I'm sure you'll say you remap it to tab).

Remap to tab? Insanity! I remap it to Caps Lock of course.

Ah, right, I forgot what the common remap was, thought I'd get that wrong, thanks for the correction.

Re: Emacs and Vim

#89
The last time I tried Emacs+Evil I found that when pressing Ctrl+[ there was a slight delay when moving back into command mode. I was constantly tripping up when typing furiously.

This alone was enough to move me back to Vim. Everything else about Emacs was awesome. I would love to go back if I could get over this one problem..

Re: Emacs and Vim

#90
post #71

Earlier quoted context omitted.

Thankfully I am blessed with the ability to move my forearms. I've heard a lot of people talk about keeping their fingers on the home row, and I more or less do that when I'm typing text like this, but for general navigation? I've sat next to a number of people who do it, and I get around my editor faster than they do. Based on this anecdotal evidence, I don't think moving my hand a short distance to reach another ke…

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 further away than that, I'm going to use isearch to get closer.

Sometimes I want to make a complicated motion in the horizontal and vertical axes at the same time in a context which is not well-formatted source code and hence has no good paragraph/word landing points. For this I move my hand slightly further and grab the mouse. It always amuses me watching people try to do it "the right way" and then spend 30 seconds trying to work out what sequence of buttons will get them there, then spend another 30 seconds remembering what they wanted to do when they got there.

I'm not trying to minimise the number of logical keystrokes, I'm trying to minimise the time and distraction of navigation. A few simple operations combined with key repeat seems to work really well. Lots of people seem to neglect the power offered by key repeat.

I'd love to meet somebody who could navigate source code faster than me and learn how they do it. When I do, I'll probably change my approach. However, I've worked with a lot of different people who used a lot of different approaches (yes, including that one where you display the line offset from point and type the number of every jump) and in the past decade I have not found any of them to be faster than me - although I have found a few who were roughly the same speed.

Post reply on HN