Unfortunately for those seeking pimps or the services of their employees, this is sadly about editors. Seriously.
Almost everything you do on a computer that is done via either the keyboard or the mouse. One of these things (protip: the mouse) is notoriously slow and error prone for some users. I know some of you can't imagine not being able to use the mouse as a veritable extension of your hand, but try to write in your sunday best handwriting using a mouse, or better yet, try using your non-dominant hand, and then you'll know how grandma might feel using the mouse.
The other one of these, the keyboard, is an instrument that were it not for it's age and ubiquity would have probably been replaced by some simplistic user interface by Apple Computer years ago. People's keyboarding speed varies dramatically, and just like playing Guitar, no amount of practice is going to make you any better if that practice is done incorrectly: I've been playing guitar for like 10 years and I still suck, my father has been typing for like 10 years and he really still sucks.
But if you are like me (or you were born after about 1987), you probably use both of these instruments very well. Congratulations, stories of your proficiency on the keyboard and mouse might very well be colorful stories for your grandchildren analogous to walking to school barefoot in the snow.
So where was I. Using the keyboard, most of the time you're typing. Your typing speed is going to be about what it is; most adults have probably been using computers for a while now, and they've probably settled into as fast as their fingers & muscle memory will allow them to. But just because you type at a certain speed doesn't mean you are necessarily limited by that speed when it comes to editing text. That's what this is about.
When you want to delete a word, do you highlight it and press backspace? Do you hit the backspace [number-of-letters] times? Do you hold the ctrl key and hit backspace? When you want to go to the beginning of a line, do you click there? Do you hit left until the cursor moves there, or do you use the home key? These are built-in keys or near-ubiquitous shortcuts for common editing tasks. They are listed in worst-to-best order, the criteria for 'goodness' being speed and the amount you need to think about them (lower is better). These editing shortcuts work well because words & lines are common primatives to all sorts of text editing, and their effects are easily visualizable without any counting. But what if there were other common primitives?
My grandparents generation took courses in writing shorthand. Learning shorthand is essentially learning how to shortcut common note-taking primitives such that you can "write" at incredible speeds. Remember, writing is merely describing tasks that you want to be recallable later via reading. If you develop a system to write in sounds (as many shorthand systems use), then you can perhaps create an expert system with many more sound primitives than letters, but that is far quicker to write in.
What's the point of all this? The point is that if you are in the business of editing things, and you don't use some kind of shorthand editing syntax, you have failed. The point is that if you are a programmer, your editor better be doing a lot for you, and if it isn't, you had better be in the process of making it do more for you. This is the appeal of IDEs; they allow programmers fast access to many repetitive tasks; the big ones are usually writing a variable correctly or viewing the documentation on a particular code object. But these are only good for programming.
So, you should use Vim or Emacs. Or a plugin that emulates one of those and emulates it well. If you don't already, you should pick one (either is fine) and learn it. They are not "normal" editors; they pack their own extensible "editing shorthand" for common editing tasks for all text, not just Java code, or C# code, or code in general. Once you are comfortable with the philosophies behind their shorthands, you can start to alter them as you see fit. While you are learning, concentrate on doing things via shorthand rather than the initially quicker long way. Delete words using dw, internalize what 'w', 'b', and 'e' do. or whatever control sequence it is in Emacs. Start changes with c.
Don't let people lie to you and tell you speed doesn't matter. Ideally, text would change as we identify and mentally solve problems with it, at which point we'd move on to the next problem. For now, we struggle with the keyboard.
Now that my public service announcement is complete, onto the real matter at hand. I discovered two things about vim tonight that scratch a few itches of mine! The first is mksession, which allows you to save editing sessions to a file. You can hook this up to an autocmd or a small script to have vim always save your sessions, if that's your poison. If you are editing a bunch of files but want them closed temporarily, save the session in a file and then source it when you're done!
The other is a modification to buftabs that I had read about a while ago but not incorporated into my work flow. Essentially, buffers always "exist", and even when I close them the number of subsequently created buffers is as large as the number of buffers that had existed previously + 1. That means that over the course of an editing session where I might edit 20 different files, my next file open command will result in a buffer with the number '21' even if I only have 2 buffers still open. Michele's patch was what I needed, but I figured I'd make an option out of it: you can get a similarly modified buftabs.vim that enables counting only visible buffers in the buffer tab list via a variable "g:buftabs_ordinal".
Oh, Happy 21st Birthday, Philip.
tags:
general tech
,
linux
comments: 0
