Using Emacs and/or Vim is also a test of how much you care, primarily because they're not the default anymore, so anyone who uses them cares enough about their programming environment to use a non-default editor, and one which has a rather higher barrier to entry than most at that.
(Although, to be honest, using the GUI version of GNU Emacs as a Notepad replacement is possible: Just ignore the keyboard commands and interact solely via the menu up top. You even get access to at least some neat major modes this way.
Still, Emacs isn't the default, so anyone using Emacs probably knows why, and won't be the kind of person to use it without getting more out of it.)
My experience is the opposite. The reason that I use vim is because I frequently have to work in environments that I ssh into, where X forwarding is blocked or very poor due to latency. It became too painful to constantly switch back and forth between vim, emacs, eclipse, netbeans, etc, so I gave up and settled on the lowest common denominator.
Not to mention that many remote server environments may not even have X installed, or graphics cards, for that matter. I started using vi for much the same reason you did, having to troubleshoot via ssh (and telnet before that) in many variants of UNIX (tm) systems. When I got hold of Vim it was like Christmas for me.
I started learning emacs some time back, but the learning curve (and fighting against Vim muscle memory) vs. needing to get work done for money soon convinced me to try again another day.
I dunno man, I care enough to spend a big chunk of my free time improving my code ability. Thing is, I find it easier to use hotkeys in vscode than in emacs. I'm trying both right now and vscode just seems to allow me to do the things I want to do without like learning lisp or something.
In terms of "caring," I care enough to learn literally all of the hotkeys available by default in vscode, including some I added and changed. I'm a f'n beast in that IDE :P
That's great, but I think you hit on exactly the point the parent was making: to use emacs / vim effectively, you need to do things like learn lisp or spend countless hours tinkering and customizing. IDEs like vscode already come with some great defaults so it gets the full gamut from newbies to gurus. I think the parent was just saying that the emacs / vim group doesn't have the low end of that gamut watering them down.
Everybody that is using emacs cares does not imply that everybody that cares is using emacs. It's a common fallacy, and it is one of the few that remain important even on non-boolean logic.
"Emacs -> Cares, therefore Cares -> Emacs" is a form of abductive reasoning. It's only a logical fallacy if you treat it as though logic guaranteed the inference was true. If you treat it as, e.g., input helping to form priors in a Bayesian model, it can be useful information.
Let's say you have 100 programmers. 20 of them "care". Of the 100, 5 use emacs. P(emacs) = 0.05. If all emacs users care, then P(emacs|care) = 0.25. If I wanted to model this phenomenon, I shouldn't ignore the correlation just because it's not perfectly causal.
Or in plain English, if you care then there's a greater chance you'll be using Emacs.
The fallacy if any is assuming likeliness implies implication. This is commonly known as stereotyping, but it's perhaps more clearly described as generalizing a group stereotype to the entire group.
I do really hope nobody is reading that article thinking about prediction. It's completely full of weak proxies that will lose any predictive power as soon as they are used.
(And that's also why you care about causation even if you are only looking for prediction, because you don't want your proxies to change their meaning as soon as you act on them.)
It is indeed full of correlation that can unmask interesting facts if studied further. And the GP complaint is meaningless if viewed from that angle, so I do really think he was talkinga bout causation.
Well, I do have an idea how to write Lisp but I still never got the hang of Emacs Lisp in particular. (But that may have something to do with the lack of actual effort on my part, admittedly.)
Long time emacs user here with a .emacs which is highly customized and is updated by me frequently. I recently added (not sure what took me so long) code to automatically install packages which are missing (for instance, if I'm starting emacs on a new system).
If you use use-package, you can add ":ensure t" to the configs to accomplish this same thing. If you're not using use-package, you should be :) . Example use:
(use-package unfill
:ensure t
:defer t
:commands (unfill-region unfill-paragraph unfill-toggle)
:bind ("M-q" . unfill-toggle))
I'd recommend counting how many of your use-package forms have :ensure t and how many don't. If more have it than not, instead (setq use-package-always-ensure t).
You don't know what you're missing. Want to be a real beast? Learn vim and emacs, both. You want an editor where "literally all the hotkeys" is literally meaningless.
Or it's diminishing returns, and most of it is busywork (fiddling with settings) and the pride of customization -- as opposed to any real tremendous productivity gains.
And I say that as someone who've used Vi(m) for 15+ years in platforms ranging from SunOS (pre Solaris), to Linux, Windows and OS X. I've also fiddled with Emacs for a year or so before (in uni) but it never really stuck. I use ST3 and Vim (terminal sessions) now and don't find Vim offering any huge productivity boost.
For all the folklore it's just an editor with some nice ideas, and a lot of random stuff throw in stolen from this or that earlier environment (read how Joy came up with vi).
> don't find Vim offering any huge productivity boost
Really? I feel so much faster with Vim bindings. Watching other people try to edit text even with OS or other-editor bindings, let alone just selecting text with a mouse, is very frustrating.
I know other editors have bookmarks, and I imagine they might work as well as in Vim. But, besides Emacs, in what other editors can you 'delete everything up to the next `=`' or 'delete everything from the current cursor position to the start of the third word (to the right)'.
Gah – even cutting and pasting more than a line or two is so much easier in Vim than anything else.
And that's just editing text. Editing code is even harder for me! Trying to remove a 'word' in a long camelCase variable without being able to jump to a letter or a search pattern consists of hitting way too many arrow keys.
I never felt typing speed or special text transformation shortcuts being my limiting factor.
At the end of a day, I'd have at most written 200 or 500 lines of code, and removed as much. Most days less.
And I don't write, re-edit and discard 10,000 lines in the process of crafting those new ones.
Speed of navigating between files (which is even better in ST than in Vim, vim, at least on the Mac, takes more 100s of ms to open a file, and NerdTree is crap) and finding the stuff I want matters more to me.
>I know other editors have bookmarks, and I imagine they might work as well as in Vim. But, besides Emacs, in what other editors can you 'delete everything up to the next `=`' or 'delete everything from the current cursor position to the start of the third word (to the right)'.
That a find at best a slight convenience of marginal utility.
My problem while coding is rarely "if I could delete until the next = more easily" but "what algorithm should I use", "What was the person who wrote this smoking" and "where's the documentation for this API".
I also don't buy the "but doing it with a shortcut/motor skills frees my mind from having to think about editing etc". As I've said, I've used Vim for 15+ years (still do, a decade after every time I'm in a shell). I've known all these shortcuts, used them, etc. Haven't seen it make any great difference in that respect. I'd take better code navigation, linting support, etc over text wrangling features any day.
(Besides I can do it just fine in ST anyway with Vintageous/Six/etc).
I think he probably chose his words fairly carefully: "feel so much faster".
I don't think anyone argues that they can ship a piece of software noticeably faster using Vim or Emacs. Like you said, we're never limited by editing speed. But it's also true that you're not figuring out what code to write one character at a time. You spend most of your time looking at the code, figuring out what to do next. But once you've decided that, there is a little burst of activity during which the limiting factor actually is the motor skill of executing that desired action. In theory, all the little savings might add up, but again, I don't think anyone seriously argues that. I think it's much more that that microburst of activity felt less frustrating while they were doing it.
> I never felt typing speed or special text transformation shortcuts being my limiting factor.
>
> ...
>
> Speed of navigating between files (which is even better in ST than in Vim, vim, at least on the Mac, takes more 100s of ms to open a file, and NerdTree is crap) and finding the stuff I want matters more to me.
I wasn't making any claims about the benefits of Vim bindings for my job as a whole. But why stop there? It's probably also not the "limiting factor" for me as human being.
But it's definitely a limiting factor when I'm writing and editing text.
> I also don't buy the "but doing it with a shortcut/motor skills frees my mind from having to think about editing etc". As I've said, I've used Vim for 15+ years (still do, a decade after every time I'm in a shell). I've known all these shortcuts, used them, etc. Haven't seen it make any great difference in that respect. I'd take better code navigation, linting support, etc over text wrangling features any day.
>
> (Besides I can do it just fine in ST anyway with Vintageous/Six/etc).
Above is even more that's besides the point I was making. I'd take good code navigation over Vim key bindings too. I wasn't saying Vim key bindings are better than anything other than not having them.
And then you basically make my point for me:
> (Besides I can do it just fine in ST anyway with Vintageous/Six/etc).
I do that too; not in ST, but in the IDEs, etc. that I use (e.g. Visual Studio, SQL Server Management Studio, Google Chrome). I assume you do for the same reason I do, i.e. you like the keybindings. I also find the keybindings generally useful and faster than not having them.
I do agree with the gist of your comment that Vim itself isn't particularly great compared to tools with features like code navigation. I don't use any Vim plugins for example tho I've tried a few.
> I never felt typing speed or special text transformation shortcuts being my limiting factor.
You don't because the purpose of all the actions you take while editing text is to not think about it. As a non-vim users, you have trained yourself to not think about the time you spent editing text. You want to move an object of options from one file to another file and move it to another object (something which I did moments ago), then the moment you come to the conclusion that you need to make that change, you start using your mouse, select the object, Ctrl-C, then move to the other file, Ctrl-V, and press the shortcut to auto format. But you don't think about it any more than you think about switching windows when moving from one app to the other.
In vim too I probably think about it no more than you do about your own text editing, but with vim, I don't press modifier keys, I don't reach out for mouse, and opening a file is the same speed as IntelliJ (an editor my coworkers use), using Ctrl-P, if not faster. Traversing files is much faster. Splitting screen and navigating is a billion times faster than what you can achieve on any of these editors. All without using the mouse or modifiers.
But these are only small benefits when compared to the biggest difference I've seen between Vim/Emacs users vs non-Vim/Emacs users. Take for instance, few minutes ago I was doing pair programming with my coworkers, and I noticed that there were thousands of productivity shortcuts that he wouldn't use, and he is not the only one, majority of non-vim using people I've met, fail to make use of these productivity enhancements.
* Pressing Ctrl-C/X without selecting text just cut/copy the whole line.
* Pressing double click on a line selects the word, triple click selects the whole line (or paragraph in text)
* Using Alt-Tab to switch windows
* Ctrl-Backspace deletes the whole word/token
* Ctrl+Arrow key for navigation
* Split Screen, nearly all their editors support split screen functionality, but opening multiple files in multiple panes is like crazy person talk
Even with this minor experience I have with their editors, I look like a magician using their IDE. Not to mention how slow their editor is while trying to help me by auto-completing. I was done typing the name of the class before their auto-completion kicked in. You call that slight convenience of marginal utility, but to
My point is that, productivity enhancements is a desire people have, which makes these people to move towards Vim/Emacs. For the people who don't even use Ctrl-A to select the whole text, they fail to see what they're really capable of doing on their editor.
> As I've said, I've used Vim for 15+ years (still do, a decade after every time I'm in a shell). I've known all these shortcuts, used them, etc. Haven't seen it make any great difference in that respect.
Considering you complaint about speed of navigating between files, I highly doubt that you know "all these shortcuts", because even if you do, the philosophy of vim is to keep optimizing your workflow, so you create a shortcut for shortcuts. I think it would be a cool idea to hold competitions where two people are given a codebase, and their own completely configured editor on the same machine with same processes running and then they are asked to do a number of tasks, like open UserController.js, UserView.html, UserService.js and refactor a variable and change some data.
>Considering you complaint about speed of navigating between files, I highly doubt that you know "all these shortcuts"
You can doubt it, but you'll be wrong :-) Note that I'm not speaking of navigating between already OPEN files (I know how to move between splits, maximize them, etc), but between files IN the project I'm working with. Vim just takes longer for those tasks and gives worse overview/feedback on which they are/where they are/etc, including with the relevant plugins.
>because even if you do, the philosophy of vim is to keep optimizing your workflow, so you create a shortcut for shortcuts
That might be the philosophy of Emacs, but it's hardly the "philosophy of vim". In fact most old-time vim users I know try to keep their customizations to the minimum, so they feel at home to whatever system/vim they're thrown at.
Vim makes writing and editing text faster, that's true. But writing and editing text is a small portion of the time of a programmer. Planning what to write takes up far more time. I suppose it depends on language though: I tend towards low-level (VHDL, ASM, C) and so tend to need to think things out in more detail just to get working code. But even high-level programming should have plenty of planning, otherwise it tends to become bug-ridden very quickly. Worrying about the time spent editing text is premature optimization in the vast majority of cases.
I still like vim, I just don't think that argument is very convincing.
It may differ for you but coding is (sadly) not where the majority of my time is spent. A lot of it is in data files, logs, sql scripts, etc. For a lot of those tasks fast editing makes a big difference. Sql in particular is verbose and repetative yet fairly unstructured, a vim macro is a great way to do bulk updates. Another would be something like adding a parameter to a function called in many places, the repeat command is a fantastic way to apply it everywhere.
I've touch typed for over 50 years, but I've never gotten really fast like some other software developers. However, this doesn't feel limiting, the thinking part is the limiting factor.
On the other hand, being really fluent in an editor (once upon a time in Vi, now Emacs) keeps me in a flow state. I think of code and it appears on the screen without interruption of the deep thoughts.
> in what other editors can you 'delete everything up to the next `=`
And how does being able to edit text a few seconds faster contribute to development speed and quality. Not a single bit. While it may let you feel cool, it really doesn't add anything to the bottom line.
Vim gives the ability to refactor large amounts of code rapidly. This doesn't make it so your typing speed is significantly faster, but it removes obstacles to refactoring large amounts of code which means that as a developer you will have more choices available to tackling some problems.
This can only really be shown via examples.
Let's say, a lazy person has created a 3000 line file containing the declarations of a datastructure, and you would like to modify the constructors to each have an additional shared parameter.
In order to add this parameter you could add some behaviour to the constructor definition.
With vim you have a new choice open to you: you can define a macro that to find and modify all of the constructors in your declaration file in 20 seconds.
Now you can choose how you would like the constructors to look, rather than the choice being made for you by the existing code.
There are of course other ways to bulk-update text files, but the advantage of learning vim is that it is context-free. The same commands used to modify C# are fine to use for modifying javascript or XML. (i.e. you don't have to use parsing libraries)
>Vim gives the ability to refactor large amounts of code rapidly.
It gives the ability to edit large amounts of code rapidly.
Refactoring implies design, coming with the right structure, applying some design pattern, etc -- which is the slow part, and not affected by your choice of editor.
If we're talking about "automated refactorings" (of the trivial variety, e.g. extract method, etc) then an IDE is an even better candidate than Vim.
>With vim you have a new choice open to you: you can define a macro that to find and modify all of the constructors in your declaration file in 20 seconds.
Or you know, I can do the same in any other editor with macros. Or use a regex, with almost all editors support and do it in 5 seconds.
I wrote a different reply to your post, but on replection you and I think vim is a different thing.
For me, vim is not my editor - It is a plugin that I install into all of my editors/ides (emacs, visual studio, etc.) so that the keybindings are familar and all of the normal tools (regex, macros, multiple clipboards) all work the same way.
Not sure why this got downvoted. While I prefer my own customized Emacs or Vim, Spacemacs is pretty decent from the jump. You just need to activate the layer for your language.
This is what I've been doing and I have to say its pretty great.
There's always a few things that drive you crazy of course, but helm+projectile, flymake, and such are just so damn useful over using vim's poor attempts at the same.
Dunno man, seems like I'd be missing ctrl+shift+f search across all files, with a nice little box that easily lets me filter out the .less files when I'm doing JS stuff, and vice-versa.
Obviously this is available in emacs, but not vim without serious configuring, and not with everything staying within a nice single editor context.
> Although, to be honest, using the GUI version of GNU Emacs as a Notepad replacement is possible: Just ignore the keyboard commands and interact solely via the menu up top. You even get access to at least some neat major modes this way.
Sure that's possible. And I realize that you're being hypothetical, but if that's how you're going to use Emacs, you're not going to see much gain in your productivity ;)
Well, if you're gonna train a cat to walk on a leash, the first thing you do is drape a harness on its body, to get it used to the feel and smell of the thing before it walks anywhere.
It does appear though that for on-site interviews, folks using emacs did not do well.
> Using Emacs and/or Vim is also a test of how much you care, primarily because they're not the default anymore
That's probably true, but I want to add that I used emacs/vim because I hung around with folks who looked down on other tools. So, it wasn't so much that I cared about my tools as it was about I wanted to fit in.
> Using Emacs and/or Vim is also a test of how much you care, primarily because they're not the default anymore, so anyone who uses them cares enough about their programming environment to use a non-default editor, and one which has a rather higher barrier to entry than most at that.
Depends, at the school I went to (less than five years ago), you start by learning emacs in the first month. A lot of people just stay with emacs for the remaining of the three years, because that's the first thing they learn.
Oh wow, there are schools that introduce these tools?
I know that every SE degree includes a course on practices in which they go over version control, some diff tools, etc. but I wasn't aware of a school teaching vim/emacs. May I ask which school it is that is doing this?
When I was an undergrad, we were "taught" tools like Emacs and Vim by being dropped into a systems programming class where we were told to telnet into a university server to complete the assignments, and "oh, you'll need an editor. I think Emacs and vi are there. You'll figure it out."
Berkeley 'taught' emacs in 61A when it used SICP and we programmed in Scheme, taught being in lower case here, italicized and in quotation marks. The idea that a university course would teach an editor is a bit much. I think there was a cheat sheet passed out by the TAs in section. My point is that this was at Berkeley where vi originated 40+ years ago.
(Although, to be honest, using the GUI version of GNU Emacs as a Notepad replacement is possible: Just ignore the keyboard commands and interact solely via the menu up top. You even get access to at least some neat major modes this way.
Still, Emacs isn't the default, so anyone using Emacs probably knows why, and won't be the kind of person to use it without getting more out of it.)