[broodbucket]

I wandered the internet for years looking for the perfect monospace font for me. There was never anything that fit; Ubuntu Mono was nice but a bit too "unprofessional", Liberation/Droid too boring, Microsoft/Apple fonts didn't fit either. I looked through so many font comparison sites, tried a whole bunch, just ended up sticking with the defaults.

Then I found Fira Mono. I use it everywhere. It looks great; it's very clear and easy to read, it has a nice style. Fonts are a very personal thing so thanks to Mozilla for finally letting me have one that was "mine".

[lomnakkus]

Another font which is very nice for code IMO is Fantasque[0,1]. It's a lot less "rigid" than most other monospace fonts, but after some use I actually found that it helps readability overall.

[0] http://openfontlibrary.org/en/font/fantasque-sans-mono

[1] https://github.com/belluzj/fantasque-sans

[sogen]

Wow, great find man, Fantastique!

[rhizome]

that looped lowercase-k is awful

[Svip]

Strange your list seems to be lacking DejaVu Mono. Just never came about it? Not that I dislike your final choice of Fira Mono. But I always thought DejaVu Mono was the best monospaced typeface out there for years.

[joosters]

Same here, DejaVu Mono in my terminal. Just tried the Fira Mono and it is OK but the line spacing seems far too big for my taste.

[noir_lord]

on xfce4-term the linespacing looks about 1.5 compared to Droid sans Mono.

Costs to many lines on screen, nice font though.

[middleclick]

I have the same issue. A sad thing, the font looks good but the line spacing is way too much for my taste.

[georgevreilly]

Download Fira Mono OT from https://bugzilla.mozilla.org/show_bug.cgi?id=897009#c64, and you'll get 30% more lines.

[broodbucket]

It didn't come to mind but I do like DejaVu, just not a huge amount. It was typically the pick of the pre-installed for sure.

[hornetblack]

I'm still comparing Fira Mono and Source Code Pro. They are both very nice.

https://github.com/adobe/source-code-pro

[temporary_art]

I'm a huge fan of Anonymous Pro... If you want to compare with something else.

http://www.marksimonson.com/fonts/view/anonymous-pro

[Demiurge]

Source Code Pro Light is the only code/terminal font I can use on OSX without being mad about the fatty rendering! It's perfect!

[buddystiff]

You could only truly compare Source Code Pro if the designer made Fira Sans Mono. I wonder if he has?

That'd fix the lowercase r problem, I would think.

[Monkeyget]

Fira Mono takes an awful lot of vertical space. To me it looks like inconsolata but less legible due to extra serif.

[alxndr]

After reading a few shell scripts in Fira Mono, I find the serif on the lowercase "r" very distracting compared to Inconsolata. The lowercase "i" too, even though it looks very similar to Inconsolata's lowercase "i".

Also, for some reason I find the dot in the number "0" to be more distracting than using a slash to distinguish it from an uppercase "O".

[buddystiff]

