8 ms·

On the design of text editors (2020)

179 points by signa11 2y ago

niobe 2y ago
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.
- teo_zero 2y ago
  I share some of TFA criticism: syntax highlighting just emphasizes what you should already see without it. The word "return" is a keyword of the language, you don't need it to be visually different from the rest to recognize it. On the other hand, highlighting could help you with semantic. For example rendering in a different color a word that's not been declared/defined before would be greatly valuable. Telling a variable from a type would also be helpful in C-like languages (no, current syntax highlighting schemes don't do this, not even the ones backed by tree-sitter). What about a switch to grey out all local/static definitions and thus emphasize only exported/public ones?
msla 2y ago
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 https://multicians.org/mepap.html
- benreesman 2y ago
  Thank you kindly for that link. I actually have a link to TFA in the block header in my dots, and it seems a crime that one isn’t there as well.
- Ferret7446 2y ago
  What about RMS's ACM paper? https://www.gnu.org/software/emacs/emacs-paper.html https://www.gnu.org/software/emacs/emacs-paper.html
  - jll29 2y ago
    for academic use: https://dl.acm.org/doi/10.5555/888850 https://dl.acm.org/doi/10.5555/888850 https://dl.acm.org/doi/10.1145/1159890.806466 https://dl.acm.org/doi/10.1145/1159890.806466
Chris_Newton 2y ago
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/ https://nick-gravgaard.com/elastic-tabstops/
- vunderba 2y ago
  Agreed. There's a great deal of improvement I'd like to see in text editors and IDEs. Collapsible images as inline comments can be FAR more effective at embedding relevant information in certain sections of code. As far as "related coloration" - Jetbrains IDEs let you setup regex around comments that will color them differently which I use in collaborative environments so devs can quickly collate their TODOs, etc. There's also an extension called Rainbow Braces that helps to highlight opening/closing pairs with different colors. https://mordenstar.com/blog/how-to-build-a-better-ide https://mordenstar.com/blog/how-to-build-a-better-ide
getnormality 2y ago
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.
- ulbu 2y ago
  > No answer is given, because there is none. case closed, guys, we can all go home now.
- FullGarden_S 2y ago
  >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? The text editor or IDE can provide a feature to show(pop up) or hide(collapse) the side comment section when needed while formatting the comments to make them look bold or italic. This will become a quality of life improvement if the implementation is done right. If not, it will be very confusing as you mentioned. I think writing API documentation can become very easy and since the function and its comment/description align on the same line, generating API documentation will become easy as well.
- preommr 2y ago
  There's also the issue of screen real estate. I often have other windows (terminal, browser, the build application), and panels within the editor (git, file explorer, console, etc.). It's already a hassle to maintain all this. It would be even more annoying if when I am comparing two code blocks side-by-side, there's another view for each of those that I'd have to either manually handle, or mentally keep in mind to look for something.
  - skydhash 2y ago
    Which is why I like vim and Emacs where everything is a buffer that can be displayed in tiled windows. You choose your configuration depending on the current task. Jetbrains' IDEs are ok too, at least in the old UI. You can collpase everything to the fringe with nice shortcuts (XCode does too, but the default shortcut are horrendeous).
kragen 2y ago
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_VT100_terminal.jpg 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
- joveian 2y ago
  If you use a terminal editor you can get margins easily by configuring your terminal emulator to have margins (and usually there would be at least a small margin due to cell size not evenly dividing screen size). Personally, my terminal is "only" 127x31 and a major complaint I have with most user interfaces (including most of the web if you don't take imperfect steps to avoid it) is the font and line height being way too small. The small margin from the cell size leftovers works for me, though it is also uncomfortably wide if used fully for one text area and I set a default width of 78 characters in my editor and make exceptions to that as needed. Elastic tabstops sounds interesting, although the simple definition presented in the link above seems like there would be cases where adding a line is necessary just to get the desired horizontal indentation. A set of new characters could fix that and allow full document alignment characters as well as consecutive line alignment. I'm not fully convinced that some version of this is a good idea, but maybe it is.
  - kragen 2y ago
    which terminal emulator are you using? most don't seem to have an option for margins as for elastic tabstops, i want to make three changes. gravgaard proposes a minimum column separation of one space, which i think is a mistake; i want rowspan and colspan; and most radically i want to be able to nest a whole document inside a grid cell with ^k and ^l as delimiters. that would give you fully freeform nested tables
keyle 2y ago
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. Woah there, easy tiger. 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.
- Chris_Newton 2y ago
  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. I agree, though there is a lot of subtlety in this problem. I tried, with very modest success, to write a tool that would overlay some graphics showing these kinds of information on top of a regular code listing. The results were rather satisfying when the structure to be illustrated was relatively simple, as it often is in well-written code. However, trying to use those visuals to help analyse and understand less well-written code with complicated, tangled flows felt like looking at spaghetti code in a very literal sense. Qualitatively it made it obvious when code could benefit from some cleaning up, but that isn’t very useful information unless it also provides useful insight into how to clean the code up, and I never really found a style/format for the visuals that conveyed enough information to provide actionable insights but didn’t become so busy in bad cases that it became was hard to follow. 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’ve only had this discussion with one author recently, but FWIW, they swear by that kind of structured story planning software. I’m not sure how many of the concepts or presentation details in those applications would translate readily to tools for working with code, though.
mediumsmart 2y ago
There is only one true editor, the design is flawless and it’s not number six.
- robinsonrc 2y ago
  I tend to prefer the visual mode of Ex
  - 082349872349872 2y ago
    ed(1) is for those who can remember what they are working on.
- NikkiA 2y ago
  EVE ?
d_tr 2y ago
The author is the creator of the nano-emacs package [1], by the way. [1] https://github.com/rougier/nano-emacs https://github.com/rougier/nano-emacs
- dang 2y ago
  Thanks! Related: Nano Emacs – a set of config files to improve the look and feel of Emacs - https://news.ycombinator.com/item?id=33403169 https://news.ycombinator.com/item?id=33403169 - Oct 2022 (4 comments) Emacs Notebook - https://news.ycombinator.com/item?id=29932274 https://news.ycombinator.com/item?id=29932274 - Jan 2022 (1 comment) GNU Emacs / N Λ N O – Emacs made simple - https://news.ycombinator.com/item?id=29373104 https://news.ycombinator.com/item?id=29373104 - Nov 2021 (1 comment)
rossant 2y ago
(2020)
animal531 2y ago
Just the other day I made this comment here: https://news.ycombinator.com/item?id=41668304 https://news.ycombinator.com/item?id=41668304 "Bit of a side issue for me: I was working on my Unity game the other day and thought to myself, have IDE's really not progressed all that much in the last 10-20 years?...yada yada" I don't want to get sidetracked by commenting on it again but I highly agree with the paper, it's time to change things up.

179 points by signa11 2y ago

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.

teo_zero 2y ago
I share some of TFA criticism: syntax highlighting just emphasizes what you should already see without it. The word "return" is a keyword of the language, you don't need it to be visually different from the rest to recognize it. On the other hand, highlighting could help you with semantic. For example rendering in a different color a word that's not been declared/defined before would be greatly valuable. Telling a variable from a type would also be helpful in C-like languages (no, current syntax highlighting schemes don't do this, not even the ones backed by tree-sitter). What about a switch to grey out all local/static definitions and thus emphasize only exported/public ones?

msla 2y ago

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 https://multicians.org/mepap.html

benreesman 2y ago
Thank you kindly for that link. I actually have a link to TFA in the block header in my dots, and it seems a crime that one isn’t there as well.
Ferret7446 2y ago
What about RMS's ACM paper? https://www.gnu.org/software/emacs/emacs-paper.html https://www.gnu.org/software/emacs/emacs-paper.html
- jll29 2y ago
  for academic use: https://dl.acm.org/doi/10.5555/888850 https://dl.acm.org/doi/10.5555/888850 https://dl.acm.org/doi/10.1145/1159890.806466 https://dl.acm.org/doi/10.1145/1159890.806466

Chris_Newton 2y ago

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/ https://nick-gravgaard.com/elastic-tabstops/

vunderba 2y ago
Agreed. There's a great deal of improvement I'd like to see in text editors and IDEs. Collapsible images as inline comments can be FAR more effective at embedding relevant information in certain sections of code. As far as "related coloration" - Jetbrains IDEs let you setup regex around comments that will color them differently which I use in collaborative environments so devs can quickly collate their TODOs, etc. There's also an extension called Rainbow Braces that helps to highlight opening/closing pairs with different colors. https://mordenstar.com/blog/how-to-build-a-better-ide https://mordenstar.com/blog/how-to-build-a-better-ide

getnormality 2y ago

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.

ulbu 2y ago
> No answer is given, because there is none. case closed, guys, we can all go home now.
FullGarden_S 2y ago
>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? The text editor or IDE can provide a feature to show(pop up) or hide(collapse) the side comment section when needed while formatting the comments to make them look bold or italic. This will become a quality of life improvement if the implementation is done right. If not, it will be very confusing as you mentioned. I think writing API documentation can become very easy and since the function and its comment/description align on the same line, generating API documentation will become easy as well.
preommr 2y ago
There's also the issue of screen real estate. I often have other windows (terminal, browser, the build application), and panels within the editor (git, file explorer, console, etc.). It's already a hassle to maintain all this. It would be even more annoying if when I am comparing two code blocks side-by-side, there's another view for each of those that I'd have to either manually handle, or mentally keep in mind to look for something.
- skydhash 2y ago
  Which is why I like vim and Emacs where everything is a buffer that can be displayed in tiled windows. You choose your configuration depending on the current task. Jetbrains' IDEs are ok too, at least in the old UI. You can collpase everything to the fringe with nice shortcuts (XCode does too, but the default shortcut are horrendeous).

kragen 2y ago

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_VT100_terminal.jpg 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

joveian 2y ago
If you use a terminal editor you can get margins easily by configuring your terminal emulator to have margins (and usually there would be at least a small margin due to cell size not evenly dividing screen size). Personally, my terminal is "only" 127x31 and a major complaint I have with most user interfaces (including most of the web if you don't take imperfect steps to avoid it) is the font and line height being way too small. The small margin from the cell size leftovers works for me, though it is also uncomfortably wide if used fully for one text area and I set a default width of 78 characters in my editor and make exceptions to that as needed. Elastic tabstops sounds interesting, although the simple definition presented in the link above seems like there would be cases where adding a line is necessary just to get the desired horizontal indentation. A set of new characters could fix that and allow full document alignment characters as well as consecutive line alignment. I'm not fully convinced that some version of this is a good idea, but maybe it is.
- kragen 2y ago
  which terminal emulator are you using? most don't seem to have an option for margins as for elastic tabstops, i want to make three changes. gravgaard proposes a minimum column separation of one space, which i think is a mistake; i want rowspan and colspan; and most radically i want to be able to nest a whole document inside a grid cell with ^k and ^l as delimiters. that would give you fully freeform nested tables

keyle 2y ago

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. Woah there, easy tiger. 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.

Chris_Newton 2y ago
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. I agree, though there is a lot of subtlety in this problem. I tried, with very modest success, to write a tool that would overlay some graphics showing these kinds of information on top of a regular code listing. The results were rather satisfying when the structure to be illustrated was relatively simple, as it often is in well-written code. However, trying to use those visuals to help analyse and understand less well-written code with complicated, tangled flows felt like looking at spaghetti code in a very literal sense. Qualitatively it made it obvious when code could benefit from some cleaning up, but that isn’t very useful information unless it also provides useful insight into how to clean the code up, and I never really found a style/format for the visuals that conveyed enough information to provide actionable insights but didn’t become so busy in bad cases that it became was hard to follow. 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’ve only had this discussion with one author recently, but FWIW, they swear by that kind of structured story planning software. I’m not sure how many of the concepts or presentation details in those applications would translate readily to tools for working with code, though.

mediumsmart 2y ago

There is only one true editor, the design is flawless and it’s not number six.

robinsonrc 2y ago
I tend to prefer the visual mode of Ex
- 082349872349872 2y ago
  ed(1) is for those who can remember what they are working on.
NikkiA 2y ago
EVE ?

d_tr 2y ago

The author is the creator of the nano-emacs package [1], by the way. [1] https://github.com/rougier/nano-emacs https://github.com/rougier/nano-emacs

dang 2y ago
Thanks! Related: Nano Emacs – a set of config files to improve the look and feel of Emacs - https://news.ycombinator.com/item?id=33403169 https://news.ycombinator.com/item?id=33403169 - Oct 2022 (4 comments) Emacs Notebook - https://news.ycombinator.com/item?id=29932274 https://news.ycombinator.com/item?id=29932274 - Jan 2022 (1 comment) GNU Emacs / N Λ N O – Emacs made simple - https://news.ycombinator.com/item?id=29373104 https://news.ycombinator.com/item?id=29373104 - Nov 2021 (1 comment)

rossant 2y ago

(2020)

animal531 2y ago

Just the other day I made this comment here: https://news.ycombinator.com/item?id=41668304 https://news.ycombinator.com/item?id=41668304 "Bit of a side issue for me: I was working on my Unity game the other day and thought to myself, have IDE's really not progressed all that much in the last 10-20 years?...yada yada" I don't want to get sidetracked by commenting on it again but I highly agree with the paper, it's time to change things up.