Effective Suggest And Complete In An Eyes-Free Environment

*Executive Summary

Emacs has always provided a wealth of techniques for rapid keyboard input (abbrev, dabbrev, hippie-expandand completion come to mind) alongside a rich collection of tools for navigating among open buffers. And these affordances have significantly increased over the last few years with the arrival of packages like ido, company, helm etc., each replete with different strategies for rapid task completion such as flex and fuzzy matching. This article investigates these tools in an eyes-free environment, specifically in the context of Emacspeak and rapid task completion. I've not investigated every possible package in this space — instead, I've picked a collection of packages and techniques that have worked well in an eyes-free context. Finally, the ultimate metric I use in each case is the time to successful task completion — since at the end of the day, that's the only metric that counts when it comes to user productivity.

1 Terminology

For this article, I will use terms suggestion and completion to mean subtly different concepts. I'll also use terms explore and filter in describing various phases in user interaction.

Suggestion: Offer the user some suggestions that help explore the space of choices. (metaphor: avoid the blank sheet of paper syndrome).
Completion: Filter the available choices based on user input with the goal of reaching the target as rapidly as possible.
Explore: User does not necessarily know what he is looking for, but expects to be able to recognize what he wants from the displayed choices.
Target: User knows exactly what he wants, e.g., filename, or function-name, but would still like to get there with the fewest possible number of keystrokes, along with the needed memory aids to guide the decision.

Note that in practice, suggestions and completions work hand-in-hand, with the visual display playing a central role in guiding the user through the pace of available choices. In a typical user interaction session, the space of suggestions gets filtered by user input to produce the available completions (choices) for the next round of user input — think of this as a Suggest/Input/Filter/Target (SIFT) interaction loop. Similarly, explore and target type activities typically go hand-in-hand, with explore serving as a memory-aid for locating the target.

2 Tasks Where Suggestions And Completions Help Speed Up Task Completion

Here are exemplars of tasks that I perform often and where I require all the help that Emacs can provide in completing the task as rapidly as possible:

File Navigation :: Navigating to and opening a file — either code or prose.
Content Navigation :: Jump to a specific location (section, function, class/method, or pattern-match) in that file.
Buffer Navigation :: Jump to an already open buffer in a long-running Emacs. If that buffer existed — but has since been killed (by midnight for example), then re-open that buffer. I do everything in Emacs, so open buffers include a large number of ORG and LaTeX documents, Web Pages opened in EWW (news sites, documentation, blog articles), IM Chats (I use jabber), Mail Buffers — both open folders and previously sent messages, and much, much more.
Media :: Easily launch media streams including local and streaming media.
EBooks :: Open (or jump to an already open) EBook to continue reading.
Code Completion :: Complete function/method-name as I type with an easy affordance to move among the available choices. The Suggest/Input/Filter/Target interaction loop applies here as well.

Notice that as one performs all of these tasks, every target is an Emacs buffer or Emacs buffer location. In the case of completion, the target is a string that gets inserted at the current location.

3 Features Of Eyes-Free Interaction

Using spoken output — as opposed to a rich visual display — has the following special features and/or drawbacks:

A large visual display can offer the user many choices at a time, and the eye's ability to rapidly scan these choices makes for an extremely fast Suggest/Input/Filter/Target loop. As an example, an interface like=helm= can display a large number of initial choices, with the user filtering these down with a few strategic key-presses.
Spoken output takes time — and there is simply no way around this — speeding up speech-rate helps to a point, but speaking 50 choices very fast does not help the user in the explore phase. This means that effective filtering and ranking of the available choices takes on added importance.
More importantly, picking a Suggest/Input/Filter/Target (SIFT) interaction loop that depends on a large display is sub-optimal for eyes-free interaction.
Given (2,3), smart filtering, flex/fuzzy matching, and ranking based on past user behavior take on added importance in an eyes-free environment. As an aside, I have high hopes in this area for package prescient — though in my few days of usage, it has yet to make a difference in my productivity.
For many of the tasks enumerated in the previous section, (2, 3 and 4) make ido with flex and fuzzy matching extremely effective. In contrast, helm with similar flex and fuzzy matching (via packages helm-flx and helm-fuzzier) adds little extra benefit — and the fractional extra time to compute and display the choices can even lead to a minor productivity hit.
When it comes to writing code with completion, package company has proven extremely effective. Notice that when writing code, one rarely if ever resorts to fuzzy matching — this may well be subjective. Speaking for myself, I cannot think of function or method names in the context of fuzzy matching — said differently, it's hard to think xl for function-name next-line — even though in a given filtering context, xl might define the shortest path through the available choices to the target next-line. Given this, emacspeak implements a company front-end that allows the user to navigate through the available choices with succinct spoken feedback, and I use those choices only after I have typed sufficiently many characters to have a manageable number of choices — said differently, though package company is set up to trigger after 3 characters have been typed, I usually end up typing more — and often resort to dabbrev or hippee-expand to input this longer prefix.
Some of the shortcomings with eyes-free interaction enumerated above lead to my looking for effective work-arounds that might well work well outside the eyes-free context, e.g. when the available choices are too large to fit on a typical visual display. Interestingly, most of these have also been solved by mainstream Emacs developers in their never-ending/unerring quest for increased productivity — package ido and company are excellent exemplars.

