GoogleTalksArchive
5 HN recommenders · recommended in 8 months, 2013–2023
1:20:30 · 126K views · Aug 22, 2012
Vim creator Bram Moolenaar's 2007 Google Tech Talk on habits for efficient text editing. He explains how to spot repetition and inefficiency, then use editor features to fix it.
HN recommends it as a lasting philosophy for improving your editing process incrementally, and it was widely remembered after Moolenaar's death.
9 comments from Hacker News
It takes a year because you learn it over time. Learning a tool progressively is the best way to go. There is a wonderful presentation called '7 Habits For Effective Text Editing 2.0' [1] explaining this philosophy. The idea is to get the basics down upfront and then get more proficient gradually over time. When you use the tool you stay aware of what you are doing. When you find an inefficiency in the way you use the tool, find a quicker way and make it an habit. This is the most efficient. If you only care about the code you have to type right now and never read the editor's documentation nor learn new commands you'll keep using only basics commands and never will gain proficiency. Not efficient. If on the other hand you try to learn every feature immediately you'll waste time learning things you won't use and forget most of them anyway. Not efficient. [1] this video
Thank you Bram for everything. Your talk, 7 Habits For Effective Text Editing 2.0 inspired me and it started my Vim journey. Using Vim all these years has been a complete joy. You will not be forgotten. Link to the talk: this video
Loved his "7 Habits For Effective Text Editing 2.0" (2007) talk and humor [1] "How many of you are mostly using Emacs?" a bunch of raised hands "Okay, we'll try to convert some people today!" RIP, Bram Moolenaar [1] - this video
> indexes everything So should your text editor (and/or it's companion programs) > and provides superior auto-completion. See above. Superior is a bold claim, superior out of the box for "strongly" supported languages, perhaps? (Eg: one way of working with java in vim is to use eclipse for extracting some information about a project[1]) Personally I'm more familiar with vim, than with Emacs -- arguably the main difference is that Emacs has one standard and sane scripting language (lisp), while vim doesn't (I'm very happy a lot of masochists work tirelessly to provide vim plugins for everything I need (and a great deal I don't) -- but I think it's hard to argue that vimscript is a "good" language. And having other bindings (eg: ruby, python) is a bit of a mixed blessing)). But what they have in common, is a strong focus on making it easy to automate transformation of text. Any kind of text. With any kind of automation, via commands. As such they empower a continued process of improving the process of writing and editing. I like Moolenaar's (vim's creator) short text and expanded talk on 7 habits of effective text editing: "7 Habits For Effective Text Editing 2.0": this video "Seven habits of effective text editing": [LINK] I often feel that modern IDEs with typical "modern" languages, tend to trap you in a certain way of working that is "with" the IDE, that tend to be counter-productive if that "one true (editing) process" doesn't fit. And they tend to provide only something like
Personally, I find vim's modal editing to be very efficient. When starting from a clean slate, it doesn't really matter much -- but when changing/ editing existing text/code, I find it feels much more natural. It also works well without using the mouse, which is important to me because of carpal tunnel syndrome (and also helps when working without a proper mouse, such as on laptops). I've only toyed with emacs, but based on that, I don't think emacs' idea of keyboard "chords" is as good a fit as vi(m). With standard keybindings, it also puts a strain on my wrists. Modal editing and the "edit language"[1] (verbs, nouns, modifiers (and motions), like dw=delete word, dd/dl=delete line, d$=delete from cursor to end-of-line, dG (delete to endo-of-file, where gg/G is motion for moving to top/bottom of file respectively), ciw()<ESC>P=change inner word (cut word under cursor to buffer), add "()", escape out of insert mode, paste word between "()"). These look cryptic, but quickly starts to feel quite natural and intuitive. My impression is that Emacs' Evil-mode has evolved quite a lot lately, and allows one to combine the best of both: a much better programming language (scheme dialect) for customization, with modal editing and vi(m) key bindings. But I've yet to play with it. If you don't mind using the mouse, you might also want to look at ACME[2] - it's a bit more exotic, and unfortunately hasn't gotten as much support as VIM/Emacs. The creator of Vim, Mjolnar, has a great video o