6 ms·

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

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
- kragen 2y ago
  rainbow parentheses are mentioned in the paper
WillAdams 2y ago
Have you considered/looked at Literate Programming? http://literateprogramming.com/ http://literateprogramming.com/ With a bit of help on tex.stackexchange.com I managed to put together a system which allows editing a .tex file (without the docstrip mandated almost everything is a comment greyness): https://tex.stackexchange.com/questions/722886/how-to-write-out-multiple-text-files-from-multiple-instances-of-latex-environmen https://tex.stackexchange.com/questions/722886/how-to-write-...
- Chris_Newton 2y ago
  Yes, I wrote some literate Haskell professionally a few years back. I think it’s an interesting and useful concept. In my experience, it also fundamentally changed the way I read and wrote code, with both pros and cons. What I’m advocating here is a little different, though. While it would certainly be useful to write documentation using more expressive formats than plain text, here I’m arguing for the ability to (a) attach that documentation to specific parts of the code at different scales and then (b) have all relevant information at all scales readily available depending on what I’m currently editing. One of the reasons I would like to have this ability in my development environment is that I found the literate style to be very helpful for writing informative documentation but relatively unhelpful for finding it again later. By its nature, literate documentation is organised primarily for a linear reading flow, like the story in a book, but most of the time when I’m editing code, that’s not my typical searching behaviour.
  - jll29 2y ago
    Apart from Donald Knuth, you are the first person that I heard from who used literate programming professionally. Would be great to learn more from your experiences, good and bad, if you every fancy writing about it.
    - Chris_Newton 2y ago
      Thanks. We did discuss this on HN a few years ago and I added a few comments, starting here: https://news.ycombinator.com/item?id=12048693 https://news.ycombinator.com/item?id=12048693 I continued to work on that project for a while afterwards, but I don’t think my overall views on the pros and cons of the literate style changed much from what I wrote there. If there’s anything you’re particularly curious about, I’m happy to discuss further (though my professional experience was limited to that one project, so I’m hardly an expert).
yonatan8070 2y ago
> 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. Visually, font ligatures do just that, and combine your !=, >=, etc. into single elements
- ReleaseCandidat 2y ago
  But they don't actually work, because there are many ambiguities. Is <= "less than or equal" or an arrow pointing to the left? And in the other direction too: is ≠ "!=" or "/=" or something else? And as soon as you allow 3 or more characters to build ligatures, your number of ligatures explodes, but you still miss some. For example it doesn't matter if <= is an arrow or LTE and => is an arrow, in a <=> all are wrong, same as in a >=> or a >>= or...
  - setopt 2y ago
    The main reason I stopped using programming ligatures that much is that many languages actually support Unicode characters in the source code, and this is actively used in some projects I work on. It then becomes important to see the difference between ASCII approximations and real Unicode symbols, since this is relevant e.g. when searching for a symbol in your code base or to see at a glance whether usage of Unicode vs. ASCII etc. is consistent. The only spot I still kinda use such a feature (prettify-symbols-mode specifically) is in LaTeX, where Unicode math is more rare and long equations become nearly unreadable without some kind of rendering in the source code.
    - kyberias 2y ago
      How are those Unicode characters typed in an editor with a normal keyboard?
      - dpassens 2y ago
        Depending on your operating system, you might have (the option to remap a key to) a compose key. Then you can press compose followed by, for example, <= to make ≤. This also works for letters with diacritics on them, like "o for ö or 'o for ó, currency like =C for € or =L for ₤, or other symbols like tm for ™. You might also be able to set up your own compose codes in ~/.XCompose, but that didn't work for me. Could be another casualty of Wayland or just some quirk in my setup.
MengerSponge 2y ago
> 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. Like ALGOL?
- Chris_Newton 2y ago
  Not necessarily the exact same symbol set, but yes. Nothing too fancy, just using widely recognisable symbols that have been supported by Unicode forever instead of half-baked, ASCII-centric alternatives that date from last century.
