151–160 of 174 posts
This is the first time I've heard of iA Writer, it looks like exactly what I need right now for nanowrimo... focused on writing prose with some minimal feedback tools. Going to give it a shot!
Not sure if it's the font, the colors, the kerning, or my browser, but this website hurts my eyes!
Earlier quoted context omitted.
tab stops is still available in terminals. Tab in terminal move the cursor to next x*8(depends on setting) position independent of what character you input before. But a major flaw is that it only works when your cell has less than 8 characters. Or it will go to the wrong stop. Which isn't that common today. Because why insist in short names and 80 width character limit? Almost everyone have a screen that can fit hun…
> Because why insist in short names and 80 width character limit? Almost everyone have a screen that can fit hundreds of characters per line today. Yet, books don't work that way, even though we have the technology. Long lines aren't readable. There's a reason newspapers have columns. See eg https://baymard.com/blog/line-length-readability and https://en.wikipedia.org/wiki/Line_length
Earlier quoted context omitted.
Formatting your code in an unintuitive way because of the font is a code smell to me.
Viewing the examples generally, the second one better communicates hierarchy at the cost of an extra line. The arguments are all grouped together visually and without distraction, while in the first example the first argument gets muddled with the function name. Why? To save a line break?
func(arg1, arg2, arg3)
The argument is already being muddled with the function in the same way.
These conventions are seen in the wild:
func (arg1, arg2, arg3)
func( arg1, arg2, arg3 )
(func arg1 arg2 arg3)
Earlier quoted context omitted.
I do something similar also with if() and others: if (condition... && condition... && condition... ) {
Same here but pushed it to force same column condition statement: if (( condition1 ) && ( condition2 ) && ( ... )) {
Earlier quoted context omitted.
> I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this: [item1 ,item2 ,item3 ,item4 ] instead of a sane way. It means adding or removing an element only changes o…
Leading comma is better at resolving textual 3-way merges, e.g.: [ a [ a [ a , b , b / , b , c --> , c / , c , d , d / , dd ] , e ] ] Your usual 3 way merge algorithm will correctly deduce: [ a , b , c , dd , e ] Contrast this with trailing comma: [ a, [ a, [ a, b, b, / b, c, --> c, / c, d d, / dd ] e ] ] You now have a merge conflict between "d," and "dd". However, if you were to require a trailing comma after the f…
Example doesn't have a trailing comma. If it did, it would act the same as the leading comma.
But also the leading comma just moves the problem to the beginning of the list instead of the end. Trailing comma with the opening [ on its own line wouldn't have that problem anywhere.
Isn't the whole point of monospaced fonts columnar alignment (e.g. the table in the article)? Seems like "almost" defeats the point. Then again, I don't see values lined up much these days: { "someKey": "someValue", "someOtherKey:" "someOtherValue, and if you only care about leading whitespace (that is, the whitespace before a character appears on the line), maybe it doesn't matter how your font is spaced. I suspect…
Earlier quoted context omitted.
Unfortunately applying both Poly and Code gives you an imperfect result: the default l glyph has a flat base, Poly makes it narrower, and Code makes it a curly tail, but enable both (e.g. font-feature-settings: "ss01", "ss02") and you get the Poly glyph rather than the Code glyph or a hybrid, both of which would be nicer, and MB has said “won’t fix” (and I haven’t gone to the trouble of patching it myself). A demo of…
I'd never actually tried to enable both at once, but I'm not surprised it doesn't work. I love writing prose with Triplicate Poly, but I code with monospaced fonts, as neither most code editors nor most codebases seem to work that well with proportional fonts.
Earlier quoted context omitted.
The value of alignment (at least for me) is not in making the text of the code more readable. Instead, the value is communicating the structure of the code. Seeing the same shape repeatedly tells me a lot about what is happening. It also helps highlight changes between two lines that are very similar.
> the value is communicating the structure of the code. I agree and I think that is the same thing as code-readability. Code-readability means you can easily understand the code. I personally try to abide by what I call "hedge" formatting convention, the punctuation forms a vertical hedge which then shows the structure of your code clearly: [ a , b , c ] Moving my eyes down to look for the closing bracket is easier (…
[
, a
, b
, c
]
[
- a
- b
- c
]Another reason for using almost monospace: international languages. Many indic languages simply don't have good monospace fonts. It's not easy to design. They stick out in code, as a result. But I've always wondered if allowing three or four different widths would help. We could still align text if (narrow) spaces were the smallest unit, and other widths were repeated multiples of that. This makes me think it's doabl…
Same goes for East Asian languages which are monospaced, but square. If you mix English (or code) with Chinese/Japanese/Korean, you get a mixed-width mess.