Vim clutch
github.com
github.com
The 1992 paper "The Prevention of Mode Errors Through Sensory Feedback" [1] uses this exact mechanism.
[1] http://research.microsoft.com/en-us/um/people/asellen/public...
I've argued for years that vim is one of the few good examples of modal design since it allows for quick entry of the command grammar without modifiers and the command grammar is an excellent fit for the domain. Whenever I bring this up with an interaction designer, I'm told there is no such thing as a good mode. The citation chain has always wound up at this paper and while I generally agree with the paper's conclusion, I'm frustrated that the editor is used in the most inspid way possible to generate mode errors (at the rate of 3-6 in 10 minutes of editing...). The problem given in the paper is solved by `:%s/\<[A-Z]\+\>\zs/errorerror/g` and I could probably do it a half dozen other ways.
Every time I read the paper I tell myself I should make/acquire a pedal and try it out but I've always been too lazy.
That said, for me as a pianist the idea of mode pedal looks pretty awesome. It just needs to be developed a bit further.
Doug Engelbart (http://en.wikipedia.org/wiki/Douglas_Engelbart) around 50 years ago:
http://www.dougengelbart.org/history/pix.html
"other experimental variations were later built and tested, including foot-pedal operated, knee-operated, even head-operated ("nose pointing") devices."
Similar ideas came up quite a few times in the recent MaKey MaKey design competition:
http://www.makeymakey.com/forums/index.php?topic=211.msg310#...
http://www.makeymakey.com/forums/index.php?topic=53.msg65#ms...
http://www.makeymakey.com/forums/index.php?topic=285.msg412#...
http://www.makeymakey.com/forums/index.php?topic=180.msg250#...
http://www.makeymakey.com/forums/index.php?topic=292.msg441#...
http://www.makeymakey.com/forums/index.php?topic=173.msg239#...
http://www.makeymakey.com/forums/index.php?topic=338.msg568#...
http://www.makeymakey.com/forums/index.php?topic=346.msg576#...
My setup has one pedal bound to Escape for Vim, and the other two switchable using F keys and some xbindkeys magic. By default, they're "switch WM workspace" (sort of like Alt-Tab) and "switch window focus within a workspace" in Awesome WM, but I can change them to e.g. j and k for reading my email, or have them run various scripts, or whatever.
It's a lot of fun to use, but I haven't been on it much lately having switched to a standing desk and I haven't yet figured out a way to make the two play together nicely. And, as always, I've been meaning to throw the scripts & dotfiles on GitHub, but I'm a slacker.
http://en.wikipedia.org/wiki/Mode_(computer_interface)#Quasi...
He never mentioned pedals though, it's a really clever approach.
If pedal-up worked, it would be neat to be inserting only while the pedal is depressed.
But however I think this is purely subjective. From an experiment perspective, this is really cool! And this generally qualifies into what could one call a 'real hack'. This has a air of freshness to it.
Now the real power of vim is in getting into a mode called 'extreme keyboarding'. I didn't realize this until I read Tom Christiansen's seminal essay "Zenclavier: Extreme Keyboarding"- http://oreilly.com/news/zenclavier_1299.html
This is to ultimately turn the keyboard into a Musical instrument, and then to become 'one with the keyboard'. Totally loosing any realization that you are actually typing. Read the essay carefully and try to understand how he tries to talk about 'moving in and out of zones'.
I started learning vim a few days back, after I suffered from Emacs Pinky. When I started question I asked was, 'Why should I memorize so many commands'. The thing is I quickly realized that being proficient with vim, requires you to understand some things. You really have to understand the vim paradigm, without that straightly diving into vim wont be much productive.
You have to learn h,j,k,l are not just navigational keys but also can be combined with multipliers like 20h(Moves 20 positions to the left). You basically speak a 'Editor programming language'. You program editor with a stream of characters. Like for example you my say 'copy this line, move up 20 positions and paste it'. This will be yy(copy current line) 20k(Move up 20 positions) p(paste it there).
So you have to basically learn these things in detail. You can use position stuff for things as well. Like for example 'd' specifies 'cut from here' and 'y' specifies 'yank/copy from here', but to where? the next character specifies that for example '$' specifies the end of a line. You can also do something like 'y2/foo' this means 'yank from here till foo'. You will have to learn regular expressions, touch typing, and many other text processing stuff. Basically you learn a terse programming language which is written as a stream of characters with data on the editor as a input.
Recently a colleague of mine introduced me to a editor command called ': perldo' you can do perl oneliner on the editor line by line.
The only thing is I couldn't find a book so far in my early days of vim, which completely teaches the 'zen of vim' completely in the paradigm, in which one needs to understand it. So vim is really about these things, I don't how far the pedal/clutch experiments gel with this concept. You may need a totally different editor paradigm to work with this setup.
In the meanwhile, if someone knows of a book that talks of vim in the way its supposed to be explained please recommend. All I could find on the net was cheat sheets, books that teach a commands in bulk.
I think the car clutch is more related to the force required to press it - it's kind of a long, slow push with lots of pressure AND control at the same time. This seems like a button, on/off-type deal - more like tapping your foot than squeezing a clutch.
Moving word wise,(w,e) is used a lot.
Next occurrence of word under cursor is useful. *,#
Learning effective macros is extremely useful.
di" is one of my favorite commands. Delete everything inside the quotes not including the quotes.
Put inoremap jj <Esc> into your .vimrc so that you can press jj quickly in insert mode instead of Esc.
Remap your arrow keys to nop and get proficient with it; this feels like I am editing super fast. A lot of editor time can be spent with your hands on home row without ever leaving.
You usually want to replace what's inside the quotes, so hence use ci"
cit is pretty nice for replacing a tag's inner html. And of course this works with parentheses - ci( - and brackets - ci[ - and curly braces and single quotes and angle brackets.. I love vim :)
I use ci{ all the time for functions and CSS. It's like magic. Whenever I'm using something like nano, I'll instinctively type what looks like a long string of gibberish: "jjjddo [oh crap] <bs><bs>..."
Once you really start getting used to the language, it makes it frustrating to use anything else.
Indeed... That is why I have been contributing to Xvim[1] for Xcode it's so nice to have vim bindings in Xcode.
Then marvel at vim-surround: cs"', cs)(, or cst<foo>, or (Shift-)v select visually S <mytag>, and argtextobj: cia and daa. Those are the two plugins that I really miss on a stock vim.
[0] https://github.com/tpope/vim-surround.git [1] https://github.com/vim-scripts/argtextobj.vim
I normally use C-c. Is there a way to make the time between j...j to be really short? Like the delay for it to count as a double press? I'd like to reduce any chance of accidental typing (although I can't see any reason I'd type "jj" a lot).
How could I forget the substitution command? <range> s/old/new/g (g == all occurrences on the line.) range can be a lot of different options. The most useful <range> options in my experience would be:
%(all lines in the file),
select something in visual mode and press :,
-x, +y for + and - x and y lines from where you are.
exact range is not that useful in my daily use.
The other thing to note about the s command is that you can use other delimiters instead of / I like to use #
% s#/some/path/to/a/file#/another/path/#g works just fine and is much more readable than % s/\/some\/path\/to\/a\/file/\/another\/path\//g
You know, I've understood this for a while, but to this day I still don't use it.
I can't count characters that fast! If you're going to lean forward and count out chars, you might as well count them out with presses of 'h'.
If you type fast, you don't want to have to spend time correcting for line estimations that are slightly off as a result of thinks like 20h. For navigation, just use forward slash to search and you'll land right where you want. It's also almost always faster to use f/F/t/T in conjunction with semicolon or comma for jumping to specific letters than using h or l. The # and * keys are also useful for jumping to words in a specific line. Failing all of /?fFtT#*, it's still going to be faster to use ^0$wWbBeE than hl unless you're one or two characters away from where you want to be. But you shouldn't even need to navigate much within lines, since text objects let you edit entire units of text, regardless of where the cursor is within those units. People who come from an emacs background (and use the default editing environment instead of evil) can't even imagine how powerful Vim is as a raw editor until they try it. I can only edit in emacs for long periods of time if I'm using evil to emulate vim's text objects.
See http://www.viemu.com/a-why-vi-vim.html if you're new to Vim
:set relativenumber
With that, my natural finger movement on the arrowkeys and on the vim home row match each other.
The reason vim's navigation keys (hjkl) today are arranged the way they are, left-means-down and right-means-up instead of up-means-up and down-means-down, is among the dumbest reasons there can be. Decades ago, the keyboard Bill Joy happened to be using when he wrote vi just happened to have arrows printed on the keycaps of the hjkl keys. He was trying to think of ways to make memorizing lots of commands easier, so he decided to take advantage of what was printed on those keycaps. There were no arrowkeys on that keyboard. That, in itself, was not a dumb choice, because it would have been a useful mnemonic on his own keyboard and he'd probably never seen an inverted-T set of arrowkeys, which didn't become popular until years later.
The dumb part is the insistence on maintaining this onion in the varnish as sacrosanct decades after that silly keyboard disappeared and in an era where every new vim user is accustomed to using the inverted-T arrowkeys found on virtually every keyboard. Anyone who, for some reason, hasn't ever used his arrowkeys picks it up immediately: up-down-left-right mean up-down-left-right. Got it.
That's why so many people who want to use vim have to be "broken" of the habit of using the arrowkeys and forced to learn an additional, weird arrowkey arrangement, because ("trust us") using the home keys is better.
Well, using the home keys is better, but not because of the awkward arrangement. That part is worse. It's better because that's where your fingers rest normally on the keyboard, from where you can operate the full set of vi commands and enjoy its full power.
You can have both. It wouldn't take much convincing to wean people off the arrowkeys if both sets of "arrow keys" on their keyboard had the same natural arrangement they've been used to for years.
I was worried when I abandoned the onion that it would handicap me on plain-vanilla installations of vi/vim until I realized that, these days, yes, there are two sets of arrowkeys on every keyboard, and I can use the real arrowkeys if I have to work on a version of vi/vim without my .vimrc, because they're arranged just like my ijkl. I can live with using the real arrowkeys for a while, and if I'm staying longer, I'll "curl -O mydomain.com/myvimrc" and restart vim with my full customizations and go back to the home row. (I also have my zsh in vi mode, and my .zshrc remaps keys the same way and can also be fetched using curl.)
I fully understand that changing this fundamental arrangement is NOT attractive to experienced vim users, because muscle memory has long since automatized the arrangement. The old fogey's vociferously defend the old onions for various, mostly self-serving, reasons.
(They tell me, for example, that this will make it impossible to use a vim on a different machine on the same page where they brag about their extensive and brilliant .vimrc customizations that they "couldn't live without." Hmm.)
But I'm starting to teach my kids to use terminals, command lines, and editors, and I didn't want to pass this onion on to their generation. I remapped the keys and retaught myself to make it easier for them. Now we can share the same .vimrc and .zshrc. They'll have one, consistent set of muscle habits for arrowkey motion from the start, whether playing games, editing text, or on the zsh command line.
* First and foremost: If you rely on hjkl, you are doing it wrong anyway. You should be using f, w, ), :n (for integer n), ^d, ^f, etc. My biggest hjkl use case is using j to idly scroll through a file (or less/more/man page), in which case it's conveniently under my index finger and I love it. I also use l for off-by-one errors.
* Secondly...especially now that it's ingrained, all of the other keys "make sense" (sort of), and there's no excellent alternative. With your setup, "Why is h insert? Wouldn't i make more sense? Gosh, vim is hard to use." Etc. etc.
1. Ctrl-H is Backspace, one of the most used keys, and much more conveniently placed than, er, Backspace. It's right next to the index finger. It's intuitive (in vim) because H is "go left". Ctrl-H works everywhere, in the shell, in OS/X all over the place, it even works in the Windows shell. It's some sort of fundamental mapping to Backspace such that can't actually be re-mapped.
2. Ctrl-M is Enter, another one of the most used keys, and also more conveniently placed than Enter. As with Ctrl-H, it fits under index finger, it's an ancient mapping, underrated, works in lots of places, even in Windows shell.
If you use the crappy arrow keys, your fingers are totally in the wrong place!
Yet you "don't get" why that might be a problem for people? Really? If it is what you claim, "the single biggest roadblock," then there is something important here, whether you get it or not.
You argue that if you rely on these awkward arrowkeys, "you're doing it wrong anyway." Does that mean they don't really matter? If not, then the using the most prime of the keyboard real estate for operations that "real programmers" don't have much use for would be an even worse design than I'm claiming. If they are important enough to dominate your right hand home row, and I think they are, then your argument is meaningless and they ought to be rearranged so that this no longer "the single biggest roadblock."
And this second reason is silly. Training your finger to reflexively move left instead of up to insert text to the left is going to be a challenge of the same magnitude as relearning arrowkey movement? You think so? People who have been using "copy" for years have to learn that copy in vim is called "yank" and the t,T commands mean, well, "till", and you have all sorts of ctrl-* and meta-* commands to somehow learn, but having to learn to use h instead of i would be such a hurdle that it's really a show stopper for fixing the arrowkeys? That's really your second strongest argument?
These aren't real arguments. Long-time vim users argue that one of the glories of vim is its marvelous customization, but if you customize the basic movement keys, it's supposedly a horror because, well, you then won't be able to use a non-customized vim. So, what's the customization for? It's for secondary things, not something so fundamental. Then you're told by someone else that, besides, if you are using the movement keys much, you're not using vim correctly. Which sounds like a claim that the movement keys just aren't fundamental. And if they're not, what's the problem with customizing them.... What a bunch of nonsense.
It's all a smokescreen for maintaining backward compatibility with a poor design that has spread, mostly in the heads of old programmers (the ultimate "legacy systems"), but also into some software. But for those willing to admit that backward compatibility is the only real argument, think of how much MORE legacy there is these days for the real arrowkeys in the minds of non-vim users and in software of all sorts.
I think vim should change its defaults. It probably would if it were a commercial product, but that won't happen, because defaults in vi/vim are by and for long-time users, not potential users. But it is, as claimed, customizable, and so are most systems (like zsh) that have a significant vi-mode. Systems that don't have a serious vi mode but just toss in a couple of shortcut keys, like j&k, can be learned ad hoc, the way we have to learn all the other shortcut keys that have different meanings in every program.
So, I'm customizing vim & zsh, using the real (physical) arrowkeys occasionally if connecting to a plain-vanilla vim/bash, and it's working out just fine.
Thanks to the relative line numbers patch being merged in finally (:set rnu and now you show line numbers relative to your cursor) you get easy moving up and down.
I prefer the easymotion plugin (https://github.com/Lokaltog/vim-easymotion/) that annotates your file with little markers (like the vimperator/pentadactyl/vimium browser plugins use to click links with the keyboard) that allow you to jump around extraordinarily quickly.
It was, and still is, a learning curve since it adds to so many basic vim commands that are muscle memory for me by now but it's worth it.
I also recommend the O'Reilly "Learning the vi and vim editors" book, http://shop.oreilly.com/product/9780596529833.do and my own course on vi basics, http://www.verticalsysadmin.com/vi.htm
remove lock = Caps_Lock
remove Control = Control_L
keysym Caps_Lock = Control_L
add lock = Caps_Lock
add Control = Control_LWonderful articulation of what we're losing with the fashion moving towards low learning curve, expert-proof designs.
Now I can send that link to people instead of trying to articulate the same idea in my own words.
It looks a bit untidy, but it's a very quick read because it's a low-density chat log.
slkjs/sdfjks/\1jksok/j23kjdj\skjd
is the same as
lkkd\kk////?!@
except latter is shorter and easier to understand
This can be used to easily control the keyboard: http://www.pjrc.com/teensy/td_keyboard.html
However, maybe these car style pedals would be more ergonomically suited than the little metal studs of guitar pedals, which are designed to be aggressively stamped on.
Thoughts?
imap kj <esc>
Picture : https://plus.google.com/118040095502884745897/posts/FwN5FEfN...
Source : https://github.com/suapapa/arduino_sketch_balcon123
I'm pretty happy by having my caps lock key mapped to escape, though.
Works here (misusing the F8 key) [2].
---
Sadly, I don't think it will be trivial to implement.
I only use i part of the time, however; I, a, A, o, and O are each used substantially.
The one I do have a massive problem with is capslock. So many times I'll go back to normal mode and there's a few moments of disorientation before I realise all my commands are being capitalised. Ugh.
OTOH I have heard Emacs users need Ctrl/Alt constantly while editing.
Actually, on the laptop I'm on, I have Caps Lock mapped to backspace - vanilla unedited colemak layout. On my desktop, I have Caps Lock remapped to LCtrl and LCrtrl mapped to backspace.
Ctrl+u,d for page up and down.
Ctrl+e,y for shifting the screen up and down.
Ctrl+],t for moving in and out of tags (with ctags).
Ctrl+v for visual block mode.
Ctrl+[ instead of escape.
Ctrl+p,n for autocomplete.
Ctrl+r for redo.
Ctrl+o,i navigate location jump history.
...and probably more that I don't know about.
Additionally:
I have Ctrl+h,l mapped for tab switching.
Terminal multiplexers like tmux and screen use Ctrl for switching terminal sessions.
You said you were on a mac so:
System Preferences -> Keyboard -> Modifier Keys
Another idea: repurposing a midi faderbank that supports automation (servos) to display data from snmp/statsd/graphite.
I was inspired because my midi keyboard has a pedal switch input...
Suppose he comes up with a better way to build the device. It would be good practice to have all versions available, something that isn't as easy to do with a website. Additionally, his target audience is people who use vim, which probably has a reasonably large overlap with git/GitHub users.
A clutch can be used for mod switching; such as running mode, stealth mode or reloading guns.
[^] Nintendo is a holdout here, though the WiiU apparently has the buttons.
This is the latter.
vi and vim are holdbacks from the days of 300 to 9600 BAUD modems. A time when more sophisticated interfaces were prohibitive. Back in those days it wasn't too uncommon for people to actually write their own text editors. I wrote a few, mainly in Forth, as I would bring-up self-designed systems.
While I use VIM today when I have to I continue to think that in today's context these things are, well, ridiculous. There is no reason that the terminal can't switch modes on you and allow text editing with the same (or very similar) UI that traditional simple GUI editors provide.
The damn text box I am using in this browser to enter this comment is far more user-friendly than VIM. There is no reason for a modern terminal to continue to support something like VIM.
Put another way, I had editors running on 6502-based 2MHz clock (yes, 2 MEGA Hertz, not Giga) Forth machines that were far more user friendly than VIM or VI. We ought to have better tools today. In my opinion, there is no compelling reason to continue to promote something like VIM. Put a bullet in it already.
As for the hack. Lots of fun. But, geez, how fucked-up is an text editor that you have to come-up with a foot-switch to make it more usable?
To the average user, sure; the text box is more friendly.
But that's not the point with vim. At all. Vim's design goals are speed and efficiency. To date, non-modal editors haven't come anywhere near vim in that regard.
As to "user friendly" - depends on who the user is. Yes, this text box is infinitely more user friendly than vim when your mom is using it.
That a foot-pedal might make vim more usable has nothing to do with vim being outdated or unusable. Is your operating system broken / outdated because one might find a food pedal driving "alt-tab" more usable or fun?
Why is an answer from sofal not acceptable?
Numbers. Not statements or links to the manual. I care about data. Show me a project that got done sooner and better because of the use of vi/vim and you'll have a point. I propose that not one person can make that claim and that the popularity of vi/vim are purely tribal.
There's an interesting show on TV called "Head Games" (http://news.discovery.com/human/new-tv-show-plays-head-games...).
In this show they demonstrate, among other things, how tribal behavior can be taken to an extreme. It is very hard for some to go against group behavior. They show one example of a guy in a room that stands up when everyone else stands up and he doesn't even know why.
To some extent I believe that some of these tools are like that. You work in a shop where the hot programmer swears by vi/vim and you adopt that without challenging any of it. Very soon everyone is playing the same tune, facts be damned. I happen to be one of those people that does not engage in crowd behavior. This can be a blessing and a curse. I never bothered to spend months on vi/vim because every time I used for days or weeks (out of not having other choices) I came out of it with the distinct idea that the whole thing was just short of lunacy. In the context of the project that needed to be completed these tools offered no real advantages. You are not going to impact the bottom line in any measurable way.
Put another way: If you took two kids that knew nothing whatsoever about computers or programming and set out to teach them. One is taught with modern mostly-GUI tools with "conventional" keyboard shortcuts while the other has to use command line and vi/vim. Both of them have to complete the same project. The vi kid would be absolutely smoked by the other kid in no time at all. No question about it.
OK, how about a second project. Maybe not smoked, but no significant gains would exist out of the vi camp. Programming is far more about things that have nothing to do with text editing. Projects are not late or buggy because of good or bad text editing tools.
I'd still like to see someone quantify the gains offered by vi/vim over the course of a project.
Regardless, see this: http://news.ycombinator.com/item?id=4144499
Furthermore, "the other has to use command line and vi/vim. " seems to be confused. Using vi style editing does not really have anything to do with the command line (though it frequently does, that is out of choice, not necessity).
http://news.ycombinator.com/item?id=4145060
I hope you will be one of the first to post to that thread.
Thanks in advance.
http://www.helis.com/h/h53ecab.jpg
We're talking about a general-purpose text editing tool used by experts for hours, days, and years on end. I understand that you like to click through your menus, but you'll have to excuse those of us who know what we're doing in vim and don't have the time or patience for that.
And, yes, funny enough, it just so happens that I would find the cockpit of a military helicopter very user friendly.
Now you resort to calling me a troll?
That's nice.
There's nothing unfriendly about a helicopter cockpit. Even if you've only played with flight simulators anyone half-way intelligent can probably figure out most of it within a few minutes. Flying one is a different deal, as mastering and understanding the complex relations between collective pitch, power, torques and aerodynamics. As a simple example, it isn't immediately obvious that flying in ground effect is different from flying above ground effect. Or the interaction between collective pitch, the tail rotor and the demand for power. This is quite different from understanding what the knobs and dials in the cockpit might do.
All of this from simply expressing a contrarian opinion on VIM.
HN does have an unfortunate trait: If you say anything contrary to "tribal" beliefs you get pounded and sometimes brutally downvoted. That does not mean that the tribal belief is right, it just means that there are enough tribe members to bully others into either not participating or simply adopting the tribal memes and falling into compliance. Well, that's not me. If I believe that someone is bullshit you are going to hear it.
Why do I believe that some of the hyper-keyboard-efficiency claims of VIM are bullshit? Because programming is not factory work.
If a programmer is spending so much time at the keyboard that counting keystrokes becomes important they are not doing a good job. I spend far less time programming than I do planning and deciding how to solve the problem. I don't just sit down and start hacking away without direction. By the time I actually fire-up a text editor or IDE to program I have state diagrams, database structures and algorithms pretty much selected and reasonably-well thought out. If I've done such a shitty job at the pre-programming work that my text editor's keystroke count actually matters, well, I'm a hack, not a programmer.
Some of the admittedly interesting things you can do with VI (http://stackoverflow.com/questions/1218390/what-is-your-most...) are, in my opinion, somewhat of a corner case. These are things that one might not do with great frequency. The fact that you can do them is interesting, but that isn't going to be a deal breaker if you only have to do them once every few weeks or months.
In some respects I can derive far greater efficiencies from using a tool such as Excel to sometimes cut hours of coding and formatting by using it intelligently to help generate code that is more maintainable.
One such example is to use it to generate state machine lookup table code that can be copied and pasted into a text editor instantly. I've done state machines with hundreds of states this way. If you do it right they are easy to maintaing and update. No text editor can improve on this level of efficiency.
Another very similar example is to use Excel to help generate JSON files from various tables and data. Easy to setup, maintain and modify. A simple copy and paste into an editor.
When justified, I have taken the time to create more complex tools that automatically generate complex code based on database inputs. One example that comes to mind was a tool to automatically generate all of the code to manage a menu system on an embedded device consisting of an LCD display and a few buttons. Every time the menu structure or content was changed it took days to update the menu processor code. The tool took a month to create. Once in place, almost anyone could generate the code for an arbitrarily complex menu system within minutes. No degree of text editor efficiency can solve these problems.
The point here is that, if I have to resort to counting keystrokes as a measure of programming efficiency then I have either reduced programming to factory work or I am so disorganized that I am spending a disproportionate amount of time typing crap that will have to be fixed many times over before it actually works.
To beat the state machine example to death. In my case it is very rare that I have any bugs when I code state machines, even complex ones. Granted, I've been doing it for a while in both hardware (FPGA's, Verilog) and software applications. Regardless of that fact, this is because I do all of the thinking and planning ahead of firing-up the editor. The resulting code, generally speaking, works on first run.
I've you've ever programmed a CNC machine manually (G-code) you understand this concept. You don't just stand there start hacking away. You take the time to plan it, do all the math, choose tools and verify the approach before you enter the code. If you don't, you'll learn the hard way. These machines are dangerous. I once made a programming error and had my Haas VF3-SS churn aluminum with a 3/4 inch roughing bit like it was butter. Amazing what something with that much power can do. I kept the fucked-up end-mill as a reminder of what not to do.
A professor of mine, who introduced me to APL, took every opportunity to drive a point home. He said that data representation is one of the most important tasks in solving a problem. If you represent the problem using a flawed model it can take ten times longer to create a solution. He pounded that into us to the point that it became instinct. That's why I will never touch a text editor unless I know where I am going. That's my context.
I also caution you and others when considering yourselves "experts" in any field. I learned a long time ago to never utter that word. One can be highly skilled in one particularly narrow area while being completely ignorant of other ideas. I certainly am. I am not just talking programming here. Having access to a larger context is sometimes very important. What makes sense in a myopic context might not make much sense when one is able to pull back to a different plane that covers other schools of thought. Be open minded.
Now, if it makes all of you really happy, down-vote away. It's always fun to watch the tribe in action.
If you are doing embedded work that involves systems that could cause harm to people or property it is far more important that a programmer understand how to write safe code and take the time to make sure it is safe than to optimize editing speed.
Nothing I have seen in my career justifies contorting ones' brain to learn the commands of a modem-era text editor. It's an utter waste of time when compared to optimizing what really matters.
Your last paragraph suggests that learning an editor like vim takes up enough time that it detracts from learning important software engineering principles. I'd like to suggest that learning vim, though scary at first, is not nearly as bad as all that. You pick up more and more of it as you go, and the accumulated bits of time saved over a long period more than make up for the time you spent getting over the learning curve.
"Modem-era"? I assume you don't use any "modem-era" command line interfaces, programming languages, APIs, protocols, or operating systems.
As a side note, the foot pedals are a hilarious idea, but they will in no way improve productivity in vim. Just mentioning it because of your "my editor doesn't need a foot pedal" comments.
If you don't feel the same, then whatever; nobody is trying to force vi style editing on you. I don't see what your issue here is, why is it that you seem so intent on discrediting the experiences of others?
I think you are reading far too much into what I've commented. Nobody is doing that at all.
jlgreco: vi/vim is an efficient text editor when you learn it! And even more efficient with a foot pedal! Don't discredit our time spent learning vi/vim when it is in fact an efficient text editor!
robomartin: vi/vim may be an efficient text editor, but in the grand scheme of a large(non-trivial) project, small improvements to text editing efficiency are irrelevant. Particularly at the sake or cost of learning and mastering vi/vim. There are easier-to-learn and more-intuitive text editors available now.
Both valid points.
Is that observation on topic or even insightful? No.
Of course what makes this frustrating is that he does not even acknowledge that he is making a different point than other people.
Often people who have been downvoted assume that it's just because they've voiced a contrarian opinion, when in reality it's because they've made strong statements with no justification. Then they pretend like they don't care by accusing everyone else of hivemind mentality and proclaiming how much they don't care.
Now onto your argument. You say "programming is not factory work" and go on to say in many words that editing text is not the most important bottleneck in the way of programming efficiency. What surprises me here is that you think that this would somehow invalidate the use of an efficient text editor.
Nobody here is going to disagree with you that the thinking and the designing take more time than the actual typing of those ideas and designs into code. That's not the point. We're not suggesting that vim is solving your thinking problems, and just because vim makes text-editing faster doesn't mean that vim users naturally gravitate towards hacking out solutions without thinking. Nobody is counting keystrokes to measure their entire programming efficiency.
Vim is used for text-editing. Text-editing speed is not the core bottleneck for programming efficiency. You've stated this, but this fact does not at all justify your assertions that vim is a bad tool. Your response above is an attempt to minimize the act of text-editing, as if text-editing itself, rather than vim, is passé and unsophisticated. That is ridiculous. Programmers edit text files all the time, regardless of how smart and awesome their code generation tools are. Those tools don't reduce or obviate the need to edit text, they just provide better leverage; they increase the ratio of work done to the amount of text-editing.
As for down-voting on HN. There's plenty of evidence that it is badly broken. It's funny to watch the Apple fan-boys down-vote on emotion when you even peripherally chafe their idols. The emotion is evident from the fact that substantive posts are down-voted when nothing is materially wrong or offensive about them.
Most of it is also what I call chicken-shit down-voting. No explanation and no reason given. You are accusing me for voicing a contrarian opinion without sufficient explanation. What about down-voting without any explanation whatsoever? I have only down-voted a post once and I went out of my way to explain why I did so. I believe I owe this much to someone if I am going to exercise that right. And so, that is my policy: If I down-vote I have to take the time to explain why. Otherwise I don't do it.
It is clear that the HN culture --at least the one exhibited on this thread-- is that vi/vim are fantastic. So be it. I don't have time to screw around with this topic any more and fend off fan-boy attacks. I suspect the same is true of your case.
I have used a myriad of tools over the years. The only use I have for vi/vim is when I have no choice but to use them. I remember when keyboards didn't even have function keys. In those days these kinds of tools made sense. Today? No. Not any more. You don't have to see it my way. And that's OK.
> they increase the ratio of work done to the amount of text-editing
I would challenge you to quantify that in the context of a real project, concept to completion. I would be willing to wager that vi/vim don't contribute one iota towards the completion of the project.
I have yet to do a project where anyone even remotely said: Wow, that text editor saved us hours of work.
That aspect of the adoration of vi/vim is what I see as ridiculous. I simply don't think that any of it is materially significant to the timeline of any non-trivial project.
Then again, I really don't care to continue on this thread because it truly is a waste of time for all involved. So we are done.
Conclusions:
1- No contrarian opinion of vi/vim will be tolerated by HN vi/vim users.
2- vi/vim are fantastic.
3- Anyone even remotely thinking of suggesting otherwise just doesn't get it.
I can live with that. No problem.
You win. Done.
Then somebody suggests that you are acting trollish, and to you that is simply uncalled for.
Really?
You think he has a valid argument, cwills? Maybe you can point out to me where he has actually responded to my points.
http://news.ycombinator.com/item?id=4145060
It should be obvious that it is intended to be useful and educational. No flaming. No trolling. No personal attacks. Just reproducible facts.
I am hoping that you will be one of the first people to post a recipe to that thread so that those of us who don't know enough about vi will, hopefully, see the light.
Thanks in advance.
Either you're a terrible Vim user or you have a pretty awesome browser text box. I had to install a third party browser extension just to make the damn thing resizeable - woe is me if I want to do search/replace, indent anything, or do anything but the most trivial undo/redo operation. And who hasn't permanently lost stuff they've written into a form by hitting the wrong key?
Yes, I am a terrible VIM user. I have far more important things to do than to get good at using modem-age text editors. My efficiency comes from planning, not counting keystrokes.
As if the two are mutually exclusive...
As an optimization problem, text editing is the wrong aspect of creating a software product to focus on.
Software projects are notorious for being way behind schedule. If the estimate is weeks, it might take months. If it is months, it might take a year or more. In that context, arguing that a text editor will make everyone more efficient is just silly. Get my damn project done on time BECAUSE you are using vi/vim and then I'll drink the cool-aid. Until that happens I will continue to believe that the use of vi/vim is just tribal behavior rather than these tools offering any real business value in the context of a project's timeline, maintainability, quality of code and bug density.
If you can point to a single project that was done on time and without bugs because it was edited on vi/vim then you have a point. I suspect that this is not the case.
They are important to programmers.
You are arguing against a strawman that I suspect you do not even realize you have constructed.
<start quote> Back in 1999, the mag asked Joy what inspired him to write vi:
What happened is that Ken Thompson came to Berkeley and brought this broken Pascal system, and we got this summer job to fix it. While we were fixing it, we got frustrated with the editor we were using which was named ed. ed is certainly frustrating.
We got this code from a guy named George Coulouris at University College in London* called em - Editor for Mortals - since only immortals could use ed to do anything. By the way, before that summer, we could only type in uppercase. That summer we got lowercase ROMs for our terminals. It was really exciting to finally use lowercase.
So we modified em and created en. I don't know if there was an eo or an ep but finally there was ex. [laughter] I remember en but I don't know how it got to ex. So I had a terminal at home and a 300 baud modem so the cursor could move around and I just stayed up all night for a few months and wrote vi.
Linux Mag then asked: "So you didn't really write vi in one weekend like everybody says?"
No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.
9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore. <end quote>
This is from Bill Joy, who wrote vi. The last line is very much on point and mirrors my point of view: "Now that computers are so much faster than you can think, nobody understands this anymore."
Also: "I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem."
If one was given the task to write a text editor today, even one without a GUI, I would be surprised if anyone reached for some of the things Bill had to do in the context of 300 baud modems and a terminal (not window, but physical).
In the context of large projects vi/vim don't offer any real measurable gains. The fact that programmers who take the time to learn these tools feel good about them does not constitute proof of anything other than that fact.
Let's just agree to disagree and move on.
I do not suggest that editing efficiency has a measurable impact on business efficiency, and I do not see anyone here suggesting that it does.
You seem to be under the impression that when people talk about editing efficiency that they are meaning to imply business efficiency. This is what I was saying when I said you have constructed a straw man.
Imagine a conversation like this:
PROGRAMER: "Hey, boss, on Monday we want to switch to
vi/m because everyone says it is more efficient".
MGR: "Do you have any data to support that? Will the
project get done on-time, on-budget, faster, better
and with less bugs?"
PROGRAMMER: "Well, I can't guarantee any of that and
can't offer quantifiable data, but programmers who know
it swear by it and talk about how much more efficient
it is."
MGR: "It only makes sense to me if you can prove and
guarantee that switching from our current text editor
to vi/m will result in true and measurable productivity
and quality gains. Otherwise there's nothing in what
you are saying that justifies changing over."
Boy, does one have to have a thick skin to voice contrasting opinion on HN sometimes.
In the interest of being constructive I decided to clear the bad blood and start another thread that is designed to educate us who might not understand why some are so passionate about vi. Here it is:
http://news.ycombinator.com/item?id=4145060
If those who post to this new thread stay within the proposed framework what will come out of it is a set of recipes that show (and support) the claims about vi efficiency. I hope you will be one of the first to join that thread and offer a few examples. There are many who know absolutely nothing about vi. Some have avoided it like the plague. And then, those like me, who only use it when absolutely forced to. This is an opportunity to educate all of us. Thanks in advance. I think it is safe to say that this thread is over (save those who want to talk about the foot-pedal).
I use vim sometimes locally, but almost exclusively remotely, because the context I'm in at the time precludes using 'real text editors' - GUI apps that get installed and have menus and such. If I have to deal with files on a remote box (example: to edit config files), pulling them down to edit in notepad is highly inefficient. Vim is far more efficient - my own data over the last 15 years proves that to me, and generally to other people who watch me, and I say that as someone who really disliked ssh/vim processes - I preferred to pull down files via FTP, edit, save, then FTP up. But efficiency won over after experimentation.
But that's just one context. I use intellij, phpstorm, zend studio and visual studio for different types of editing, and those editors provide a wealth of other tools that make my editing far more efficient in those contexts (development, debugging, creation, testing, etc).
So "vim efficiency data"... likely never to happen, but "eclipse efficiency data" or "emacs efficiency data" won't happen either.
I too have had to administer and support remote systems where vi was the only viable way to edit config files and the like. And, much like you, if I could, I would go for bringing the files into my local system for editing with a non-vi editor (a secondary reason being that if I screwed something up by accident I wouldn't take down a system).
In over twenty years of programming my intersection with being forced to use vi was never frequent enough to warrant spending the time to get good at it. None of my work suffered for it, of course. In my current business nobody uses vi and we get quality work out the door like anyone else. And, I should say, without the need for foot-switches :) --had to throw that in for a little dose of levity.
Thanks.
If you are a manager, its worth your time to study tools that help you manage things better. If the best managers in the trade say a particular tool 'x' helps them be productive, then its worth your time to learn that tool. Can you justify minor leaks in productivity while you are learning it day to day. May be no on the shorter run, but the productivity gains over time are going to be so drastically huge its going to be totally worth your time.
If this manager goes to his senior manager and explains all this, I believe the senior manager would understand this. Else these so-called managers are not managers. But glorified desk-supervisors, whose only job is pushing buttons on the blackberry.
If you are saying that, in your own business you make decisions that would bring your entire team to almost an absolute without solid business or product quality justification. Well, more power to you. Live long and prosper.
Software projects are late on schedule for reasons nothing to do with typing speed. Learning text editing is only important for you to make comfortable while you are doing other important tasks.
In other worlds like Java, Intellisense and auto-complete rule the world. You can't do any work sanely without those two things. In fact not knowing them might cause a delay in delivering projects. Using them only brings you on plane with other Java developers. Its a need not an advantage.
Emphasis added.
Vim when you're using it with 3-5 buffers, some specialized, on screen with lots of plugins feels just like an ide or something like Sublime Text 2
Vim keybindings in Sublime Text 2 or Visual studio/outlook/word via ViEmu is pretty good in my experience.
Now vim has everything I need for coding html/css. To me vim just makes everything better from my experience, it made me more efficient, more faster at coding. Visual Studio with vim key bindings made me love the VS IDE as well haha.
https://bitbucket.org/cheater/us_split.
It's just like us qwerty, just more ergonomic.
Could a neck collar or head band be developed to perform similar tasks? Eg you move your head left or right to navigate web sites.
Definitely a neat hacky idea (so by its nature, me gusta), but VIM is a silly, silly editor for real world purposes.
Why do you think that? Vim is perfectly fine for real world purposes - I use it for real world purposes all the time, as do a lot of other people.
Not only do the basic vi commands make my life easier (My mantra is if I have to press the same key more than three times, then I'm doing it wrong - you quickly learn to navigate by words, brackets, lines, search and judge how many of these away you want to move - eg instead of wwwww to move forward five words you can do 5w, to turn "abcde_" into "_abcdeabcdeabcde" you can do 5x3p - silly examples I know, but this makes it very fast an efficient to navigate and edit text), but with vims additional features and with a small handful of plugins there is nothing that a GUI IDE can do that vim can't.