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.
Emacs and Vim
241–250 of 277 posts
Re: Emacs and Vim
#242Earlier 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.
Re: Emacs and Vim
#243Earlier 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?
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
#244Earlier 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.)
Re: Emacs and Vim
#245Earlier 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.
Re: Emacs and Vim
#246Gah, 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.
Re: Emacs and Vim
#247Whether 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…
Re: Emacs and Vim
#248Earlier 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).
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
#249Earlier 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).
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
#250Earlier 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!