Mapping Solutions To Tasks

This section maps the various solutions I use to speed up the tasks enumerated earlier in this article.

3.1 File And Buffer Navigation

I use package ido with add-_ons_=flx-ido= and ido-completing-read+ (formerly ido-ubiquitous) as my primary/only solution for this task. I've dabbled with package helm — primarily via command helm-mini but have found almost no use-cases where I did better with helm. I also use command org-switchb to quickly jump to any of my open org buffers – since that automatically filters the choices down for me — I can then get to the org-mode buffer I want with one or two keystrokes. Notice that in all of these cases, I'm relying on the fact that I mostly know what I want, i.e., the explore phase does not start with an entirely blank sheet of paper.

3.2 Content Navigation

Incremental search is your biggest and most effective friend in effective eyes-free interaction — this simply cannot be stressed enough. That everything in Emacs is searchable via incremental-search is a big win for eyes-free interaction. When you have a large visual display, the human eye is the search interface of first resort – you typically use a search-command only if the target is below the fold or far away from the cursor. Because spoken output takes time, I use isearch even when the target is one or two lines away.

Structured navigation comes next in my toolbox for navigating content — imenu for code, and section navigation for documents (org, LaTeX). I also use command occur to advantage since that provides a quick way of finding all the desired targets in a document. Given that program source-code uses indentation for displaying structure, hbuilt-in command selective-display remains one of Emacs' hidden treasures with respect to expanding/collapsing source-code.

Finally, I use a combination of isearch and structured navigation in org-mode buffres by collapsing the document, and then using isearch to reveal the desired content fragment. In the case of LaTeX documents, I use package reftex to generate a navigation buffer that functions as an interactive table of contents.

3.3 Locating And Playing Media

I keep all my music content organized under ~/mp3.
I keep playlist files that contain stream-links to my favorite Internet streams under emacspeak/media.
The afore-mentioned techniques using ido enables me to launch local and streaming media with a small number of keystrokes. Once selected, the content is played via package emacspeak-m-player which provides Emacs bindings to all mplayer functionality via that program's slave-mode. In addition, Emacspeak also implements a smart emacspeak-m-player-locate-media which uses Emacs' integration with command locate to turn the located files matching a given pattern into an interactive play-list.

3.4 EBooks

Jumping to already open ebooks is no different than buffer navigation. I organize all my ebooks under a single directory tree, and module emacspeak-epub implements a bookshelf that allows me to organize and browse my collection along various axies. Finally, Emacspeak implements a light-weight bookmark facility that works with eww so that I can save my place in an ebook across Emacs sessions.

3.5 Code Completion

As covered earlier, I use company along with dabbrev and hippee-expand while writing code. I also use yasnippet to generate skeleton code. I use auto-correct-mode to automatically correct repeated errors, and add abbrevs for commonly occurring typos.

4 Summary

Emacs' Suggest/Input/Filter/Target (SIFT) interaction loop is just as effective in eyes-free interaction — in fact more so .
Fuzzy matching when filtering is a big win when working with spoken output — it leads to faster task completion.
Navigating ones computing environment based on the underlying structure and semantics of electronic content is a major win — both when working with a visual or spoken display. The advantages just become evident far sooner in the eyes-free context due to the inherently temporal nature of spoken interaction.

If you have questions about this archive or had problems using it, please contact us.

[Blog] Effective Suggest And Complete In Eyes-Free Environment