101–110 of 146 posts
I do this sort of thing quite often, more often than not: my $foo = GetFoo(); my $bar = GetBar($foo); my $baz = GetBaz($bar); As opposed to this: my $baz = GetBaz(GetBar(GetFoo())); It takes a smidgen longer to write, but is much easier to read and understand when I'm looking at it 2 days later.
my $baz = GetFoo()
|> GetBar
|> GetBaz;A vast majority on book typography agrees on 66 characters per line in one-column layouts and 45 characters per line in multi-column layouts as being the optimal numbers for reading. The text-block should also be placed assymetrically on the page, with the margins in size order being inner If you adhere to these very simple principles, you will have avoided like 95% of the typographic choices that can make texts hard…
Surprised no mention of distraction free mode, sometimes called Hemingway mode: everything except the current sentence is faded out. Actually how I do most of my bulk writing.
Where do you find and use this mode?
On a related note: At one point I switched to working exclusively on a laptop and after a while realized that the smaller screen had forced me to write better code. I wrote smaller methods, made smaller files, kept my concepts together, the whole nine yards. I even wrote better tests since that helped me keep my work small. It didn't last; I'm writing this on a 27" monitor, but I think that has more to do with bad la…
Then again, limiting the line width to something like 120 characters should allow you to edit two files side by side simultaneously, or run into far less problems when using something like a laptop, as opposed to having large monitors, while also help people who prefer larger font sizes, so it should be better for accessibility as well.
I currently have about 4 monitors in total, 3 of which are 21.5" at 1080p and there's also one vertical one, which to me that seems like a pretty decent setup - being able to browse code, work in a terminal, preview things in the browser and maybe get a few filesystem windows in there as well seems to improve productivity, all without the tradeoffs that tiling window managers might incur (though mostly just the learning curve) or struggling with software that doesn't work well with less horizontal space.
Of course, the technicalities of getting such a setup working are a bit cumbersome too - i cannot afford one of the fancy VESA mounts, so instead two of the monitors use a DIY monitor leg that's basically one long PVC pipe with some 3D printed mounts and screws, another sits atop of the computer case to the side and the GPU I/O is kind of a mess, since there's occasionally an adapter in there as well (monitors with DisplayPort are more expensive, rather than VGA/DVI/HDMI).
Honestly, it'd be nice to sidestep all of that with something like VR, but we're not quite there yet in regards to the resolution, or may never really get there at a good price point, even if there are some really interesting projects out there: https://arcan-fe.com/2018/03/29/safespaces-an-open-source-vr...
Virtual workspaces (basically multiple desktops) might help mitigate some of the issues, though!
(That being said, code is different than text in that line length varies greatly and it generally looks less uniform than a block of prose. So maybe 100 chars per line is fine here.)
Interesting take. On hackernews I also learned about an approach called "ventilated prose" or writing with "semantic line breaks." That is, when you write, say in vim or emacs, you put one clause per line. Then when you are done, you can use pandoc or something similar to convert what you wrote into standard prose. But the artificial line breaks, which results in thin lines, make it easier to edit, and also easier to…
I find the line break to be semantical important! So it is different if there is or if there is not a line break. How do you manage it? Double line break?
But an empty space in between indicates a new paragraph.
If for some reason you require to have separate lines, perhaps when enumerating something, you can leave two trailing spaces after the line, that preserves the break.
Earlier quoted context omitted.
I find the line break to be semantical important! So it is different if there is or if there is not a line break. How do you manage it? Double line break?
Pandoc ignores single line breaks when exporting markdown. So all of this would be treated as a single sentence. But an empty space in between indicates a new paragraph. If for some reason you require to have separate lines, perhaps when enumerating something, you can leave two trailing spaces after the line, that preserves the break.
``` Pandoc ignores single line breaks when exporting pandoc. So all of this would be treated as a single sentence [sic, I wanted to write "line"]. ```
Earlier quoted context omitted.
I find the line break to be semantical important! So it is different if there is or if there is not a line break. How do you manage it? Double line break?
Pandoc ignores single line breaks when exporting markdown. So all of this would be treated as a single sentence. But an empty space in between indicates a new paragraph. If for some reason you require to have separate lines, perhaps when enumerating something, you can leave two trailing spaces after the line, that preserves the break.