The basic idea of looking at how we can improve workflows in editors is great, but I have issues with much of the actual analysis. Even the core premise—that al

The basic idea of looking at how we can improve workflows in editors is great, but I have issues with much of the actual analysis. Even the core premise—that all editors "look the same" is flawed. They only look the same to the extent that most of the screen is taken up by, of all things, text. In this sense, image editors also start looking suspiciously the same... Image editors, of course, have all sorts of tools and buttons, not just the image. But this is just a function of the main modes of interaction: mouse vs keyboard. Unlike an image editor, a text editor is used almost exclusively by a keyboard, so most of the controls are optimally presented as keyboard shortcuts. Then, the post goes on to argue by analogy: always a risky strategy. Would I put two pieces of paper side-by-side when I'm writing an essay? Probably not. But code is not text; often, I do want to compare two pieces of code next to each other, line-by-line... which is done perfectly by putting them next to each other. And the rest of the paragraph goes on to pretty much describe my Emacs workflow[1] anyhow: I often have one main buffer and a bunch of random resources in another buffer which I periodically move around or swap. Sometimes, I also have a browser window or two open in the same way. The buffers don't overlap per se. In practice, they actually do: each one shows a window into the underlying text or image or whatnot, and can just show a small part. (Moreover, I can have multiple windows into one document, which is occasionally useful in practice). The only constraint is the physical grid... which I might use anyhow if it was easy with physical things. I lose a bit of flexibility in how things overlap in return for not having to worry about positioning and having everything line up nicely; a great compromise. An important detail is that, in Emacs at least, open, closing and swapping panes is trivial. I constantly bring up new ones, look at new things in existing ones and then close them in the normal act of editing. Very transient, very flexible and largely possible because they don't overlap so that we can lay out new ones automatically instead of giving me a floating window to manually drag out of the way. My workflow still looks just like the wireframe in the blog post. Interesting. In the end, this is just going from the cozy world of tiling window management into the frontier of floating windows. While it might be friendlier to newcomers, floating windows are simply not as good for experts and, presumably, most code editors are aimed at experts. I would much rather take on a slightly worse learning curve to get my stuff laid out automatically, all from keyboard commands. My code editor is one of the tools I use the most, so the trade-off is a no-brainer. In fact, by using Emacs, that's exactly what I've already done! [1]: http://jelv.is/emacs-workflow.png http://jelv.is/emacs-workflow.png