I do wish we were more adventurous in how we present our code in editors. As the article says, we seem to be stuck in a rut. Typography in the main editing area is almost always based on a classic monospaced text file. Colours are almost always based on “syntax highlighting”, which in turn often involves distinguishing elements of the language we’re looking at whose differences aren’t very important.

Given the potential of modern graphical environments and typography, I’d like to see languages and editors adopt simple spacing improvements like elastic tab stops¹. I don’t want to chose between an aesthetically pleasing layout that draws attention to patterns and anomalies in my code and a layout with completely uniform spacing because anything more carefully aligned is a pain to maintain in later edits and adds noise to diffs. We could shrink blank lines to half-height as well, which would keep the useful visual separation but waste less space.

I’d like to use a (somewhat) wider range of basic symbols than whatever we had in ASCII last century. Even allowing comparison operators like ≤, <, ≠ and = that align consistently would be a useful start.

I’d like simpler syntax highlighting, concentrating on distinguishing major language elements like literals, variables and types, and emphasising problems I probably care about like unclosed strings and misspelt keywords. I’d also like to see colour used more effectively for matching related code like opening/closing pairs or the definition of a value and later references to it.

I’d like to see a sidebar for documentation, not unlike the example for comments in the article, but allowing documentation to be attached at different levels from an individual function or variable up to an entire file or beyond, then having the editor automatically offer all documentation relevant to wherever I am in the code and whatever I’m typing there.

If we were designing a UI for another application, we’d always consider aspects like spacing, symbols and iconography, colour schemes and how to show and navigate related information. It’s strange that we give so little consideration to them in the tools we use ourselves!

(Join me next week for part two of the epic rant, provisionally entitled Why aren’t we all using semantic diff tools yet?)

¹ https://nick-gravgaard.com/elastic-tabstops/

rougier says that on an 80×24† vt100 40 years ago margins were an unthinkable luxury, but as you can see in any photo of a vt100, they actually do normally have margins: https://datashark.academy/wp-content/uploads/2018/03/DEC_VT1...

a little thought about how crt displays work suffices to see why this is the case. if you carefully adjust your deflection coil amplifiers to perfectly align the edge of the text with the physical edge of the display tube, you will almost certainly cut off the edges of the first or last lines or both

marginless displays are a product of flat-panel displays and window systems

i'd like to second the recommendation to look at gravgaard's elastic tabstops idea

_____

† 25 actually i think

There's no end of unpopular experiments in double pane formats where one pane holds text and the other holds comments, footnotes, etc.

They're unpopular because they're confusing and brittle. How is the relationship between the two maintained when the developer is hard at work, when the text is not just a set piece for pretty presentation? No answer is given, because there is none.

Some food for thought. Although I think the authors criticisms of syntax highlighting are a bit personal and subjective, alternative schemes would be interesting to explore.

This, of course, is the true paper on the design of text editors:

"Multics Emacs: The History, Design and Implementation", Copyright © 1979, 1996 Bernard S. Greenberg

https://multicians.org/mepap.html