Good videos, with context.
7 Habits For Effective Text Editing 2.0

7 Habits For Effective Text Editing 2.0

GoogleTalksArchive
5 HN recommenders · discussed 2013–2023
Open YouTube ↗

About this video

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.

Why it appears in the archive

HN recommends it as a lasting philosophy for improving your editing process incrementally, and it was widely remembered after Moolenaar's death.

AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.

From the Hacker News discussion

Monkeyget · 2014-07 · strong rec

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] [VIDEO]

Read original comment ↗
tzhenghao · 2023-08 · strong rec

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] - [VIDEO]

Read original comment ↗
1-2-3-5-8 · 2023-08 · strong rec

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: [VIDEO]

Read original comment ↗
adem · 2014-04 · rec

The only thing you need to read about Vim to get started is here: [LINK] , the rest is learned pretty much by the following principle: 1. Detect inefficiency for a particular task 2. Find a faster way to do it 3. Make it a habit You can learn more about this approach in this video: [VIDEO]

Read original comment ↗
e12e · 2015-08 · rec

Reminds me of Mjoolnar's (author of vim) talk on 7 habits of effective editing 2.0; the core idea is essentially (my current interpretation): awareness: look for repetition - they are candidates for automation and/or being more effective. Rule of three: If you do something (anything) 3 times - figure out if it can be done more efficiently. In vim (or any other editor) an example might be shifting the indendation of code: maybe you only remember how to do it a line at a time; figure out how to work on blocks of code; figure out how to do it on a file - a whole project. [VIDEO]

Read original comment ↗
e12e · 2016-04 · rec

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

Read original comment ↗
e12e · 2016-05 · rec

> 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": [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

Read original comment ↗
oelmekki · 2013-03 · reference

In the next article : "Buy a lot of software and don't learn programming. It's hard, and after four years, I still can't write anything someone else didn't do better !" Not only I can confirm that after 7 years of vim, I feel really more productive than when I use any "intuitive" editor, but now I've remap all my window management (either X or tmux) to similar mapping. One point I can agree, though : vimscript is a real pain in the ass, which defeats what Bram Moolenaar say should be our process - detect repetition and automatize it seamlessly. [1] It will only be empowered when we'll have a full featured language to do so. [1] [VIDEO]

Read original comment ↗