Live data from Hacker News

Write thin to write fast

breckyunits.com

91–100 of 146 posts

Re: Write thin to write fast

#91
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 innerIf you adhere to these very simple principles, you will have avoided like 95% of the typographic choices that can make texts hard or slow to read.

Re: Write thin to write fast

#92

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?

Sublime Text has a Distraction Free Mode which goes to full screen, removes all GUI and centers the buffer contents on the screen.

It’ll use your buffer settings so if you’ve configured Markdown to only be 60 characters wide, it’ll look like the photo in the article.

Re: Write thin to write fast

#93
post #32

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…

I wonder if this is something analogous to Parkinson's law. I have found that transitioning to a single screen was initially frustrating, but it forced me to adapt to the lack of space by condensing my writing, both code and prose.

It seems intuitively convincing and almost obvious to me that the quality of your output would be inversely proportional to the amount of available "space" for that output, although the exact relationship doesn't seem so clear.

Re: Write thin to write fast

#94

Really interested to try this out. I crank out between 5 and 15 content pieces each week (blog posts, ebooks, white papers) and am constantly looking for ways to optimize my workflow. It has never occurred to me to modify column width to get a "jump start" on the editing process. Excited to futz around with this tomorrow.

Any tips for someone who is struggling to get barely 1 piece done per week?

Re: Write thin to write fast

#95

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?

Re: Write thin to write fast

#96

It would be cool if you could automatically do this in a browser, by essentially telling the browser to render a very long screen and then split it into however many columns fit on your screen (imagine taking a screenshot of your window, going down a page, taking another screenshot, and so on, and then putting these screenshots side by side). Questions: - Are there Ebook readers that can show many pages at once? - Ca…

Hi,

In Emacs, it is possible by using "follow-mode":

Open a "large" file.

M-x follow-mode

C-x 3 ;; to split vertically

And adjust splits width as many times needed.

I usually use 3 splits with "visual-line-mode" enabled.

Re: Write thin to write fast

#97

This seems to be kind of a complex topic, with a number of variables. Here is a study: How physical text layout affects reading from screen https://www.researchgate.net/publication/220208446_How_physi... A quote from the Discussion section: "Most of the studies on line length report faster reading with longer lines, and point to the number of characters as the variable responsible for the differences, rather than phy…

The paper focuses more on reading. OP focuses on editing.

Both are very different mindset. The second is supposed to make the first enjoyable and fluid. When editing you need to keep the reading location (kinda “cursor”) and move back to some sentences to test the “fluidness” of the flow. When reading, you don't need to do this anymore. I suspect OP prefers short line length to avoid the cognitive load implied by “finding” words back and forth during the editing step.

Re: Write thin to write fast

#98
General rule of thumb that works for me: the number of characters should roughly match the number of handwritten characters that fit onto a normal letter page. For me, that is between 50 and 70 characters. This also roughly matches the number of letters in the standard manuscript format [0] used by the publishing industry for literary works.

[0] https://en.wikipedia.org/wiki/Standard_manuscript_format

Re: Write thin to write fast

#99

It would be cool if you could automatically do this in a browser, by essentially telling the browser to render a very long screen and then split it into however many columns fit on your screen (imagine taking a screenshot of your window, going down a page, taking another screenshot, and so on, and then putting these screenshots side by side). Questions: - Are there Ebook readers that can show many pages at once? - Ca…

VsCode: a single thin column is possible: turn on Zen Mode, word Wrap, and slide the bar for a thin editor.

Re: Write thin to write fast

#100
post #79

Earlier quoted context omitted.

I see some coworkers with ridiculous setups. Three monitors, one vertical, one ultrawide and curved. I don't see why you need that much screen to write code... when pressed they say it's for having references, Slack, etc. up on other screens but then you just end up moving your head around a lot (what a pain in the neck!) I do everything on a single 27" monitor.

> but then you just end up moving your head around a lot (what a pain in the neck!) If moving your head causes you neck pain, you should get that looked after ASAP! Generally, a static posture over a long time is really bad for your health. Make sure to stretch, fidget, move around, change your posture a lot when working with a screen.

Sounds like hyperbole, but i do feel like i loose track and some situation awareness when i use a 34" super-widescreen
Post reply on HN