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
(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.
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.
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.
"stereotyping" is a floating signifier, and arguably in common usage doesn't merely signify hasty generalization.
Love all lisps, including elisp.
(use-package unfill
:ensure t
:defer t
:commands (unfill-region unfill-paragraph unfill-toggle)
:bind ("M-q" . unfill-toggle))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.
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).
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.
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.
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)
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.
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.
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 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.
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.
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.
As I said, there are fast plugins for that task and slow plugins. Command-T and Ctrl-P are megafast because they are run as native binaries.
> 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 still like vim, I just don't think that argument is very convincing.
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.
Obviously this is available in emacs, but not vim without serious configuring, and not with everything staying within a nice single editor context.