alextingle 2y ago
> Even allowing comparison operators like ≤, <, ≠ and = that align > consistently would be a useful start. Every text editor that understands Unicode already allows for that. If you want to use ≤ rather than <=, then you need to alter the language, not the editor.
- swiftcoder 2y ago
  You don't need to modify the language, and most popular editors already support this. You'll need to enable ligature support, and install a font that contains the appropriate ligatures (as many coding-specific fonts already do)
  - auggierose 2y ago
    That's not really a solution, is it, for example I don't want <= to be confused with ≤ within a string. What you propose is just one more half-baked solution that the industry is full of.
    - rollcat 2y ago
      That's why you need editor support for this; the lexer understands the difference between an operator and a string literal (that's how syntax highlighting works), and should be able to use ligatures in one context but not the other. (BTW I'm not a fan of coding ligatures myself, but they seem to be popular.)
      - auggierose 2y ago
        Yes, if you do it on top of the lexer it starts to make sense to me. I still think the language should also support the corresponding "ligatures", so that no confusion can result if you happen to enter ≤ directly, but this is actually a nice solution to the problem of what to do in your language aware editor when the user enters <= : nothing! You just assign to different token classes different fonts.
  - Chris_Newton 2y ago
knallfrosch 2y ago
Everything you say is already possible, and done. I don't know what Notepad you use to write your code, but VSCode with font ligatures (for comparison operators) and a linter (aligns the same as elastic tabstops) already does the 80% of what you want. The 20% rest – sidebar for documentation – are not implemented for a reason.
- tmtvl 2y ago
  > The 20% rest – sidebar for documentation – are not implemented for a reason. I mean, keeping an overview of the documentation open on the side is something I do every day in GNU Emacs, so I'm a bit curious what the reason is why it's not done in Microsoft VS Code.
  - zarzavat 2y ago
    You can do it in VSCode. It's running in a browser. There may extensions to do that or if not you could write one easily. The reason it doesn't come with the editor is because every language has its own specific documentation format, though I do wish that they could create a consistent set of keyboard shortcuts, search UI, etc for documentation.
- Chris_Newton 2y ago
  The 20% rest – sidebar for documentation – are not implemented for a reason. The sidebar to show the documentation is just a presentation detail. What I’d really like as a developer is (a) the ability to attach documentation with a specific scope ranging from small things like a function parameter or variable, though larger things like a function or a set of related functions, up to whole files or packages, and then (b) editors that recognise the scoped documentation and present it contextually. I’d like all relevant comments to be easily visible when I might want to refer to them. Also, I’d like to know what documentation exists in the first place, which is not always obvious when we rely on things like big banner comments at the top of files/sections or having separate README files scattered through the tree.
- eviks 2y ago
  Which liner aligns the same as elastic tabstops in real time without polluting your diff??
practal 2y ago
I've been thinking for quite some time about how to incorporate spacing properly into the syntax of a programming language, and I now settled for a simple solution: hard-code blocks of texts via spacing into the text format itself. I call the result Recursive teXt (RX, http://recursivetext.com http://recursivetext.com), and I am using it as the basis for the rest of my work on Practal, instead of using just plain text. A lot of issues are resolved with this, for example it is trivial to have different kinds of syntax live next to each other, as they can just occupy separate blocks.
anta40 2y ago
"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" That's already doable on vim/nvim. BTW, I'm on macOS, and install them via macport. Or perhaps because I already installed some specific fonts....
chipsrafferty 2y ago
You can customize the syntax highlighting with 15 minutes to 4 hours of work, depending on your IDE, languages, and particular preferences. If it's important enough to you to rant about it online, perhaps you should set a new standard to help others that also want syntax highlighting the way you do? And you'd also be helping yourself for the rest of time.
eternityforest 2y ago
I'd mostly just like markdown headings, and maybe even inline images and other formatting. It would also be very cool if we could use hyperlinks and backlinks. Like, you could have a code example that you could reference that shows up when you mouse over a comment in some code or something.

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

kragen 2y ago
rainbow parentheses are mentioned in the paper

WillAdams 2y ago

Have you considered/looked at Literate Programming? http://literateprogramming.com/ http://literateprogramming.com/ With a bit of help on tex.stackexchange.com I managed to put together a system which allows editing a .tex file (without the docstrip mandated almost everything is a comment greyness): https://tex.stackexchange.com/questions/722886/how-to-write-out-multiple-text-files-from-multiple-instances-of-latex-environmen https://tex.stackexchange.com/questions/722886/how-to-write-...

Chris_Newton 2y ago
Yes, I wrote some literate Haskell professionally a few years back. I think it’s an interesting and useful concept. In my experience, it also fundamentally changed the way I read and wrote code, with both pros and cons. What I’m advocating here is a little different, though. While it would certainly be useful to write documentation using more expressive formats than plain text, here I’m arguing for the ability to (a) attach that documentation to specific parts of the code at different scales and then (b) have all relevant information at all scales readily available depending on what I’m currently editing. One of the reasons I would like to have this ability in my development environment is that I found the literate style to be very helpful for writing informative documentation but relatively unhelpful for finding it again later. By its nature, literate documentation is organised primarily for a linear reading flow, like the story in a book, but most of the time when I’m editing code, that’s not my typical searching behaviour.
- jll29 2y ago
  Apart from Donald Knuth, you are the first person that I heard from who used literate programming professionally. Would be great to learn more from your experiences, good and bad, if you every fancy writing about it.
  - Chris_Newton 2y ago
    Thanks. We did discuss this on HN a few years ago and I added a few comments, starting here: https://news.ycombinator.com/item?id=12048693 https://news.ycombinator.com/item?id=12048693 I continued to work on that project for a while afterwards, but I don’t think my overall views on the pros and cons of the literate style changed much from what I wrote there. If there’s anything you’re particularly curious about, I’m happy to discuss further (though my professional experience was limited to that one project, so I’m hardly an expert).

yonatan8070 2y ago

> 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. Visually, font ligatures do just that, and combine your !=, >=, etc. into single elements

ReleaseCandidat 2y ago
But they don't actually work, because there are many ambiguities. Is <= "less than or equal" or an arrow pointing to the left? And in the other direction too: is ≠ "!=" or "/=" or something else? And as soon as you allow 3 or more characters to build ligatures, your number of ligatures explodes, but you still miss some. For example it doesn't matter if <= is an arrow or LTE and => is an arrow, in a <=> all are wrong, same as in a >=> or a >>= or...
- setopt 2y ago
  The main reason I stopped using programming ligatures that much is that many languages actually support Unicode characters in the source code, and this is actively used in some projects I work on. It then becomes important to see the difference between ASCII approximations and real Unicode symbols, since this is relevant e.g. when searching for a symbol in your code base or to see at a glance whether usage of Unicode vs. ASCII etc. is consistent. The only spot I still kinda use such a feature (prettify-symbols-mode specifically) is in LaTeX, where Unicode math is more rare and long equations become nearly unreadable without some kind of rendering in the source code.
  - kyberias 2y ago
    How are those Unicode characters typed in an editor with a normal keyboard?
    - dpassens 2y ago
      Depending on your operating system, you might have (the option to remap a key to) a compose key. Then you can press compose followed by, for example, <= to make ≤. This also works for letters with diacritics on them, like "o for ö or 'o for ó, currency like =C for € or =L for ₤, or other symbols like tm for ™. You might also be able to set up your own compose codes in ~/.XCompose, but that didn't work for me. Could be another casualty of Wayland or just some quirk in my setup.

MengerSponge 2y ago

Chris_Newton 2y ago
Not necessarily the exact same symbol set, but yes. Nothing too fancy, just using widely recognisable symbols that have been supported by Unicode forever instead of half-baked, ASCII-centric alternatives that date from last century.

alextingle 2y ago

> Even allowing comparison operators like ≤, <, ≠ and = that align > consistently would be a useful start. Every text editor that understands Unicode already allows for that. If you want to use ≤ rather than <=, then you need to alter the language, not the editor.

swiftcoder 2y ago
You don't need to modify the language, and most popular editors already support this. You'll need to enable ligature support, and install a font that contains the appropriate ligatures (as many coding-specific fonts already do)
- auggierose 2y ago
  That's not really a solution, is it, for example I don't want <= to be confused with ≤ within a string. What you propose is just one more half-baked solution that the industry is full of.
  - rollcat 2y ago
    That's why you need editor support for this; the lexer understands the difference between an operator and a string literal (that's how syntax highlighting works), and should be able to use ligatures in one context but not the other. (BTW I'm not a fan of coding ligatures myself, but they seem to be popular.)
    - auggierose 2y ago
      Yes, if you do it on top of the lexer it starts to make sense to me. I still think the language should also support the corresponding "ligatures", so that no confusion can result if you happen to enter ≤ directly, but this is actually a nice solution to the problem of what to do in your language aware editor when the user enters <= : nothing! You just assign to different token classes different fonts.
- Chris_Newton 2y ago

knallfrosch 2y ago

Everything you say is already possible, and done. I don't know what Notepad you use to write your code, but VSCode with font ligatures (for comparison operators) and a linter (aligns the same as elastic tabstops) already does the 80% of what you want. The 20% rest – sidebar for documentation – are not implemented for a reason.

tmtvl 2y ago
> The 20% rest – sidebar for documentation – are not implemented for a reason. I mean, keeping an overview of the documentation open on the side is something I do every day in GNU Emacs, so I'm a bit curious what the reason is why it's not done in Microsoft VS Code.
- zarzavat 2y ago
  You can do it in VSCode. It's running in a browser. There may extensions to do that or if not you could write one easily. The reason it doesn't come with the editor is because every language has its own specific documentation format, though I do wish that they could create a consistent set of keyboard shortcuts, search UI, etc for documentation.
Chris_Newton 2y ago
The 20% rest – sidebar for documentation – are not implemented for a reason. The sidebar to show the documentation is just a presentation detail. What I’d really like as a developer is (a) the ability to attach documentation with a specific scope ranging from small things like a function parameter or variable, though larger things like a function or a set of related functions, up to whole files or packages, and then (b) editors that recognise the scoped documentation and present it contextually. I’d like all relevant comments to be easily visible when I might want to refer to them. Also, I’d like to know what documentation exists in the first place, which is not always obvious when we rely on things like big banner comments at the top of files/sections or having separate README files scattered through the tree.
eviks 2y ago
Which liner aligns the same as elastic tabstops in real time without polluting your diff??

practal 2y ago

I've been thinking for quite some time about how to incorporate spacing properly into the syntax of a programming language, and I now settled for a simple solution: hard-code blocks of texts via spacing into the text format itself. I call the result Recursive teXt (RX, http://recursivetext.com http://recursivetext.com), and I am using it as the basis for the rest of my work on Practal, instead of using just plain text. A lot of issues are resolved with this, for example it is trivial to have different kinds of syntax live next to each other, as they can just occupy separate blocks.

anta40 2y ago

"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" That's already doable on vim/nvim. BTW, I'm on macOS, and install them via macport. Or perhaps because I already installed some specific fonts....

chipsrafferty 2y ago

You can customize the syntax highlighting with 15 minutes to 4 hours of work, depending on your IDE, languages, and particular preferences. If it's important enough to you to rant about it online, perhaps you should set a new standard to help others that also want syntax highlighting the way you do? And you'd also be helping yourself for the rest of time.

eternityforest 2y ago

I'd mostly just like markdown headings, and maybe even inline images and other formatting. It would also be very cool if we could use hyperlinks and backlinks. Like, you could have a code example that you could reference that shows up when you mouse over a comment in some code or something.