Hacker News Reader

Comment by unfamiliar | Hacker News Reader

Why does source code have to be shown in fixed width? I've been using non-fixed width fonts for about a year now and I find it much nicer on the eyes. The only downside I've found is that sometimes things don't line up quite as nicely, which is purely cosmetic.

View on HN

If you use vim keybindings, it's certainly nice to be able to move between lines without your cursor jumping around.

Most people consider that anything but cosmetic.

Well the indented parts will always line up correctly (since all they have before them are spaces or tabs), the only problem is if you use spaces for alignment after you've already typed some text.

the one true argument alignment style™ does not work (well) with variable width fonts:
retval = select(readFDCount, &readFDs, NULL, NULL, &timeout);
or:
d = [NSDictionary initWithObjects: objects forKeys: keys count: count];
added

The first would be easy to simulate semantically, treating the leading whitespace as a flexible tab stop and thus replacing all the leading spaces with a space of the appropriate width (basically, the editor would replace the leading spaces with `retval = select(` with opacity 0).

The second would be more difficult to handle, but so long as you know what to look for to indicate the style is being done it could be handled perfectly intelligently. It’s not the simplest thing, but it’s perfectly feasible.

Basically, variable width fonts can become fine so long as you also have semantic understanding of what is being achieved with whitespace. The use of monospace fonts is a cop-out, pure laziness. [Yes, I am deliberately stating this more strongly than I believe. It’s an understandable laziness, as the problem is hard and the industry and tooling all backs monospace, but it is laziness.]

Elasti-tabs can handle the first case, though I don't really see why you would want to bother. The second case...I don't think is reasonable.

Couple replies, but nobody stated the (to me) obvious. My source code is displayed in the same font as everything else in my terminal, and using a variable width font for terminals yields some pretty insane results.

My solution to the things not lining up nicely was to give up column alignment completely. In fact, I did that long before I started coding in proportional fonts. I think it was giving up column alignment that opened my eyes to the possibility of using proportional fonts at all. If you don't use column alignment, code looks pretty much the same in a proportional or monospaced font.

BTW my favorite coding font right now is Trebuchet MS on a high-DPI display.

I went through a stint of coding in proportional fonts about 15 years ago. Mostly, I liked it (I used to use Verdana myself, I think?) - you can often get a fair bit more on screen widthwise, which means you can have more files side by side, and the overall appearance is quite pleasing.

Don't recall anything specific that got me to change back, but change back I did in the end. Just a bunch of small things adding up, really, a combination of limitations in commonly available tools, and the repeated need to print nicely-formatted tabular things to the all-pervasive monospaced text console. Swimming against the tide just ended up being more hassle than I felt it was worth.

It does not have to be. Go ahead and use nice proportional fonts and never looks back. There are certainly no shortage of them that are high quality and easy on the eyes.

But for the rest of us, having a fixed width font is as important as any other consideration. And we're always on the lookout for a fixed width font that's as pleasing and readable as you proportional font people enjoy. Don't be jealous of us getting all the articles and blogs, because those only exist because we're jealous of you and trying to catch up.

On the other hand, I don't think I've ever seen a proportional font designed specifically for programming in. Like, with the same "make sure 1/l and 0/O look different" considerations programmers' fonts get, but proportional.

You should check out Input, which is exactly that. I've been using it for a couple of months, can definitely recommend it. The only issue I've run into is that certain features in Sublime Text don't work so well with proportional fonts, such as indent guides.

http://input.fontbureau.com

The preview page is amazing.

I've been using Trebuchet MS for coding, and it does a good job on this: all the confusing pairs are easily distinguished. For example, the lowercase "l" has a little rounded hook at the bottom to it doesn't look like a capital "I". It's not perfect, but I've been enjoying using it.

Before that I used Georgia, which is also fairly good in this area. I stopped using Georgia because it rendered poorly with too-thin stems in Windows 8.1 on a MacBook Pro Retina. Looked fine in OSX and on my ThinkPad's 145 DPI display.

