Using `make` and `git diff` for a simple and powerful test harness
1–10 of 48 posts
Re: Using `make` and `git diff` for a simple and powerful test harness
#2it's my friday, here's a haiku for you:
this is a nice post
i'm not sober on hn
fixed width code font pleaseRe: Using `make` and `git diff` for a simple and powerful test harness
#3it's my friday, here's a haiku for you: this is a nice post i'm not sober on hn fixed width code font please
The code font I use is Triplicate: https://mbtype.com/fonts/triplicate/
I use the Poly variant by default, only disabling it in places where the monospacedness matters for layout purposes, e.g. the terminal recording in this article (because of Vim), and Rust compiler output in some of my other articles. The Poly variant does things like make i, l and space a little narrower, and m a little wider, which makes casual reading more comfortable than a strict monospaced font.
I do this because I believe that monospacedness is substantially overrated in most places, and that most things actually look better not strictly monospaced. I contemplated not even using a monospace-style font at all but decided that was probably going too far for most people. (And as a Vim user I necessarily work in a monospaced text editor; but if it weren’t for that, I’d probably go full proportional.)
So I’m curious if you have further feedback on this matter and why you find fault with what I’m doing. It may influence what I do.
Re: Using `make` and `git diff` for a simple and powerful test harness
#4it's my friday, here's a haiku for you: this is a nice post i'm not sober on hn fixed width code font please
The code font I use is Triplicate: https://mbtype.com/fonts/triplicate/ I use the Poly variant by default, only disabling it in places where the monospacedness matters for layout purposes, e.g. the terminal recording in this article (because of Vim), and Rust compiler output in some of my other articles. The Poly variant does things like make i, l and space a little narrower, and m a little wider, which makes casual…
I second the mono space for code suggestion. I guess my brain is wired to see when characters are offset slightly as wrong. It’s a bit unsettling.
Re: Using `make` and `git diff` for a simple and powerful test harness
#5it's my friday, here's a haiku for you: this is a nice post i'm not sober on hn fixed width code font please
The code font I use is Triplicate: https://mbtype.com/fonts/triplicate/ I use the Poly variant by default, only disabling it in places where the monospacedness matters for layout purposes, e.g. the terminal recording in this article (because of Vim), and Rust compiler output in some of my other articles. The Poly variant does things like make i, l and space a little narrower, and m a little wider, which makes casual…
I think one of the best reasons to use a monospaced typeface is that it is a fairly strong and accurate signifier of code. Of course, in this case you have special highlighting for it that makes it less useful, but in general I think that it really helps. (Plus there are a couple of other, minor benefits probably not worth listing here.)
Re: Using `make` and `git diff` for a simple and powerful test harness
#6Earlier quoted context omitted.
The code font I use is Triplicate: https://mbtype.com/fonts/triplicate/ I use the Poly variant by default, only disabling it in places where the monospacedness matters for layout purposes, e.g. the terminal recording in this article (because of Vim), and Rust compiler output in some of my other articles. The Poly variant does things like make i, l and space a little narrower, and m a little wider, which makes casual…
I second the mono space for code suggestion. I guess my brain is wired to see when characters are offset slightly as wrong. It’s a bit unsettling.
To you and anyone else with this opinion: try disabling the `code { font-feature-settings: "ss01" 1, "ss02"; }` rule in the CSS, which will disable the Poly variant, and let me know how it feels.
It seems possible to me that it’s actually the use of a true serif monospace font (>95% of monospace fonts used these days are sans-serif, and >95% of the remainder are slab serif) that’s throwing you off, more than the strict monospacedness of it, and I’d like to try that hypothesis out.
(In early development of the visual style, I used only the font with no spacing or colour hints, but I found the monospace Triplicate too similar to the serif Equity, so that it was sometimes not quite clear enough that it was code; that was the reason why I put the background colour on inline code rather than only on code blocks, even though that wouldn’t be done in a printed manuscript, which is a style I am loosely imitating in part.)
Re: Using `make` and `git diff` for a simple and powerful test harness
#7Earlier quoted context omitted.
I second the mono space for code suggestion. I guess my brain is wired to see when characters are offset slightly as wrong. It’s a bit unsettling.
To you and anyone else with this opinion: try disabling the `code { font-feature-settings: "ss01" 1, "ss02"; }` rule in the CSS, which will disable the Poly variant, and let me know how it feels. It seems possible to me that it’s actually the use of a true serif monospace font (>95% of monospace fonts used these days are sans-serif, and >95% of the remainder are slab serif) that’s throwing you off, more than the stri…
In monospace that typeface looks glorious. I'd recommend continuing to use proportional for inline keywords, though.
Re: Using `make` and `git diff` for a simple and powerful test harness
#8I went to an awful lot of trouble to apply roughly the same technique to test some code generation code [0]. Required pulling in a random dependency and hacking around for a while to make the output look right. Your solution is much slicker!
[0]: https://github.com/couchand/wayfinder/blob/1dc58a1130bc17941...
Re: Using `make` and `git diff` for a simple and powerful test harness
#9Earlier quoted context omitted.
I second the mono space for code suggestion. I guess my brain is wired to see when characters are offset slightly as wrong. It’s a bit unsettling.
To you and anyone else with this opinion: try disabling the `code { font-feature-settings: "ss01" 1, "ss02"; }` rule in the CSS, which will disable the Poly variant, and let me know how it feels. It seems possible to me that it’s actually the use of a true serif monospace font (>95% of monospace fonts used these days are sans-serif, and >95% of the remainder are slab serif) that’s throwing you off, more than the stri…
I object to this whole thread as bikeshedding, however I happen to use proportional fonts for code (lucide sans unicode in windows) but just yesterday reverted back to a proportional font (lucida console).
While I much, much prefer proportional it's simply that indented stuff after text didn't line up properly in it eg.
stuff = 23
more stuff = 99
x = 41
(edit: sorry HN is messing up the indenting even further, but you know what I'm getting at)
Also my magit popup buffer is all ziggy-zaggy instead of properly column'ed. I can live with that. Edit - and git log which relies on fixed-width to show properly gets all bollixed.
In your case I can't see your code suffering at all from these problems, so I'm fine with it.
The niceness of proportionals may be enough for me to go back to it. I don't know yet.
Further edit: thanks for the article!
Re: Using `make` and `git diff` for a simple and powerful test harness
#10Earlier quoted context omitted.
To you and anyone else with this opinion: try disabling the `code { font-feature-settings: "ss01" 1, "ss02"; }` rule in the CSS, which will disable the Poly variant, and let me know how it feels. It seems possible to me that it’s actually the use of a true serif monospace font (>95% of monospace fonts used these days are sans-serif, and >95% of the remainder are slab serif) that’s throwing you off, more than the stri…
In monospace that typeface looks glorious. I'd recommend continuing to use proportional for inline keywords, though.
Interesting. I’ll give the thought time to settle and probably disable Poly for all code blocks tomorrow, leaving it on only for inline code. (That’s what I did initially in the design, but then I decided to make normal code blocks Poly as well because I preferred it so, and why not? —But it seems to be disconcerting people.)
Yet one of the things I really like about Poly is how it decreases width. Disabling Poly would slightly harm layout on https://chrismorgan.info/blog/rust-fizzbuzz/ where I have code side-by-side, increasing the width required for the full layout without wrapping from ~1500px to 1600px. Ah well. It’s not critical, just makes me a little bit sad. (Admittedly I could get much of that back with `tab-size: 3;` instead of `tab-size: 4`, but that would doubtless make people baulk too. And I’m not going `tab-size: 2` except on small displays.)