How would you render source code if you weren't tied to a 2D grid of monospace characters? I'd probably start by using a proportional font for all words in the code. I posted an example of this here: https://mobile.twitter.com/FKohlgrueber/status/1156152950093426688 After getting used to it, I feel like it's easier to scan the code in that representation. What do you think?

I agree with you, I find it more readable! In your example I find nothing that is better in monospace.

Hey, are you two sneakily making the point that “textual” is just a subset of “visual” and we’ve been using visual programming languages all along…? 🤨😆

https://syvis.surge.sh/ErZoPhsMTcDvGT9pZswo/ 😁

Verdana has been my programming font of choice for some time. #what-is-Smalltalk-may-never-die

My point is that "textual" is more than what our 70's terminals and text editors support currently. Websites and word processors have shown more advanced textual systems and it's time to make similar progress in programming tools.

Though getting Word to not have weird hidden formatting oddities in a shared document? It's not a thing I'm managed to accomplish.

@wtaysom this could be solved by separating the view and edit representation (think LaTeX)

@Adrian Sieber Syvis looks interesting. Is it an open source project? I can't find any info about it.

It’s supposed to be open source. Haven’t found the time to release it yet

Weirdly, perhaps, I'm especially interested in where you drew your inspiration from in terms of visual style, that's why I was looking for a project page 🙂

The design is my own. Not sure If i was inspired by anything in particular…

TextMate uses mixing fonts to great effect in their Markdown rendering, one of their best tricks is using multiple font sizes for things like headers. Here's an image comparing TextMate and Atom's Markdown rendering

I had been using that in the past, but I’m ambivalent. Markdown was explicitly designed to be readable as plain text. If people start formatting markdown shitty (e.g. more than 80 characters / line) just because it looked good in their editor, I get really annoyed ^^

Ha, doesn't that apply to everything in this thread? 🙂 I'd consider plain text a file format, not a specific rendering (otherwise wouldn't syntax highlighted code not be plain text?) If you want to say "Markdown was designed to look good in Monospace fonts without colors or weights" then you can, but that seems awfully dogmatic to me personally. The beauty of plain text as a format everyone can use the tools they want, with the features they want, and we can all read and edit the same file!

Sorry, but I’m awfully dogmatic 😂

Totally fair enough 😂

paging @andrew blinn since fructure takes this idea one step further:

@Garth Goldwater I know both projects and I'm interested to see where they'll go in the future. My current hypothesis is that standard text editing is actually a really powerful input method, both because it consists of only a few primitive operations and because people are used to it already. Generations of structure editors have failed to become mainstream and I think that a big factor for that is that the interaction (while being really clever and conforming to the inherent structure of the code) isn't intuitive / primitive enough to not stand in the programmer's way. That's why I'm currently exploring which features of structure editors (e.g. advanced rendering) can be used in an editor while keeping the interaction close to what users know already.

Proportional fonts shrink the horizontal anywhere from 20 to 25 percent. This improves readability; however, most proportional fonts are not designed to highlight punctuation characters, which are incredibly meaningful in most languages. So that is a big drawback. Also, monospacing is much better for editing, as you often need to get to a specific point, and in proportional fonts some of the letters are optimized to be very close together; in fact, if your kerning is good, the letters will overlap quite a bit, and Apple is very good at kerning. So this works against you. You can fix the punctuation issue by forcing people to have a specific font, but that is not a recipe for acceptance. For this reason, although proportional fonts are a nicety and do increase readability significantly, during editing they are a drawback, and so i think a dual mode system will be necessary: proportional for printing, scanning, and monospaced during editing.

How about some literate programming, elastic tabstops, hyperlinks, and schematic tables?

@Edward de Jong / Beads Project That's why I've used a proportional font for words (keywords, variable names, ...) only. Punctuation characters and spaces are still monospace so that they're large enough. I don't see a problem in editing words displayed using a proportional font, I'm actually doing this right now to write this text. Using different fonts could easily be implemented in a code editor that supports syntax highlighting. In addition to color and weight, one would also specify a font for each token type.

@Felix Kohlgrüber Ron Baeker did some research on typography for code. I haven’t read this, but it turned up during searches: https://books.google.ca/books/about/Human_Factors_and_Typography_for_More_Re.html?id=QstWAAAAMAAJ&redir_esc=y

@guitarvydas I think I've read a part of this book a while ago. I'm not sure how relevant it is nowadays because display and font technology have advanced a lot in the last 30 years, but I'll take a look at it again. Thanks for reminding me 😉

Fructure looks pretty good. Do you know if it supports drag and drop?

i don’t think so yet but it’s very much a work in progress

@Steve Dekorte soooon... Most of the hooks are in for mouse support. But I'm taking a while to focus on perf and address some technical debt

This is my exploration of the topic from a few years ago. https://www.joshondesign.com/2014/08/25/typopl2