For some reasons, I've found that good, old, Verdana (as used on this very HN) is the most editor/writer friendly. IMHO of course.
I fully agree, but sadly its character set is rather limited in terms of Unicode characters.
Almost monospaced: the perfect fonts for writing
161–170 of 174 posts
Re: Almost monospaced: the perfect fonts for writing
#162Earlier quoted context omitted.
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.
It’s well-defined, at least in the terminal: the east-asian characters are simply double the normal width. There’s a Unicode property to decide which is which: https://www.unicode.org/reports/tr11-2/
I was saying something else. If you mix latin text and Chinese text in a monospaced font, the character boundaries no longer line up.
Re: Almost monospaced: the perfect fonts for writing
#163Earlier quoted context omitted.
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?
The canonical notation is like this: func(arg1, arg2, arg3) the first example splits it across multiple lines in a way which maximally preserves the other aspects of the notation. The argument is already being muddled with the function in the same way. These conventions are seen in the wild: func (arg1, arg2, arg3) and func( arg1, arg2, arg3 ) The real fix for that muddling is to drop the commas, and move the parenth…
> the first example splits it across multiple lines in a way which maximally preserves the other aspects of the notation.
Once you’re splitting it across lines I don’t think that is a desirable attribute. Better to use a format that suits multiple lines than attempt to match as closely as possible to a format intended for one line. Like those “flying cars” that try to look like the “canonical” car.
From my perspective this is a UI problem (though not a serious one).
Re: Almost monospaced: the perfect fonts for writing
#164This 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!
My first time seeing it too, it really does look appealing! I am using Scrivener's very generous Nano demo this year ( https://www.literatureandlatte.com/nanowrimo ). Free from Oct 15 - Dec 7, and at the end of that you get a 50% discount if you hit 50k words, which is pretty cool. So anyway, I've got my outline and stuff all in Scrivener but maybe I'll try iA next year, or for some other markdown writing work. It ki…
Two years ago, I did nanowrimo in Vim with a whole suite of plugins:
- https://github.com/preservim/vim-pencil
- https://github.com/junegunn/goyo.vim.git
- https://github.com/junegunn/limelight.vim.git
- https://github.com/vimwiki/vimwiki
It was fun, and the setup is almost identical to iA Writer which I appreciate. I even had it all on my phone with Termux!
Last year I just did it in Markdown in VSCode in "zen mode" which also worked pretty well. It was definitely easier to setup than Vim and had better highlighting of bold/italics/etc.
Re: Almost monospaced: the perfect fonts for writing
#165Earlier quoted context omitted.
It’s well-defined, at least in the terminal: the east-asian characters are simply double the normal width. There’s a Unicode property to decide which is which: https://www.unicode.org/reports/tr11-2/
I was saying something else. If you mix latin text and Chinese text in a monospaced font, the character boundaries no longer line up.
They still line up (when rendered with correct double-width), the east-asian characters just take up two “slots”, as if they were two normal characters. I don’t know if you see a problem with that, or if you’re talking about renderers and/or applications that don’t correctly handle this double-width logic.
My point is that if handled correctly, e.g. in terminals, there is no problem with that, as long as the application is double-width aware. For example I use Mutt as a mail reader in a terminal, with Vim as an editor, and mixed latin and east-asian characters work fine with them and line up on the terminal grid.
Re: Almost monospaced: the perfect fonts for writing
#166Earlier quoted context omitted.
> 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 (…
Languages should allow for leading commas to enable the more uniform: [ , a , b , c ] Depending on the rest of the language syntax, it could also be nice to have a markdown-style list syntax: [ - a - b - c ]
In JavaScript a leading comma in an array would create a first element whose value is undefined, I believe.
Re: Almost monospaced: the perfect fonts for writing
#167See also: a little bit pregnant, almost alive, and close but no cigar. Yes, I read the article to the end. No, I don’t get it. Either they line up or they don’t. Either it’s monospace or it’s not.
Within the fonts that aren't monospace, some fonts have less variation in glyph width than others. It's a spectrum. You can choose a font that is mostly monospace, but not completely, to confer benefits for readability. If all you're saying is that you personally don't care to make a finer distinction than monospace/proportional, that's fine, but it's probably not worth commenting on either.
There is nothing that says monospaced fonts are more readable. In fact, they’re probably not since you can’t give neither whitespace nor character components like the ascenders/descenders/bowls/stem/etc the space they need to shine relative to each other.
Monospace has one and only one redeeming quality that makes it worth using over proportional fonts: it lines up.
Re: Almost monospaced: the perfect fonts for writing
#168Earlier quoted context omitted.
Languages should allow for leading commas to enable the more uniform: [ , a , b , c ] Depending on the rest of the language syntax, it could also be nice to have a markdown-style list syntax: [ - a - b - c ]
In JavaScript a leading comma in an array would create a first element whose value is undefined, I believe.
What a stupid design. If the consortium had just one member having the competence of knowing some competing design and using his brain for five minutes, this disaster could have been avoided.
Re: Almost monospaced: the perfect fonts for writing
#169Earlier quoted context omitted.
In JavaScript a leading comma in an array would create a first element whose value is undefined, I believe.
What a stupid design. If the consortium had just one member having the competence of knowing some competing design and using his brain for five minutes, this disaster could have been avoided. https://news.ycombinator.com/item?id=9624429
Well, JavaScript is pretty much a lost cause anyway.
Re: Almost monospaced: the perfect fonts for writing
#170Earlier quoted context omitted.
I was saying something else. If you mix latin text and Chinese text in a monospaced font, the character boundaries no longer line up.
They still line up (when rendered with correct double-width), the east-asian characters just take up two “slots”, as if they were two normal characters. I don’t know if you see a problem with that, or if you’re talking about renderers and/or applications that don’t correctly handle this double-width logic. My point is that if handled correctly, e.g. in terminals, there is no problem with that, as long as the applicat…
I don't think I've ever seen a double-width font outside of an actual terminal emulator though. It's really frustrating that the fonts used by all IDE's and graphical emacs/gvim/vcode seems have this mixed script spacing issue.