It is not clear if these implicit choices derive from the ignorance of alternatives or if they derive from developers' habits, reproducing what they are used to.
The OG literally invented editing text on computers, and since then many novels have been written on keyboards and computers. The "text" editors have fed back into the more basic code editors and we're in a mixed situation between "comfortable to edit code" and "comfortable to edit text".
I'd be interesting to explore more visual programming built into text editors, as an overview of code flow, because right now the best we have is the direct stack trace. In terms of code it would be great to have integrated tools that show a visual representation "map" of the functions usage and data flow.
As for regular prose, it would be interesting to see editors specializing in poems and other use cases. I know some editors specialize in novels by having wiki like features of linking characters to storyline and research work.
I'm not sure how much of those are used by real world authors though, I think they mostly are trying to get closer to the "typing machine" as possible, removing any kind of distraction to get the X words per day in.
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
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.
"Multics Emacs: The History, Design and Implementation", Copyright © 1979, 1996 Bernard S. Greenberg
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/