"Patch Grid" Sounds Like a Useful Editor Technique

I came across a link to Austin Henley’s dissertation “Human Centric Tools for Code Navigation”.

There are three interesting tools discussed Henley discusses for navigating code:

• navigating code you’re working on now

• navigating through the history of code you’re working on
  (though his tool is for visual dataflow languages)

• navigating the structure of the code you’re working on

“Ribbon” of Open Files is a Great Idea

Of these, I found the “navigating code you’re working on” most exciting. The “navigating through history of code” discussed was aimed at visual dataflow languages; and tools to navigate code structure sound cool but it’s probably a difficult tool to get working outside of full-fledged IDEs.

Henley’s Patchworks sounds like it’d be useful for navigating code you’re currently working on. Short video visualising the idea. I’d describe it this way:

• A scrollable pair of tiled rows of editing panes.
• A “ribbon” is the 2*m array of open files.
• A “patch grid” is the grid / scroll viewport over the open files.

That is, your editor window shows a 2x3 grid (2 rows, 3 column) grid of editing panes, and you can scroll the open files.

This is comparable to navigating multiple “desktops” in window managers. (A feature so useful that now even Windows has this out of the box).

I think it’s also worth mentioning a couple of details:

• It’s beneficial if the user can quickly “zoom” into the split tab pane. (e.g. Tmux has split panes, but also offers a “zoom into pane” feature).
  • Although “keep the unit of code you’re editing small enough that it can be managed in a pane” sounds a nice ideal.
• Henley’s Patchworks offers a “zoomed out” view of the ribbon, so that it’s easy to recognise which open files are where in the ribbon.

Reasons to Be Excited

I think there are many reasons to be excited for this idea:

1. I might not be the most eloquent, but I feel like it’s relatively easy to to describe in terms of features developers are used to at the moment. Scrolling, editing panes, tiling.

2. I feel this idea is kinda-sorta close to workflows I like at the moment.

   • e.g. in vim I love using unimpaired so that I can press [b and ]b to switch between “previous buffer” and “next buffer”. (buffer = “open file” in vim terminology).
   • e.g. I love switching between multiple desktops. Usually I’ll have “terminal”, “IDE”, and “internet browser” as a working group of 3 desktops focused on the same task.
   • e.g. I already often split the panes to make use of “code I’m working on” and “output”. Plugins like slimux make use of this idiom.

3. The editing programs developers use tend to have split editing panes. So, “scroll a ‘ribbon’ of files through a grid of editing panes” seems like it’s a feature which can be implemented broadly.

4. I feel that the workflow of: “I’m looking at these functions (which aren’t all next to each other in the same file” is fundamental to maintaining non-trivial software.
   The idea of a “patch grid” sounds like it supports this workflow better than “switch between files in the editing pane”.

Reasons to Not Be Excited

I even made an effort at writing a plugin for Emacs, so I’ll be trying the idea out. (It’s usable, but still a work in progress).

Navigating To Another File is Already Very Quick

“Navigating” to a different file is something that’s already really easy in modern editing environments.
e.g. in an IDE I can have a “jump to file/function” with fuzzy searching which takes as long as “command invocation + type query + select result”.

The discussion in the dissertation is comparing how long it takes developers to navigate to files using Patchworks vs Eclipse IDE; but AFAICT the users were using the mouse to navigate files.

But, using the keyboard to control a text editor can be very quick, so I think it oversells the idea that the benefit is in navigation speed.
I might believe that using “patch grid + scrollable ribbon” would allow for less time navigating for power-users of an editor across an editing session. But that feels like a less tangible benefit.

Editors Already Support Grid of Split Editing Panes

The ‘novel’ idea to me of Henley’s Patchworks is the “ribbon” of open files that the editor should be able to scroll through.

A “patch grid” minus scrolling the “ribbon” is just a 2x3 grid of editing panes, which editors already support at the moment.
People don’t commonly split panes in IDEs, and AFAICT it’s uncommon to see people use 2x3 grids of panes like that.
I think people don’t use them because it’s difficult to set up, and there’s hardly an obvious benefit to splitting an editing pane into 6.
(Right now, I split an editing pane into 2 all the time).

Maybe the idea of a scrolling ribbon means that it’s less of a hassle to work with a set of open files with a grid of editing panes. (You don’t have to decide which open file to replace; you just have to scroll the ribbon over and open in an unused tile).

Existing Workflows Already Work

Editors / IDEs these days are packed with all sorts of complicated features such as multiple cursors or multiline editing.
There may be features that would be more efficient ways of doing what I want to achieve that my editor already has. I have to go out and deliberately try to improve.
Most of the time, whatever you’re doing to get the work done is good enough as it is.

If making effective use of a “patch grid” (and scrolling it) isn’t intuitive out-of-the-box (or from seeing someone else make use of it, I guess) then it might not be worth picking up.

That said,
not every user is a fan of “keyboard for everything”, and if using a “patch grid” is a big navigation improvement over other mouse-oriented workflows, maybe that’s good enough.

Benefits of Patch Grid and Ribbon May Be Unclear and Unintuitive

My impression is that a big benefit to a “patch grid”‘s structuring “open working set of files” this way isn’t exactly “see everything you need to see at once” so much as the mental model of a ’ribbon’ of buffers makes better use of associative memory, episodic memory, and spatial memory. (cf. section 2.4 “Human Memory of Code Navigation” of Henley’s dissertation).

I’d think a workflow of “quickly switch to other open file in the current editing pane” requires the developer to remember the code in the other files in their working set of open files.
So, surely a “patch grid” of open files make better use of associative/spacial memory than “quickly switch to another file” allows.

Henley’s dissertation discusses that one recommendation is to use the ribbon chronologically, by putting newer open files to the right of currently occupied panes.
I’m curious to try this out for myself, I’m curious to see how easy it can be to scroll the ribbon to open a different file, compared to just switching the file in the current editing pane.

On a Laptop Screen, 2x3 Grid Panes are Really Tiny

2x3 isn’t a magical grid size set in stone.
“2 rows of tiles” is more restrictive than a free-form 2D canvas of editing panes.
Maybe “3 columns of a pair of editing panes” a good number of editing panes to fit in human memory.

But from what I’ve tried on even a 15” laptop screen, a 2x3 grid of tiles feels like editing in a grid pane is an editor pane for ants.
This doesn’t matter much, since I think the benefit of a patch grid isn’t “editing in the grid panes”.

I’ll have to try it on a larger screen to see the difference.

---

---