I kinda like it. It forces a comfortable min line height that makes it very readable. However, upon further investigation it breaks readability of text in menus/lists that have max height shorter than the expected standard fonts line height. Hence cutting off the text... huge bummer. Oh well, back to uncomfortably dense fonts :(

[seanmcdirmid]

Go proportionally spaced fonts for code and don't look back.

[baddox]

I'm not against that at all, but it doesn't really work when you're on a shared codebase with people who use spaces to align things based on the assumption of fixed-width fonts. Things like:

    hash[:foo]   = 5
    hash[:sdfkd] = "x"
    hash[:x]     = "y"

Of course, I'm against doing this anyway, because it causes issues when you want to add an even longer key to the hash.

[profsnuggles]

If you are using a decent text editor it's easy to keep things aligned. Emacs for example m-x align-regexp = will do the trick. I would assume vim, etc have similar options.

[subsection1h]

> it causes issues when you want to add an even longer key to the hash

What issues? Needing to realign the values? If so, does your text editor not include alignment commands like these:

http://www.emacswiki.org/emacs/AlignCommands

[nitrogen]

Realigning the values causes all of the lines to change in a line-by-line diff (e.g. as displayed by git diff). It also makes "git blame" less helpful, since every realigned line appears to originate from the alignment commit.

[e12e]

I agree -- but I'd think the work-around would be to do whitespace-insensitvie diffs? Which would probably be a good idea if the codebase uses indentation like this?

See eg: https://stackoverflow.com/questions/7310033/how-to-make-git-...

[jacobparker]

`git blame -w` to ignore whitespace. There are other good options (like `-M`, ignore moved lines) available in the documentation.

[alxndr]

I really wish GitHub would show me all diffs with `-w` by default, with a switch to turn it off...

[skelsey]

This is what tabs are for.

[Silhouette]

Elastic tabstops[1] are one of those things I wish was standard in the programming world, because it seems to have essentially no downside as long as tools support it.

Failing that, many text editors will provide some sort of realign command that will adjust spaces on adjacent lines so the columns line up as intended in these situations, and many diff tools and related functions like 'blame' commands in VCSes will allow you to ignore whitespace-only changes these days.

Personally, I prefer to have non-trivial code neatly lined up, despite the potential irritations when reviewing changes later. I find the advantages of highlighting patterns (and highlighting where a line didn't follow the same pattern as all the others) outweigh any practical issues where a few tools show diffs I would prefer to ignore.

I make an exception for Python, because PEP8 explicitly advises not to do this, and sometimes having a coding style that is consistent with everyone else is worth more than any of the above.

[1] http://nickgravgaard.com/elastictabstops/

[espadrine]

This algorithm sounds like it has a dreadful worst-case complexity. It can have to parse the whole file to give the intended result (eg. in the case of a dense table, when deleting a character at the end of the longest cell of a column).

It also has terrible partial results. For instance, removing the tab after `cell-missing` in the example triggers a weird alignment.

That is too bad, since the idea is bright.

PS. This is off-topic, but I cannot create a new thread on it, since it was submitted to HN six years ago and that old thread is locked: https://news.ycombinator.com/item?id=333626

[Silhouette]

FWIW, it's not that particular implementation that I'm in favour of. As you say, it has some issues.

Also, while the page I linked to was the first time I saw anyone offer a convenient name and write-up to cite, I should acknowledge that there had been discussions about using tab widths that varied by context long before that page was written. Many editors have provided related functionality where hitting tab once would automatically align your code blocks, function parameters, etc.

I suspect that for anything closer to the specific elastic tabstops idea I cited to become established, we'd need a distinct character rather than reusing ASCII spaces and tabs. This could work rather like the way various typesetting systems and DTP packages have "align to here" markers that don't necessarily introduce any extra horizontal space themselves but do indicate that consistency should be enforced across related lines.

I personally think that a standardised character like that and support for it in tools like editors and diff displays could bring several modest benefits: aside from the immediate convenience of aligning code more neatly if that's helpful, it could actually clean up a lot of whitespace-based diffs that tend to confuse tools today without necessarily having to ignore all whitespace, and of course it would improve the usefulness of proportional fonts when reading code, which I think is where we came in.

[baddox]

Would you use that in the example I gave, in the middle of the line of code? I don't quite see how that would work.

[subsection1h]

Do you create a new spreadsheet using a spreadsheet app every time your notes include tabular data? I ask because a proportional font would be incompatible with the table/spreadsheet syntax of every lightweight markup language I've used. I would hate to have to create a new spreadsheet using Excel every time I have new tabular data for my Org-mode-powered personal wiki rather than simply use Org mode's spreadsheet syntax.

[seanmcdirmid]

I use proportional fonts for my latex editor, and have always been able to align my tables well enough in .tex files. Of course, latex output has no problem aligning table columns without using a fixed width font.

Doesn't everyone use latex for note taking?

[grayclhn]

Lots of use use something that can export to latex :)

[e12e]

I tend to agree, I use monospaced fonts -- however -- what's wrong with tabs? Surely if you're using variable width fonts, you could pair them with tabs?

[ANTSANTS]

Let me know how that works for you if you ever write Lisp, Haskell, or have to deal with someone who thought they could make their $ALGOL_INSPIRED_LANGUAGE look cute by aligning everything into tables.

[seanmcdirmid]

Mono space is a type writer anachronism. Lisp was designed in hype 60s and not many people write code in it; Haskell could benefit from better mathematical typesetting.

I've heard that going proportional would be bad, but I made the switch and have noticed yet any badly formatted third party code (I mostly use C#).

[rtpg]

Haskell, despite how people talk about it, isn't necessarily that heavy symbol-wise. Table-based aligning makes haskell code look very good (esp. when dealing with a lot of pattern matching)

[seanmcdirmid]

Haskell just looks horrible when set in ASCII at all; where did they come up with \ for lambda? It would definitely benefit aesthetically from at least more Greek use.

[Someone]

It's two thirds of a lowercase lambda: λ vs \

[edwintorok]

Are you using a serif font? Because sans-serif is very bad when it comes to representing source code: the characters 1lI and 0O all look alike. For example Pidgin's choice of a sans-serif font always caused me troubles, had to either switch the font, or the system-wide sans-serif font to something where I can tell the difference.

[seanmcdirmid]

Segoe UI. Honestly, I knew this would be a problem but I haven't had this problem yet. The most annoying thing is that subtraction (-) is too short in relation to addition (+).

[Silhouette]

In my ideal world, code would be typeset in proportional fonts, with mathematically appropriate glyphs chosen from a font with a comprehensive Unicode character set, including a proper minus instead of hyphen-minus.

The usual problems with this are arranging indentations/alignments neatly where you really do want them and avoiding an explosion of funny characters once you've got a large part of the Unicode character set to play with. Tools are pretty good at the first these days, but pity the poor Haskell developers if we don't fix the second. People will be writing logging libraries that use different levels of emoticon to save writing 'debug' and 'error'...

[lygaret]

Totally agree. I _really_ wish there was an italic variant; that would pretty much guarantee it'd be the only monospace I use again.

[cmyr]

I'm a big big fan of Bistream Vera Sans Mono. It walks the line between being humane and being rigorous quite well, in my opinion. http://en.wikipedia.org/wiki/Bitstream_Vera

[Zardoz84]

Do you try Hermit font ? Made by a programer for programers.

[calinet6]

Monaco has always been excellent for me.