Every time programming fonts comes up, I always have to plug using proportional fonts. For me, anyway, it increases readability in any language that isn't super symbol-heavy (Obj-C, for example).
Holy kerning Batman... Maybe I'm too sensitive to this, but this text rendering engine is BAD. It says "SPA WNING". Below in SPAWNED wn is overlapping. "(sha)red" has similar problems. Lowercase "cce" however is way too wide apart.
I can see how people may like the idea, but it looks like xcode was never tested with proportional fonts...
That screenshot is pretty old, from Xcode 3, back when I first switched to TNR. I have no eye for kerning, so it didn't bother me then, but it looks a bit better in Xcode 5: http://i.imgur.com/rRxUpDY.png (included quoted text "CHARACTER SPAWNING" so it can be a/b compared).
The comment is the only thing in a monospace font. It's a criticism, and a valid one, of your choice of programming font. Nobody in their rightest of minds programs in Times New Roman. I'm convinced you must be trolling us.
I also use proportional fonts for Java to make the code look like it's taken from an algorithms textbook. Also, idiomatic Java as produced by IDEs usually doesn't align variables, so the code looks OK as long as the space characters themselves all are of the same width.
The C++ code I work with usually has more strenuous alignments which are only possible to get right in monospace fonts.
My main problem with proportional fonts is not alignment (I don't really do that beyond the indentation) but symbols. Most proportional symbols, especially thin ones like dots, colons or the vertical 'or' bar, get too packed in between letters and can be hard to see. Since reading code with precision and ease is the most important trait I ask of my programming fonts, proportional fonts are out. But I'm open to suggestions about one that works.
I am currently designing/building a programming editing environment around proportional fonts (specifically, some kind of sans serif). You can see the effect in this essay I submitted sometime back on hackernews:
Its been fun getting font metrics working right (given a custom editor) and getting key-up and key down to work correctly, but overall, I think this is the future, especially in richer editing environments.
I really like this, and while I wouldn't code in just any font, this one seems to lend itself. Only nitpick would be breathing room around parentheses and "." in method calls. Right now it's a bit tight. Love this article though, definitely some cool stuff going on in this space.
Alignment is the problem here, not the proportional font.
I gave up alignment in my code many years ago, back when I was still using monospaced fonts. I gave it up because I was really tired of fiddling with spaces when I changed a name in code like this:
myType someFunctionName(someType someVariable,
someOtherType someOtherVariable,
int foo) {
...
}
I found that I just didn't care that "someVariable" and "someOtherVariable" weren't lined up one above the other. In fact, I actually liked the fact that the variable names and types were closer together, so my eyes didn't have to keep scanning across a sea of whitespace to match things up. And I really liked not having to add and remove spaces every time I changed a name.
As a bonus, the overall width of my code was often much less, as in this example.
Later I discovered that using this style, my code looked the same in a proportional font as it did in a monospaced font. So I switched to a proportional font and never looked back. But the code is still just as readable in a monospaced font.
I still use space based alignment a fair bit, though it can be faf. What would be really nice is for a code editor to support some sort of elastic tab-stop so I can tell it that some things should stay aligned and have it do any extra work needed. I'm not sure how that could be made low-/zero-effort easy from a UI PoV though, but it would work just as well with proportional fonts too.
Plus, as variables get added and renamed, the resulting realignment of tokens modifies lines unrelated to those changes, leading to messy diffs which degrade the effectiveness of most version control tools.
I clocked substantial time in Frontier back in the day, where alignment was fundamentally handled by the outliner core, so the text could just be wrapped as in an outliner. It works fine. I don't know what syntax highlighting would look like since I haven't seen it.
It does seem like the programming environment and language must be designed for it to work nicely, though. I've tried proportional fonts in several environments since then and it's always sucked for one reason or another.
Possibly Go is structured enough for proportional fonts to cleanly work though. Haven't tried it yet; I use emacs and last time I tried proportional fonts in that it was a joke. (And that was just straight-up English, no programming at all.)
I suppose I should in fairness observe this was actually a long time ago. Since then emacs has switched to XFT; I haven't tried it since then, because well, as I mentioned most languages don't work very well with it either. But perhaps I will try it in a Go buffer here.
(A few minutes later.) Hey, this isn't so bad. I'm not sure everybody would appreciate me sticking with it since it makes it hard to tell when you've got a "long line", but it's certainly radically better than I remember from the last time I tried this.
For those who may want to play at home, I use the Droid series of fonts for my programming and I just eval-region'ed this:
(custom-set-faces
'(default ((t (:stipple nil :background "#ffffff"
:foreground "#141312" :inverse-video nil :box nil
:strike-through nil :overline nil :underline nil
:slant normal :weight normal :height 105
:width normal :family "Droid Sans")))))
YMMV may vary, of course. Especially if you're not using a white background. :)
Go's attempt to auto-align struct name and types isn't working so well, though. (Fortunately, gofmt takes care of it so I still can't be wrong.)
Further follow-up: You don't realize how much you're subconsciously using the "shape" of the code to guide you until you change it and suddenly feel lost, like I'm in a fresh code base I've never seen before, despite the fact I'm actually in something I've more-or-less written from scratch over the past six weeks, which is just about the maximum level of familiarity you can have with a piece of code.
i can't understand how anyone can look at this and think "hey, this is nice!". I'm not sure if it's because of using a proportional font or if it's because of the serifs, but this makes me want to do this: http://farm5.staticflickr.com/4113/5031198207_ac01d2c500_b.j...
At high resolution such as printed text at small sizes people tend to find seriffed fonts quicker to read. Something to do with the serifs leading the eye. At larger sizes they just add distraction like any other decoration, and at low resolutions on small-ish text they can produce quite a mess legibility wise unless the font is very well designed with low resolution rendering in mind. Sub-pixel rendering help a little, but not nearly as much as some seem to think.
Some people insist on seriffed fonts even for small text in low resolution environments because they find them easier to read elsewhere, without considering that the different environments (screen and print) have quite different properties (or being blind to where the difference is, I know someone who blames the OS's font renderer when he is asking it for the impossible). Of course as screens progressively move towards higher PPIs (I'd love a 24"+ display with the PPI of my phone's screen) the low resolution rendering thing will diminish as an issue.
;; you have to do this twice the first time, and sometimes after that if
;; you've run it in another buffer. I think the variable
;; `buffer-face-mode-face' isn't behaving quite buffer-locally
(defun gpc/toggle-proportional-font ()
"Switch between my default proportional and monospace
typefaces."
(interactive)
(let* ((family (if (boundp 'buffer-face-mode-face)
(plist-get buffer-face-mode-face :family)
gpc/default-font))
(new-family (if (string-equal family gpc/proportional-font)
gpc/monospace-font
gpc/proportional-font)))
(message "Set font to %s" new-family)
(setq buffer-face-mode-face `(:family ,new-family))
(buffer-face-mode t)))
Eeeew... I can't do proportional fonts while programming. I like more width and I like certain things to line up. I have tried others, but I always go back to Consolas.
For that to work well enough, we’d need an indentation engine that doesn’t depend on manually entered whitespace — tabs aren’t enough, because you don’t always know how many tabs you’ll need. And that just won’t work at all for certain languages (see, for example, Perl, which is pretty good at confusing syntax coloring engines with perfectly common code due to some of its design choices).
I seem to remember reading somewhere that Stroustrup (the inventor of C++) also uses a proportional font. I've tried it a few times, but generally end up using a monospace font due to laziness - I update the software and can't be bothered to change :)
I've kicked around Sys (http://www.fsd.it/fonts/sys.htm) for this purpose before and like it. I'd rather code in a proportional font, but I feel like we need an editor designed for one, which we really don't have right now. Univers is also all kinds of beautiful.
I've tried out a bunch, and I haven't found one I like better. That said, Open Sans looks pretty good, and you may like the sans sarif style better. If you find anything awesome, I'd love to hear about it!
Woah, in your screenshot are the comments a smaller font size? I don't know if I could learn to deal with the proportional fonts, but I do really like the idea of comments rendering smaller.
Xcode theme using Times New Roman: http://31.media.tumblr.com/tumblr_kweyqtEkg41qzsc93o1_500.pn...
Download link: https://gist.github.com/coryalder/811771
Not for everyone, of course, and definitely not for all langauges, but still worth mentioning.