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

101–110 of 277 posts

Re: Emacs and Vim

#101

Post by mercurial »

jerf wrote: post #41
mercurial wrote: post #35

Earlier quoted context omitted.

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…

Generally you have emacs do the remoting. I use emacs in a work environment that is primarily Vim and where we end up logging in to a lot of machines to do development on, and the two things that turn heads in my emacs setups are my fluent and flexible use of multiple windows and frames, and the fact that I'm always using my local emacs and I use Tramp to remote in to the machines, so I don't have to screw around wit…

It sounds like it's only practical when you know you want to edit things in the first place, as opposed to "it doesn't work, let's restart the service in my existing SSH session and have have a look of the log" sysadmin-style-workflow.

Re: Emacs and Vim

#102

Post by MetaCosm »

jerf wrote: post #40
yulaow wrote: post #9

Earlier quoted context omitted.

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.

It's the vim defenders who will claim that the home key navigation is a must. Emacs advocates don't much care from what I've seen. Some of them will be roused to suggest that you learn to use searching better.

Vim defenders will also tell you to use search. Also, why would even Emacs fans recommended corded combos over single keypresses? Give my pinky a break man!

Re: Emacs and Vim

#103

Post by lepton »

Touche wrote: post #55
bastih wrote: 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).

Esc is also C-[, and if you've mapped Control to the home row (eg, swapped with CapsLock) then it's not so bad either.

Re: Emacs and Vim

#104

Post by aaronem »

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.

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 reasonably good at that, too.

"Do one thing well" is a good start, sure. But why not aspire to more?

Re: Emacs and Vim

#105

Post by unhammer »

Spiritus wrote: post #72
phaer wrote: 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…

The reason the backup-directory in emacs is an association list instead of a simple string is that some people might want some backups in some dirs and other backups other places. More powerful → more complex.

Turn on line numbers everywhere by putting this in ~/.emacs.d/init.el:

    (global-linum-mode)
(Yeah, EmacsWiki is a mess, but that's not emacs' fault.)

Re: Emacs and Vim

#106

Post by MetaCosm »

jeremiep wrote: post #62
oafitupa wrote: post #51

Earlier quoted context omitted.

"They also can run in a remote console which for me is reason alone not to use another editor." As a developer, that makes no sense to me. Do you really need a powerful remote editor? What do you need a remote editor for, other than checking that a config file was set up correctly, or reading a log file?

Working remotely for one, where the code is not allowed to leave the office. Also, quick & dirty code changes on development/QA environments when it needs to be fixed ASAP. There's not many uses as you mentionned, but there are times when its really useful.

Working on code that only makes sense against production data... our current "small" dataset is 20TB, our real one is going to land about 150TB. These datasets are a pain to get locally, and a pain to maintain. Way easier to just have an account on an attached box you can use from anywhere.

Another perk of it is using tmux and having a consistent environment you can tap into from work, home, the road, etc.

Re: Emacs and Vim

#107

Post by aaronem »

MetaCosm wrote: post #99
phaer wrote: post #20

Earlier quoted context omitted.

I haven't used CtrlP too much, but what are you missing in ido-mode or helm?

Fast proper fuzzy-find completion on files, buffers and tags that works across multiple platforms and even on files not in source control. In Vim I have it bound to f, b, t -- on my multiple trips over to Emacs land -- I have tried lots of ways to get the equivalent working and always come up short.

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.

Re: Emacs and Vim

#108

Post by MetaCosm »

unhammer wrote: post #105
Spiritus wrote: post #72

Earlier quoted context omitted.

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

The reason the backup-directory in emacs is an association list instead of a simple string is that some people might want some backups in some dirs and other backups other places. More powerful → more complex. Turn on line numbers everywhere by putting this in ~/.emacs.d/init.el: (global-linum-mode) (Yeah, EmacsWiki is a mess, but that's not emacs' fault.)

When I spent a few weeks learning Emacs -- I had to filter out EmacsWiki because it lied to me so many times. :(

Re: Emacs and Vim

#109

Post by falcolas »

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.

I tried Evil for about a month, and couldn't stand it. Some parts didn't work the same (ctags word boundaries), and the need to move back and forth between Evil mode and normal emacs mode when using other emacs plugins (it never worked quite right in plugins like magit) negated much of the benefit of having Evil mode in the first place.

I'll probably be sticking with boring old Vim and the command line.

Re: Emacs and Vim

#110

Post by akerl_ »

aaronem wrote: post #104
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.

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).
Post reply on HN