Why Keyboard Driven Editing in this age of the mouse? First of all, the mouse is easy – you don’t need to learn anything to point, drag, and click. And for many problem spaces this is ideal: I browse the web with a mouse (usually because my work as a web application engineer requires it), and I wouldn’t dream of attempting keyboard-driven image editing such as with Gimp or InkScape. But there are places KDE (Keyboard Driven Editing, not the window manager) far exceeds the easy alternatives.

The Mouse/GUI-Driven Success

• When generic actions are needed and can be pre-coded with little customization required

• When a good GUI has been produced and meets your needs Before you say “duh,” try designing some GUI yourself. This is not a trivial task, and is bound to leave SOMEONE frustrated. Keyboard-interactions, on the other hand, are extremely close to the native implementation of a feature, and flow almost trivially from the in-code implementation of the feature.

• When it is desirable to avoid learning something new An example is when I want to print one-sided, black-and-white, fit to page, on a #10 envelope: I don’t want to memorize the LP incantation to make this or any other custom print-jobs work. The C-p GUI in modern applications will let me step through this print customization.

The cost of switching

Switching anything, be it verbal languages, programming languages (Clojure to JavaScript to PHP to Python is a disorientation that’s common for me now), social situations, or anything, really. Cognitively, it is very much the same with frequent changes from GUI to KDE environments, particularly if it is during the same tasks. Physically, too, there are health repercussions with frequent back-and-forth to the mouse beside your keyboard.

Keyboard-driven Success

Categories in which KDE is between excellent and requirement include

• Navigation & Search
• Custom commands
• Documentation

Navigation & Search

1. Find files or text anywhere in a project

   Tools like project-find-file allow you start typing the name of any file within your project (however many directories you have), and every editor has grep-like searching for text or tokens in the project. This is such a useful feature that GUI editors have it now, too; but even there, you have to come back to the keyboard to make it useful (type the name of the file). In the case of text search, GUIs usually support right click-options to search for a thing anywhere. This is about the same as “command where my cursor is” with KDE.

2. Go-to-line

   Going to a specific line number is often necessary, as when error traces give you the line you are debugging; and these aren’t always clickable error traces. With GUI, this is at least going to cost you a switching fee so you can type the number.

3. Find files anywhere on your system

   You’ll have to type the name of the file anyway; might as well use Linux locate (emacs: M-x locate) to hunt that file down quickly.

Custom Commands

GUI excel when there can be an icon or gesture that invokes a commonly-needed function. When specific options need to be set, however, you invariably end up incurring switching costs back to the keyboard. Meanwhile, the ability in a keyboard-driven editor to readily create macros or custom commands means that specific functionality can readily be executed in a single keystroke. GUI systems have started to add functionality for recording your actions, but the name tells that Emacs (Extensible MACros) is decades ahead of the competition here.

Documentation

Until voice commands for technical questions is solved, locating documentation will always require at least typing into a search engine. Why not avoid switching costs?

Conclusion

Key-board Driven Environments have been around since before the mouse (and long before touch-screen GUIs), but they are far from out-moded. Health, efficiency, and sheer power don’t make them easier for newcomers, but they have advantages that reward mastery and that only grow with time.