"Hack has deep roots in the libre, open source typeface community and includes the contributions of the Bitstream Vera & DejaVu projects."
It's a bit disingenuous though. I'd call Hack a straight copy of Deja Vu Sans Mono, with a few very minor tweaks. On Linux using the TTF fonts I can't even see a difference in line height:
Aside from '_', 'i', '0', many of the changes are so minuscule that it feels more like a change for the sake of change. Some however are nice, like the parenthesis placement, cleaner 'r'.
One thing I really don't like is the change to a serif-style comma. They've probably argued that it improves readability, and prefer that over typeface consistency.
They should emphasize more the previous work they are using, otherwise they might come across as ... hacks.
I'll probably stick with inconsolata though. But good job, nonetheless.
> Some however are nice, like the parenthesis placement
I see the parentheses as problematic on their own. When I read the functions that don't have any arguments, it looks like they have one space character within the parentheses!
Thanks for combining these images. The red square was really clever for peripheral vision identification of the image.
I agree with a lot of what you said here. Weirdly, they went sans-serif with the 'i' and serif with the comma. I'm personally a fan of commas, semicolons, and quotations having the same visual flavor and the Hack changes went farther from that.
To turn the conversation to a slightly different direction:
this is a great case study of the kind of effects branding can have. Dejavu sans mono, an otherwise boring and established font, especially for those using Linux, somehow just seemed something sexy and exciting because it's a newly released, specially made font called Hack, it's a font that represents a very fundamental paradigm shift in how fonts have been, the seamless legibility this font offers is unprecedented. This font is finally the one thing that will enable you to code better than you could ever before. You can't wait to try it out, can you. Go ahead, take it out for a spin. Set your terminal to use Hack, open up vim, and write up a helloworld.c program. You won't believe it -- it'll all come out beautifully and without effort, you'll find the code writing itself through you.
Copyright infringement != plagiarism. They're not violating the copyright because they abide by the terms of the license.
They're also not plagiarising because they clearly cite its original source. They even go so far as to say "deeply rooted in" which seems to me like a euphamism for "virtually identical to".
The point here isn't that it's illegal or immoral, just kind of uninteresting.
There are some very minor changes, but this got me thinking about tricky fonts are compared to software development in general. You can fork a font on GitHub and make some changes, but you can't really merge them back into the original font because fonts are expected to be entirely static. Perhaps they could accept pull requests for a DejaVu 2 or something.
Interesting. I hadn't thought of that before, but those examples seem to embody the struggle in the transition from classic print design to modern digital mediums.
I imagine someday we'll see more typefaces versioned like software, instead of alterations receiving new names. Or is this already happening?
And UniVGA, an emulation of the VGA font that provides much of Unicode (useful for a little Turbo Pascal nostalgia trip with an appropriate color theme, or the FPC IDE):
That's ludicrous. You can get better scanlines by using Cathode or Cool Retro Term, and the latter comes with the beautiful 3270 font that stands upon the long clean design heritage of IBM's 360/379 line. This beautiful font, by the way, you can take for a spin on any civilized operating system by simply typing `apt-get install 3270font`. Go, try it.
ttyp0 is way better than Terminus, which is so popular among Linux/Unix people. But if the world ever goes HiDPI, I guess bit-mapped fonts will die out.
> But if the world ever goes HiDPI, I guess bit-mapped fonts will die out.
No, it's the other way around. Anti-aliasing is a hack to make low-res displays slightly more palatable. Once the resolution gets good enough, there's no point in anti-aliasing your fonts anymore, and bitmaps start making a lot more sense.
How is anti-aliasing related? I was thinking about rasters: if you don't have many pixels, you need to use every single one the best possible way, so you manually layout every single pixel. If I have a ton, I can draw any vector glyph and I would not need to micro-manage the pixels. Can you elaborate or give me a link?
It takes far less cpu time to draw a bitmap than to draw a vector shape. An in-between solution is to pre-render vector shapes into bitmaps for later use; this is what METAFONT does.
I'm a huge Monaco fan. Slightly disappointed that Apple chose a Bitstream Sans derivative for its default monospace font. I don't dislike Bitstream/Deja Vu/Panic Sans/Menlo - it just feels derivative at this point and Apple often take opinionated stances on typefaces.
Nothing beats the lowercase "a" in Monaco.
I feel like it has a bit of whimsy that other fixed with fonts don't have. It's not stuffy or pretentious. None of the bowls are circular or ovular (except for the "o") all of the ASCII range characters are distinct. It looks great in its bitmap or anti-aliased vector versions.
I came to Mac OS recently from Linux and while I like Menlo, I found myself quickly going back to Inconsolata[1], which is really great for long coding hours, and works especially well for me with the dark solarized color scheme.
I've been using Monaco for Powerline for quite a long while now. The main issue is that most of the builtin proportionally-spaced fonts have some glyphs which are difficult to distinguish. Monaco gets the job done but other people prefer slightly different glyph styles or want to make their own fonts, more power to them.
I've been using Monaco 9 since I first started hacking away in HyperCard and BBEdit, and when OS X started screwing up the antialiased version of it I switched to ProFont which looks identical but scales properly
Have you tried Source Code Pro (http://adobe-fonts.github.io/source-code-pro/)? It's my go-to now when it comes to monospace fonts. I keep it installed on all my systems, right along side my dotfiles.
Does it show more lines than consolas in the editor? I just measured Hack with Consolas (9pt) in VS.NET, and Hack shows 54 lines, Consolas 65 (and for reference, lucida console 131). The page you linked to shows the typeface, which is nice, but it's hard to measure whether it's a font that's going to lead to more lines or less lines in the editor.
I switched from Consolas to Source Code Pro after I switched to a 4k monitor. On a 1080p display, I think I still prefer Consolas, but Source Code Pro is absolutely beautiful on a high-dpi screen.
I'm particularly fond of semi-bold. I find light is too narrow for my vision and taste. After a while of using the light version, it starts to blur together, but semibold works well. But my wife uses light and regular on her high DPI Lenovo.
For a complete change of style it might be worth having a look at fonts designed assisting those with dyslexia. Designed for uniqueness of glyphs and for minimising eye strain.
I've used them for several years ( even though I'm not dyslexic ) and now find 'normal' terminal fonts to be extremely harsh on the eye. Probably the best change I've ever made to my programming environment.
Despite having a different proposition and use-case, FE-Schrift seems have ended up with a similar yet much more aesthetically pleasing outcome. It doesn't have lower-case, which is a deal breaker for programming at least though.
Dina used to be my go-to font as well but a few years ago I switched to Anonymous Pro [1] as it tends to be more recognizable at the small font sizes which I use.
That's a strange feeling, huh? It's similar to how we always want more (money, vacation, etc.) in life, but when we get there we just want more again. I've had the thought about Consolas many times; "Why do I keep looking for a new one when I like Consolas?". I think the answer is that we always seek novelty, because that drives evolution.
A change in environment boosts productivity, doesn't it? I read somewhere, maybe in Peopleware, that in a lighting study, they found any change (brighter, darker) to a workplace imported productivity. The idea being that it was just the change, not really mattering what was changed.
Perhaps it reflects poorly on me, but I love novelty. Different places, new software, new languages (or improved features) - it's great. I'll get a huge boost working on a shitty desk in a cold hotel, for a week. I started learning Ruby, and while I find it revolting in a way (it's like the opposite of elegance), I'm enjoying learning it.
This must be a well known effect, as MS seems to make small but very noticeable cosmetic changes to their UIs. I feel ... something when using the older version. Something slightly beneath my conscious perception, something that changes and feels fresh when I upgrade. (Similar but not quite the same thing when I use a shitty cross platform UI that doesn't get things quite right.)
I should probably collect a few good fonts and color schemes and rotate them automatically.
And you know, it doesn't really matter when working. But the novelty is very useful to get me going. Once I'm rolling on a project, I can be in any broken environment and stay in the flow.
I could not agree more with almost everything you just said, even the Ruby bit (did the same thing, even bought a book, though I gave up a little prematurely).
The only time seeking novelty hurts me is with side projects. As soon as I get used to the project I lose site of the bigger goal, and then I just want to start a fresh, new side project.
I've been using the X 6x13 font for about 12-13 years. Though these days I've had to switch to a TrueType one that looks the same - presumably reproducing the pixels with hand-drawn boxes...
Hack is quite nice in terms of the aspect ratio, but in common with many modern fonts it doesn't look very good at low point sizes on a ~100dpi monitor. Not exactly unexpected - nobody bothers to hint their fonts any more, and/or provide bitmap versions for low point sizes - I'm sure it takes ages anyway and most people won't care - but still a shame. I have antialiasing switched off on Windows, and Hack looks pretty horrible. But 9pt non-AA Arial Unicode MS shows delightful-looking small fonts are possible...
Looks good on a retina display though. Just need to replace all my monitors with 250+dpi ones and I'll be set!
Same here :) I was a lucida console user for years (and before that Courier) but as I passed 40 my eyes told me it would be better to use something else. Consolas it was, and I have to admit, it's great.
I tried hack, it looked OK (in vs.net) but the 0 (zero) didn't render with the fill-in but open. That of course sucks, as for a programmer a 0 has to be different from O. Perhaps it's something related to vs.net's rendering, not sure.
I sometimes need Japanese characters on the console, so I got in the habit of using this font. The only thing I did was return the backslash character to be an actual backslash character (rather than yen symbol, which most Japanese fonts do).
Sorry, I don't have a picture of it (and I couldn't even find a good picture because they only show Japanese characters ;-) ). It's quite a nice programmer font, but just about the opposite to Consolas. Consolas is short and wide, whereas Ume Plus is very narrow. This gives you more columns, rather than more lines. I often split my screen left and right (tests on the right hand side) and due to poor vision, I have massive fonts. This gives me a few extra columns to work with.
As a retro-computing geek who had an early contact with IBM 3278 terminals, I am very fond of their font. So much, in fact, I recreated it based on earlier bitmaps that trace their history back to a student who copied it pixel by pixel from a real terminal. May not be your piece of cake, but you can try it:
Tamsyn [1] made me switch from Consolas. Now I am not even looking for another font. It is so perfect. But it being a bitmapped font, I get only two sizes. But I am so happy with it that I don't even mind...
Since everyone's mentioning their favourite code fonts -- any love for Ubuntu Mono? I know it's not trendy to like the OS default as a non-Apple user but I find myself always coming back to it when I see it in comparisons.
In addition to just being a nice monospaced font, I like that its non-monospaced version, Ubuntu, is also available. I can use Mono in my source and non-Mono in my desktop UI and everything looks consistent.
I love this and want to use it; I just wish there was a proportional version. I've spent a lot of time trying to figure out how to hack OTF to do my own programming font (proportional with programming-specific ligatures), but the how-to information available on the web isn't very complete.
The use of ligatures in Hasklig is very intriguing. Would really like to see more work in this vein. Could see benefits to Clojure (arrows) and even => in JavaScript.
This could be really cool, but I can also see it getting distracting and increasing oversight. The >= and <= signs look nice in Fira Code and Hasklig, but I worry I'd accidentally see them as > and < when debugging. Either way, I can't really try it because neither of those are usable in vim with iTerm2 and I'm not changing my whole toolchain just to try a font.
Hm. I was hoping maybe neovim (being, in some sense - "new" vim) might have fixed this -- apparently not (yet) -- looks like it's still modelled too closely on vim (not that that's a surprise, or all bad -- I suppose it was too much to hope for that this kind of design errors would be (easier to) fix(ed) this early:
Proper font handling is actually one of the few things that I find troubling with these "old" nix tools.
The combination of nice font handling and otherwise being lightweight (and working fine without any borders, which makes sense when paired with xmonad for a window manager) was one of the reasons I moved to Sakura:
(Not on my Linux box atm - so unable to test if ligatures actually work -- but either way it would appear vim does a little too much -- so even if the terminal handles ligatures, vim will not. Time to upgrade to ed! ;-)
I wonder if kakoune[1] supports ligatures in a capabable terminal? I'm guessing not, but have yet to try.
Also, I just discovered that AbiWord actually have a setting to get vi(m) keybindings -- not that I'd suggest moving from vim to abiword for editing code...:
Based on the issue[2] for Emacs support, it looks like the general "easy" approach is monkey-patching from two-symbols to unicode ligatures and back on the fly. Such an approach would probably work with vim too -- it'd probably be just as well to handle that bit via a pre/post processor -- and just type in the combined symbols directly in vim (eg: iab >= ≥ to insert the symbol for "greather-then" rather than >= -- and then just deal with editing that as a single symbol. You'd need to run the source through a transformation to change all occurrences back -- for most langauges -- so I'm not sure if it's really a good idea. But seems simpler if you just want ligatures, and there's a unicode glyph that matches the ligatures you want.
Ahem, well -- from the Haskling site: "Some Haskellers have resorted to Unicode symbols (⇒, ← etc.), which are valid in the ghc. However they are one-character-wide and therefore eye-strainingly small. Furthermore, when displayed as substitutes to the underlying multi-character representation, as vim2hs does, the characters go out of alignment."
So then again, maybe not. I suppose we just have to wait for the next display server tech to reinvent display PostScript along with a friendly API ...
When using a text editor or IDE that does not allow the user to adjust the line spacing (aka "leading"), my choice of programming font for the last 1.5 decades has been Lucida Console. It has tighter line spacing than any other monospaced font I've seen, thus displaying more lines of code within a window of a given height. Every time I hear about a new font designed for source code, I try it out, and am consistently disappointed at how far apart the lines are spaced. I haven't tried Hack, but looking at the screen shot it seems no better than other fonts in this regard.
Font designers never seem to consider tight line spacing as a potential selling point, and that makes me sad. :-( In fact, wider line spacing is sometimes touted as an advantage, for readability.
The 'f' is really ugly, and the * not being centered is a shame (it's used so much in source code for ⨉, it really should be vertically centered), but the reduced number of serifs is nice. I also like how === has less spacing between the lines, which fits common source code conventions which use = for underlines and horizontal rules.
On my Mac, Hack has increased leading (space between lines) which makes it more readable. Quite a bit more IMO. I'm curious why your screen shots show identical leading.
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.
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 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.]
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.
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.
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...]
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.
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.
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.
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.
> 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.
I've been using Anonymous Pro[0] for as long as I've known about it. I think I think Anonymous slightly more than Hack. On a different note, while this might sound like a silly gripe, I really don't like the "r"s in Hack. They seem off.
Seconded. Bought it ten years ago/ never looked back. And Fabrizio (the author) has been pumping out improved versions to all registered users about annually - just shows up in my inbox.
I hate it when sites like this change the normal scrolling behaviour. I use the trackpad on my MBP and on sites like this scrolling accelerates too quickly and gestures like going back don't work in chrome.
This. Why do people think that changing default behaviour is ok?
Hijacking scrolling always bothers me, for now I can't even read the content because of the scrolling being too annoying.
Maybe I should write a browser extension to remove scrolling hijacking.
Well, Hack and many other fonts like SCP is a bit too wide for Asians, since they may mix source code with 文字 like this. That's why I made Iosevka [1].
[1]: http://be5invis.github.io/Iosevka/
Thank you for this, I really, really like the compactness of it.
Not surprised to see Pragmata as an inspiration, I bought that font a few years ago when it was around US$100, and I still love it today, I probably use it 80% of the time :)
Now that I have a 4k monitor, I notice how unrefined the shapes of most programming fonts are. Of course this is on purpose and the right choice for typical resolutions, but it would be cool if someone designed a bit more elegant monospace font for 4k displays.
I have really enjoyed the look of 'Source Code Pro', an open-source monospace font designed by Adobe. It pairs well with Source Sans Pro for sans-serif text.
Not only do all of my editors use 'Source Code Pro' but I also often use it to display monospaced text on websites because of how clear and legible it is for reading as well as coding.
I cant wait to put Hack to the test, but for me the ultimate test will be if it can displace Source Code Pro from my editor!
6-7 years ago I bought the Essential version of the PragmataPro font (http://www.fsd.it/fonts/pragmatapro.htm). And although in the intervening years I have tried dozens of other fonts, I have always come back to the PragmataPro. It is now available for 19 euros (~$21). I bought the essential version for $70 back then.
I personally use it aliased. The font looks a little dense with anti-aliasing on. But I never liked anti-aliasing anyway, especially on low-dpi screens.
We see another pushing of 'the great programming font' from time to time. But rarely see innovations like special glyphs from multi-character tokens, +=, ++, /*. We see the same, boring, single rendering glyphs for parenthesis and brackets without regard to the depth level of parenthesis. You would think a more savvy font designer could do something eliding color and font rendering to produce a font the would help quickly understand code.
I find the idea interesting and would love to see more in this direction. It especially makes sense for languages with more obscure operators that are mimicking traditionally handwritten mathematical symbols.
That being said, I tried using FiraCode for a week and switched back. Some of the conventional common operators have become so ubiquitous and second nature to me that its difficult to adjust (especially the comparison operators). I'm still looking forward to more extended ligature fonts though.
I'm kinda late, I guess, but I thought I'd add my 4¢:
It's not experience, so much as accomodating the repetetivity of software development. Just like getting a better chair or a more comfortable keyboard, one day you find a font that strains your eyes and brain less than the last one, and you switch, and your eyes last longer.
Speaking of which, my absolute first reaction after I loaded that screenshot was "ouch, blur!" - to me, the combination of font, color scheme and antialiasing is making the text quite hard to read. Now, your eyes might be good enough to counteract that, and your screen might be lit differently from mine perhaps as well, making this reaction moot. On the other hand, if you look at some of the sharper screenshots in this thread (curl -s https://news.ycombinator.com/item?id=10140728 | grep -o '<a href="https\?://[^"]\+"' | sed $'s/^.\{9\}//;s/.$//;s/\//\//g;/imgur\|png/s/[^$]\+/\033[7m&\033[0m/'), and your eyes go "...oooh.", then you might be blind to the blurriness of your font. You might adjust this by changing the font, your editor color scheme, or learning about FreeType (ahaha) and how to adjust hinting.
All of this is just technical blathering though; I'm not questioning your choice of font for the choice's sake, or criticising it. I'm just saying, in case you don't realize, I thought it was blurry with my eyes, on my system. :P
As for actually going about making changes and adjustments, this is usually done in the traditional manner - spending an afternoon avoiding the todo list and for example getting horribly distracted with color scheme designers or font comparison utilities or text editor build systems... ;)
You grab a bunch of fonts, try all the monospace ones, find one you like, and go with it.
I use Liberation Mono everywhere. You might want to give Oxygen-Mono a shot just for kicks since its the "kde" font, but having used both I still like my Liberation.
Your font is fine. Use whatever you like. Main thing I look for is fonts that differentiate between things like 0Oo and lI1. I prefer open source fonts too. Just don't use a non-monospaced font.
You can get used to any font, and it is after all a matter of taste. I have preference but it's totally personal and might just be a habit. Whatever works, you know.
I'm on a spare (unconfigured) PC at the moment since my main systems were taken down for abrupt maintenance, but it's currently the default font I use in my terminals, text editor, etc. It looks a LOT softer than Fixed (the default X11 font)!
Nice font. I really appreciate that it supports non-latin alphabets. Even though it seems that these alphabets come from the original font (deja vu maybe?) and hasn't been much worked on, it still is extremely useful!
Some critic:
The small i seems a bit funny to me. It is like a greek iota (ι) with a dot on top. Also it is a bit tall font. Whilst that makes text/code more readable, on the same time it let you see less lines on your terminal. My main mono font (Liberation Mono), lets me see comfortably 51 lines in a full screen terminal on a 15.6" laptop. Hack font only shows 45 lines (11% less code :p) at an equally acceptable size.
This started quite a conversation, looking at the stats in Codeanywhere it seems at a first glance that Inconsolata is the most used (although true this is the default font). Will do a detailed analysis and report my findings :)
Thanks, I've seen that before, but it doesn't list Proggy Tiny, and just shows the characters in the font in a line and not how they'd appear in source code. It's hard to discern things like line height, compare the fonts at equivalent sizes, or see how they'd actually look in source code.
It also has anti-aliasing enabled on fonts that support it, which I personally hate. Proggy Tiny is designed to be pixel perfect at small sizes. MonteCarlo looked similar to Proggy Tiny, but when I typed MonteCarlo's example[1] into my editor and compared to Proggy Tiny[2] I really disliked it. That shows why you really need to see it with real source code in an editor at the same size.
Thanks for the link though, it's a good resource to see some of what's available!
This font does not work well at all in small font sizes, at least in Emacs. (ttf, linux mint, no font hinting)
At 4 & 5 point font sizes, there is a TON of whitespace around each character, destroying the text density and visible flow. Though it might be an Emacs rendering quirk as it never quite appears exactly the same as system fonts otherwise.
Liberation Mono is still works the best for me at those font sizes, still being legible and leaving enough pixels varying between similar characters to distinguish them.
On OSX put the ttf's into your ~/Library/Fonts directory. I've switched, Atom looks subtly different, but I'm surprisingly comfortable with it. Looks good.
While on the subject of fonts could an expert answer a question for me - on Windows (10 if it matters) should I install the ttf or the otf font? Is there a difference?
I like luculent, it's quite thin and you can stuff lots of texts in a small terminal, very useful if your laptop is small, and underscore is also thick.
I like the typeface, but I wish Hack had other weights; I find their normal weight far too heavy. I use Source Code Pro Extra Light (in Emacs and the terminal, on OS X) on my low-DPI display and it's pretty good.
I hate that 'i' glyph but otherwise looks nice. I'm more interested in editor's colorscheme in example though. Really nice, anyone has some information?
I really don't like the font personally, but you know, can't argue with taste. I'm curious though - you're using Geany for working with Go? What level of support does it have?
Geany doesn't support Go out of the box, but you can configure it to have excellent support. In the preferences, you can tell it the "go build" commands, and it will be able to build & run your project in Geany's integrated terminal and attach gdb for debugging. Also in the preferences you can tell it the format of go error messages, which allows it to highlight lines with compile errors.
Not much love here for Droid family it appears. Droid Sans Mono has been my go to monospace font for years now on different platforms. Ideal fonts are subjective, but this font is most comfortable to my eye on both shell and editors when antialiasing is turned on. Strangely enough I find Noto Sans which is derived from the same family less pleasing.
The O looks like a zero, but the 0 has a dot, and therefore doesn't look like an oh. That's not enough? I'm happy if every letter has a distinct form; they don't all need to differ from the common form though.
http://gfycat.com/SomberUnitedGermanshepherd