I've used "Untyped" and "Trim" from this collection[0], and they were plenty readable. They take care of ambiguous characters and provide a wider space character than general-purpose proportional fonts.

[0] https://code.google.com/p/i3project/wiki/Fonts

Serious question: what kind of codebases are you working on where there tokens in which it's not immediately obvious from the context whether they contain digits or numbers? I have never seen such a situation.

The most common concerns are a result of the font being monospace.

In most proportional fonts, 1 has a hat, and l is a vertical line; and 0 is a thin, squared off oval; while O is almost a circle. The characters become similar in monospaced typefaces so that they can fill the rectangle they're supposed to fill.

I and l are often indistinguishable; but there's no shortage of fonts that put the extra strokes onto I [eg: Verdana, Tahoma, every serif font...]

Proportional is still very contreversial. A few of us have made the transition, and won't go back to fixed-width, but many value the ability to do ASCII art (aka space-based alignment). Other than that, there is absolutely no advantage to using a type writer font on a modern display.

I've been using a proportional font since the beginning of the year. It took one week to adjust (things look weird for a few days).

I tried the Input font time ago and didn't like the way it looked, but maybe I have to fiddle with its settings and find a way to make it look nicer. I'm using DejaVu Sans inside emacs now. The only shortcomings with the font are that l (lowercase el) and I (uppercase I) to be indistinguishable, but it's rare that they cause trouble. Uppercase o and zero are distinguishable (zero is narrower), but maybe a marker inside the zero would be handy. Not sure about that. Context usually is enough to make them apart.

Overall a page of code formatted proportionally is much nicer to look at than a monospaced one, so I'm not going back.

It would be nice for editors to support alignment with proportional fonts inside lines (see http://nickgravgaard.com/elastic-tabstops/). Maybe this is not going to play with Python and similar languages but automatic transformation of spaces into tabs and vice versa has been around for years and we have more CPU cycles than we need now.

Proportional fonts do not work well with space-based alignment, but are fine with tabs.

Actually, you can't reliably use tabs for column alignment with proportional fonts. You can get everything aligned for the font you're using, and the tab width you've specified in your editor, but when someone else views the code in a different proportional font or a different tab width - or in a monospaced font! - they will likely see "off by a tab" errors.

Proportional fonts do work fine with tab-based indentation. If you stop using column alignment, as I did many years ago, then it no longer matters whether you use proportional or monospaced fonts, and it doesn't even matter whether you use tabs or spaces for indentation. All sorts of code fomatting questions just become non-issues.

And column alignment was always such a hassle, I was glad to give it up anyway. Column alignment is a pain to maintain - it all too often just ends up misaligned after people work on the code, it messes up version control diffs, and the occasions where it helps readability are easily matched by the occasions where it hurts readability.

But is rare that you're the only one changing and using the code. Fixed width code looks similarly aligned on all systems with fixed width fonts.

A code written in Helvetica would render bizarro on an editor running Futura.

> A code written in Helvetica would render bizarro on an editor running Futura.

Don't be so sure of that. If you were to load any of my code in your favorite editor and font, you would never know that I wrote it in a proportional font or what font I used. It would just look like ordinary well-formatted code.

The reason is simple: I don't use column alignment at all. Column alignment is the only reason that code formatting would ever depend on what font you use or whether it's a monospaced or proportional font.

Without column alignment, it doesn't matter in the slightest what font you write the code in or what font you read it in. Proportional, monospaced, any font you like. It will look fine.

That is interesting. How exactly do you format your code? I'm super curious. Maybe a code sample? :)

> Why does source code have to be shown in fixed width?

> ...which is purely cosmetic.

You've answered your own question. I do this for a living; I want to look at something I like to look at.

But to each their own.

> I do this for a living; I want to look at something I like to look at.

That's an interesting observation. When you spend so much time looking at text, it should be in a form that you enjoy viewing.

The funny thing is that's exactly the same reason I use proportional fonts: I enjoy coding more when my code looks good to my eyes.

Reply on news.ycombinator.com