Live data from Hacker News

Emacs and Vim

martinklepsch.org

241–250 of 277 posts

Re: Emacs and Vim

#241
post #226
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…

Yeah, evil-mode just doesn't play nice with lots of emacs utilities. It's a good idea to use evil-mode only in code/text buffers and stay out of it when using e.g. GUD debugging. This, unfortunately, means that you're going to have to learn two sets of keybindings, the vanilla emacs ones and vim keys.

Yeah... getting caught out of evil mode can be scary... WHAT DO I PRESS TO LEAVE... CTRL-F... dafuq?

Re: Emacs and Vim

#242
post #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 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.

In VS, I use VSVim which lets me actually have both absolute and relative line numbers, but it probably wouldn't be difficult to write a vimbinding to bind enabling/disabling the line numbers plugin to a chord/hotkey.

Re: Emacs and Vim

#243
post #206

Earlier quoted context omitted.

It depends on how you plan your future. I've used quite a few text editors over the years (Bluefish, Scite, Homesite, Phase5, Idle, TextMate, Vim, others). I switched to Emacs more than a year ago with one clear goal: Not having to switch anymore. You see, most of the editors above (except vim) used to be good and then were deprecated, sold, stopped, and so on. Which of those has been existing for more than 20 years…

Maybe I'm a bit dense, but when are asynchronous commands a pain point in an editor? I mean, you can run eg a script that forks into the background, right? I'm not sure I really want to do "r! long-running-thing-that-updates-buffer". I can see me wanting to do "! long-running-compile &" (in the background). And I can do that in vim?

One of the things that has caught me is syntax checking. I use the syntastic plugin, set to check syntax on write, and I apparently save my changes pretty frequently. Some files can take 2-3 seconds to run an external syntax checker, during which time I can't edit the file.

I guess the real problem is me saving too often. Others may be trying to run a long make from vim and wanting to continue editing or looking through files.

Re: Emacs and Vim

#244
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.)

In vim, one would type 64↓.

Re: Emacs and Vim

#245
post #129

Earlier quoted context omitted.

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.

Yes! C-s navigation, once learned, is the thing I miss most from other editors.

Agreed. Don't forget C-r too.

Re: Emacs and Vim

#246
post #16

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

I use C-{n,p,f,b} all the time, though admittedly their placement is more convenient with Dvorak. Though I also tend to use M-f and M-b a lot to navigate by words instead of characters. I also often navigate by incremental search.

The nice thing about the C-{n,p,f,b,a,e} is they work on the bash shell command line by default. So learning them is actually really useful, even outside of emacs.

Re: Emacs and Vim

#247
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…

Aquaemacs is a emacs with some very mac-centric key bindings. It drives purists nuts but I kinda think it works really well.

Re: Emacs and Vim

#248

Earlier quoted context omitted.

Lusty Explorer may well satisfy your first two requirements. I don't believe it searches tag files at present, but the capability shouldn't be too hard to add; for files and buffers, I've used it for some years, and find it quite nice.

Actually, I think I have used a clone of Lusty on the Vim side and it worked nicely. Getting tags support working would be nice as well -- I really like the global tags option in CtrlP (I got this function name somewhere in an open file, take me there).

Lusty actually originated on the Vim side, and was ported to Emacs by someone who liked the functionality.

Emacs comes stock with good tags support; once you've built a tagfile, M-. on a tag will take you to its definition. (I don't use tags myself, although I really should, so I don't know whether Emacs can automate construction and update of a tagfile, but I strongly suspect it can; check the relevant documentation for details.)

Re: Emacs and Vim

#249
post #110

Earlier quoted context omitted.

Emacs does a great job at that, too. (In fact, it contains a complete Javascript parser, which is invaluable to me since that's the language around which my professional life revolves.) It also does a great job managing child processes and SSHing. (Or FTPing, or speaking whatever other protocol you need to use to access remote files.) I can't speak to it as a visual Git interface, but I don't doubt it's at least reas…

It's great to aspire to more, and that's why my system has more than one binary in $PATH. If a project wants to release an awesome $thing_doer in addition to their main tool's function, it should be a separate tool. That way I can use esshhelper and egitbrowser and eftp separately from emacs (yes, I know the names are contrived).

Different perspectives; Emacs has a built-in shell, which is closely integrated with most of the editor's functionality -- for example, Tramp, which transparently supports almost every remote access protocol in existence; if I want to copy a directory tree from host A to host B, in bash I might

    mkdir ~/tmp/foo
    scp -r user@host-a:/foo/bar/* ~/tmp/foo
    scp -r ~/tmp/foo/* user@host-b:/foo/bar
    rm -rf ~/tmp/foo
or

    ssh user@host-a 'cd /foo/bar; tar -cf - .' | ssh user@host-b 'cd /foo/bar; tar -xvf -'
while in the Emacs shell I just

    cp -r /user@host-a:/foo/bar/* /user@host-b/foo/bar
and if I want to inspect the result, in bash I

    ssh user@host-b
    ls -R /foo/bar
while in eshell I simply

    ls -R /user@host-b/foo/bar
and all the key management happens automatically, via ~/.ssh/config and ssh-agent, just as it does when I invoke OpenSSH binaries by hand.

Oh, and lest I forget, if I want to edit a remote file in Vim, I have to either ssh to that host and invoke vim there, or scp the file here and invoke local vim on it, or deal with sshfs or something -- the latter of which might seem like a perfect solution, until you consider that I use all of Linux, OS X, and Windows machines extensively in my daily life, and not all of them do sshfs well or at all. By comparison, eshell's

    find-file /user@host/foo/bar/file
is exceedingly simple, and works equally well on whatever machine I happen to be using at the moment. I don't have to worry about marshaling temp files or configurations or, indeed, anything at all; Emacs does all of that for me, quietly, in the background, so that I can spend all my time and mental effort on the changes I actually want to make, instead of doing a bunch of annoying sysadmin work just so that I can make them at all.

There's value in having lots of loosely coupled tools, but it's not the only paradigm worth considering. There's also value in a single, unified interface to an enormous range of tightly integrated functionality; indeed, I've found the result to be something of a combinatorial explosion of productivity.

Re: Emacs and Vim

#250
post #129

Earlier quoted context omitted.

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.

I have my own code editor... That's the best line I've heard to finish an emacs-vs-vi argument!

Well, sure, if by "finish" you mean "unite emacs partisans and vi aficionados in mutual and vaguely contemptuous pity".
Post reply on HN