Write thin to write fast | Hacker News Reader

Write thin to write fast

breckyunits.com

305 pointsbreck140 comments

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 physical line length (visual angle)."

The OP thinks that humans read thinner columns faster. Generally, this seems not to be the case, so maybe we should treat his main conclusion with some skepticism. In any case, it's probably best to refer to the scientific literature.

It's helpful to link the research here. Thanks.

I do wonder if scanning is different from sequential reading. When reading code, I'm most often looking for the right place to change or add something.

> The OP thinks that humans read thinner columns faster. Generally, this seems not to be the case, so maybe we should treat his main conclusion with some skepticism.

> In any case, it's probably best to refer to the scientific literature.

You might not think so if you read the literature review which takes up most of that paper. The literature covered is generally focused on questions of no obvious interest and then, even in its own terms, finds little or no effect. Particularly funny is the paper (Youngman and Scharff (1998), covered in §2.7) comparing the independent effect of physical line length vs physical margin length. Or in other words, they investigated whether it's faster to (1) read six inches of text with half an inch of blank page to the right of the text, or to (2) read six inches of text with a full inch of blank page to the right of the text.

The paper you cite also goes out of its way to express the authors' dismay over the extreme nature of one experiment invalidating the finding they wish to support:

> The study also fails to replicate [the finding of] Dyson and Kipping (1998a) and earlier studies that more characters per line can result in faster reading. The difference may be due to the extreme nature of the longest line, i.e. 132 characters in 12 point Arial (rather than 10 point Arial used by Dyson and Kipping). The line length therefore not only has more characters but is also physically longer because of the larger type size.

later:

> A setting with no margin would not be typical practice, but may have been included to assess an extreme of a variable in a similar manner to using 132 characters per line.

How unfair!

Of course, as I read your comment on Hacker News, it contains a line of 130 characters.

This paper isn't even trying to address the questions you think it's addressing.

Your points help with discounting the claim that long lines read faster. But that does not say anything about OP's claim that short lines are better.

I'm not convinced by OP's argument "New York Times does it": pretty much any book does the opposite.

Perhaps we need more/better research.

For what it's worth, I set my screen to be very wide when I write because I like to write each sentence on a single line: it allows me to easily spot sentences that are too long, a mistake I often make.

Your points help with discounting the claim that long lines read faster. But that does not say anything about OP's claim that short lines are better.

Yes, that's true. I was not trying to dispute or support OP's claim that short lines are better. I was trying to dispute my immediate parent's claim that the way to handle questions like this is to refer to the scientific literature.

> The OP thinks that humans read thinner columns faster.

Tbf, "reading faster" in the linear sense is probably not exactly the metric to use when writing text. When writing, I usually need to jump randomly a lot in the text to cross reference something (from the last paragraph, the last sentence, or the beginning of the current sentence). It's a kind of nonlinear scanning that I'm guessing could be more efficient in narrow column text, even if wider columns would be faster to read from beginning to end.

On HN, your line here is 200 characters in 9pth Verdana, so it's also pretty extreme (perhaps because I have a wider screen). Personally I find the max line length on HN really uncomfortable.

> nature of the longest line, i.e. 132 characters in 12 point Arial (rather than 10 point Arial used by Dyson and Kipping). The line length therefore not only has more characters but is also physically longer because of the larger type size.

I'd say anywhere from 50-100 characters is fine for line length, stray too far outside that and you're not allowing enough words to scan well, or have too many so that it's hard to jump to the next line.

> On HN, your line here is 200 characters in 9pth Verdana, so it's also pretty extreme (perhaps because I have a wider screen).

I'm actually doing two things to shorten the line width as measured in characters. #1, my browser window is set to a size I find reasonable, not fullscreen. #2, I have HN configured at "110% zoom" (not sure precisely what that means, but it's how Firefox reports it), which makes the text larger and therefore allows fewer characters per line.

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.

> The OP thinks that humans read thinner columns faster. Generally, this seems not to be the case

Really? This is absolutely the case for me. I use "reader view" / "readability" in Firefox whenever possible and it's incredibly helpful.

Thinner columns allow for more of a "Z" pattern of reading, where you can kind of scan-read backwards when your eye scans back to the left, as opposed to the standard "E" style of reading of reading an entire line, returning to the left, then moving to the next and repeating.

Writing in thin columns allows you to keep an eye on what you just wrote more easily as well.

I find this to be super important for noticing when my writing is getting repetitive; when I'm reading in that "Z pattern," it's easier to pick up repeated words or phrases in the last few lines of text.

This loosely reminds me of the way the pages of Cornell Notes are structured. I wonder if it has anything to do with that.

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<top<outer<bottom. The line height should be set at 120% of the highest character hight for normal book typefaces, but should be increased for typewriter typefaces and can be decreased slightly with shorter lines. A small set of typefaces are economic without losing readability, and if you use them you can increase these numbers slightly. But any more than 80 characters and anything less than 40 characters is suboptimal for texts that are longer than a paragraph or so.

If 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.

This. Art of typography. I stick to this a lot. Major problem here: A lot of corporate templates suck and changing them is pita or impossible due to non negotiable guidelines.

Robert Bringhurst in "The Elements of Typographic Style" (a bible for this kind of thing, and one of the most beautiful books ever made), has this to say on the topic:

"Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple-column work, a better average is 40 to 50 characters.

If the type is well set and printed, lines of 85 or 90 characters will pose no problem in discontinuous texts, such as bibliographies, or, with generous leading, in footnotes. But even with generous leading, a line that averages more than 75 or 80 characters is likely to be too long for continuous reading."

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 laptop ergonomics than space.

You can make the things on screen bigger on the 27” to match laptop.

Better yet - tile things on the monitor.

I'm on a 32" and I don't full screen anything except for the odd video.

> 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.

Interesting. The programmer equivalent of using smaller plates so you eat less at meals.

The IDE I use has a line set at whatever your acceptable line length is. I find that's usually enough to keep me in line (ba-dum-tss)

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.

It's almost as if people have different preferences in working environment, isn't it?

I used to prefer dual 24" monitors. I felt the physical separation let me better organize my tools.

Now I prefer my 34" widescreen. More flexible, less distracting.

I'm writing an operating system, its build system, a verifier for it, and writing docs, usually switching often between them. I wish I had that much screen space.

Everyone has their own workflows.

> 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

Hahaha very good point :)

I understand you, I also use one primary monitor in front of me. I have another monitor next to it, which I mostly use to put documentation next to the IDE. But the second monitor ist 90% of the time unused. Sometimes I put tool windows (test runner) there. Or something entertaining (YouTube/Netflix) ;)

I love coding on a huge 40 inch screen: the main reason is that I can view an entire file without scrolling. Less mental overhead to move your hands means more brainpower is left to do useful work.

Did you see the post the other day about using a thin editor with very few columns?

https://news.ycombinator.com/item?id=29166673

It really got me thinking about monitor setups and how much space you _really_ need to write code.

Yeah, I read that one. As others in that thread point out there is research that actually shows long lines are better (with yet others in that thread questioning that research, but alas, it's certainly not a given shorter is better)

It depends on the type of work. For people who code like they're writing a novel, yeah, a laptop can be perfect and encourage focus. But for anyone who works with real-time financial data, working on a laptop screen would be a nightmare.

Split your screen.

I never write code in a full screen window. Either code on two sides or a terminal on one side, etc.

Long horizontal lines really mess with comprehension and attention.

I typically go 13" laptop, but when docked on a 4k screen, I use screen splits to achieve a similar effect.

I push back on the mantra that smaller methods are always better.

Yes, they usually have less responsibility, by virtue of being smaller. However, sometimes it is best to just get a larger task done in a function. You can have parts of it logically called out, without having to use the languages features for function declaration.

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.

I feel like there is probably something to be said about how well particular languages work with less horizontal space - the more verbose ones out there might lead to code that is so long vertically, that a lot of time will be spent scrolling through it, unless you're using a vertical monitor for that.

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!

Core hypothesis: "Thinner columns help you read faster. Writing speed is dominated by reading speed. If you read faster, you write faster."

If you have done any typesetting, say for a book, you'd realize that there is a sweet spot between the font size and the number of characters in a line. This has changed little over the hundreds of years. I think some of that effect is what we're seeing on the screen here in this post. There is a lower limit though, if you set the line too small, you'll be scrolling very often as the other comments have pointed out.

https://baymard.com/blog/line-length-readability

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 comprehend diffs if you use git to track changes.

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.

Oh, even hackernews ignores single line breaks. I wrote this coment like this:

``` 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"]. ```

huh... sorry, I don't know how to use hacker news to show you what I mean... it keeps squishing my lines.

Instead of leaving two trailing spaces, I tend to just use `<br>`, which is more explicit.

Reminded me of the "Rules of Comfortable Measure", from The Elements of Typographic Style, quoted here:

http://webtypography.net/2.1.2

I always find myself fighting this on practically every website.

But it makes sense to me, that this should be something we think about in, well, most of our editors as well.

I debate about the measure of code, but I do find 100 to be a reasonable fit for most languages. The problem, is that I want code at 100, and then comments at 66. Oh well.

Ironic that the lines on the page are well over 200 characters.

Yeah, I chuckled that page didn't apply the fixed width that it recommended. If you just apply the width rule, it seems to mess up the right column.

It's like a microcosm of how challenging CSS is to get right.

The actual book this website is based on comes from print media. That website is just trying to apply those ideas to the web. And, as we see, not quite getting it right

I highly recommend Bill Hill's _The Magic of Reading_, and excellent document on the art of typesetting and why we have various typographic conventions (hundreds of years old now) and why they work. I had so many profound realizations from this paper.

https://nreilingh.github.io/The-Magic-of-Reading/

This resonates with me. I typically narrow my Outlook windows to ensure a certain look/feel to my line length and breaks. I get flustered any time the window stretches across the the screen. So fun to read through another person’s experience with this.

Hm, I guess keeping my code line length capped at 80 for all these years may have beneficial. Makes me wonder if there is any correlation to preferred line length and choice of programming language, job considerations aside.

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.

5 to 15 per week is incredible already

I agree, I can feel my own burning jealousy.

it depends on the length, really.

1200 to 2000 words each.

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

Work hard on the outline. Go as deep as you can for a while on the outline as it makes the piece itself simple.

Tools like the Hemingway editor are quite valuable as well.

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.

Check if your language has a pipe operator. You may be able to do something like this:

  my $baz = GetFoo()
    |> GetBar
    |> GetBaz;

Thanks for the idea, I'll consider it.

One of the other reasons I use this style is because it allows me to port code easily between different languages.

For example, aside from the "my" keyword, I can pretty much copy and paste the same code between PHP and Perl.

I could imagine this trick helps.

In my experience, when I try to convert a text into tweets, it gets more concise.

I'm often baffled how much I can condense information down to 280 characters.

I've found that when I condense an impressive amount of information down to 280 characters, the compression is lossy. People only pick up one tidbit out of the several that I've packed in; or maybe they'll come away with a completely wrong interpretation. Hell, even when I come back to my own writing, I find that it's too clever by half and I can't extract the nuance that I expected to be clear.

Yes, that's true.

I wouldn't try to convert everything to one tweet. Often, I need to split it into a thread.

That's why I never succeed at writing letters to the editor: the word limit is too small for anything complex enough to be wrong about!

That‘s one of the most annoying things for me on HN, that text is rather small and lines are extremely long. Especially difficult in the comment section.

Firefox remembers the zoom level for each site separately, so you can zoom HN to e.g. 110 % to fix the font size.

The line-length issue can be fixed by resizing the browser window. At least that works for me - none of the sites I use require a huge amount of horizontal space. (Many people seem to keep all their browser windows maximized out of habit, but that is not necessarily the optimal window size.)

I know, still I consider the layout of HN bad design. And I don't want to resize the browser window for every website I visit. There is a reason why Bootstrap "invented" .container.

https://getbootstrap.com/docs/5.0/layout/containers/

Interesting idea. No clue if it’s true, but it deserves an upvote just for being intriguing if nothing else.

I also find paragraph length affects my reading speed and focus.

When a paragraph is too long I tend to skim past it, even though the same paragraph split into a few smaller paragraphs would have the same word count.

Here's a tip, read the first line of each paragraph you skip. A properly structured paragraph contains a 'thesis statement' in the first sentence most often. From there you know whether you want to complete the paragraph or not because what follows are usually supporting statements.

Great insight ... most Bibles are formatted with thin columns as well. Maybe why it is easier to memorize as well. I got to try this for writing! I don't know why I didn't think of this.

That goes back at least to the Gutenberg Bible, which was two columns per page with generous margins for annotation or hand-drawn decoration.

You weren't kidding about the margins! https://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2...

Does anyone know how to get the narrow column at the center of the screen in full screen mode pictured in the article using vim settings? see https://breckyunits.com/writeThin.png

I tried :set textwidth=<tw>, but that gives left aligned so not quite the same...

Probably Goyo. It's a vim plugin.

Thx for the tip. I managed to get it working.

Here are the additions to ~/.vimrc in case anyone is interested (this after installing vim-plug https://github.com/junegunn/vim-plug#unix and running :PlugInstall as per goyo instructions:

   set wrap linebreak nolist
   
   call plug#begin('~/.vim/plugged')
   Plug 'junegunn/goyo.vim'
   call plug#end()
   
   "Goyo settings
   let g:goyo_width = 60
   let g:goyo_height = 999
   let g:goyo_margin_top = 0
   let g:goyo_margin_bottom = 0

I will add that it’s also useful to have as much text as possible so you can see the flow, the context and the “context of the context.”

But I find this insight more or less convincing so I guess the ideal writing screen is thin and tall.

Sadly, that’s the opposite of what horizontal monitors encourage. This might be another benefit of physical notebooks.

+1 about the tall and narrow, especially for editing.

I used to work from my friend's office who has these giant monitor that can pivot 90 degrees and I was easily 1.5x or 2x more productive given how much text was on the screen (almost and entire section of the book), and so I didn't have to scroll much...

Some screens can be rotated to be tall and thin. If yours doesn't, you can probably buy a mount for it.

I have an irrational hatred of columns. My master's degree reading includes many articles in journals that use columns, and pieces from the 1800s which are in columns, and I almost always feel anxiety with opening them for the first time. I felt that same anxiety for this website.

I think part of the reason is that actually scrolling a page with columns is a pain if you are zoomed in to make the text legible. You can't just scroll one direction on a tablet, you have to scroll down then back up and slightly over, scroll down again, then back up, etc. Sometimes you lose your place and have to zoom out to find what column you were previously on. Even then if I have the choice between a print book with columns and without (such as the Bible), I will always choose without.

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?

Typora

I think Hemingway mode is when backspace and delete are disabled. Ghostwriter (https://wereturtle.github.io/ghostwriter/) has Hemingway mode and another mode that they call "distraction free mode" which highlights just the current sentence.

FWIW I find it really distracting to have the current sentence highlighted because it means the file's appearance changes more than it otherwise would. Sublime Text has a "distraction free mode" (shift+F11) which goes to fullscreen, hides all menus, limits the current file width, and centers the file's contents.

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.

If I understand correctly, the Limelight plugin for Vim does this. It's best used in conjunction with Goyo, which achieves the narrow columns as well.

Does anyone know what the phenomena is called where you think about something/hear about something and then suddenly you stumble across multiple instances of it in the wild?

Just yesterday I began configuring the textwidth/wrap porperty in my Neovim. I went to bed thinking that maybe a hard-capped width of X*2 cahracters would be better, so I can fit more text "into a square" -- which basically means that I focus on a point in the middle of the text and see X characters left, right, up and down.

Now today, the first article I read is about the same exact problem :)

It's called Baader-Meinhof phenomenon: https://www.healthline.com/health/baader-meinhof-phenomenon

Now you will encounter people mentioning this phenomenon all over the place.

Poet William Carlos Williams famously wrote on prescription pads[1] and the constraint was defining in his work's simplicity.

I'm not sold (ahem) that the New York Times newspaper chose columns strictly for the purpose of reading speed.

[1]https://collections.library.yale.edu/catalog/11870008

EDIT: I've recently been printing text on a thermal printer ribbon and editing with scissors. As the author writes, and as I write less, weight this accordingly.

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

I don't know about writing, but I found the layout of this website easy to read; no need to move my eyes, just scan entire lines as I go. I'm on a 27" screen with the browser maximized, and sites the expand to fill that space are typically hard to read...

However, the same is absolutely not true of writing source code. I find there is much value in seeing the indentation structure, and messing that up with 'fake' indentation just to allow for shorter lines utterly destroys my source comprehension.

False premise on newspaper column widths AFAIU.

Thinner columns permit more individual stories on the front page, with more predictable lengths and layouts.

If column-width were optimised for reading comprehension, then one would expect to find internal content similarly laid out ... and it generally wasn't.

(I'm going off recollection rather than measurement here, but what I generally recall is that column-widths opened up on inside pages, especially for essays and the like.)

I'm not sure what all the contributing factors were, though I suspect tradition and fixed layout patterns especially for the front pages of newspaper section played a strong role, as well as a design that was optimised for scanning the front page when displayed at a news-stand or in a vending box as here:

https://www.travel-pictures-gallery.com/images/usa/washingto...

Skinny columns would show a lot of stories but not much story --- if you wanted more than the lede, you'd need to buy the actual paper.

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?

- Can you get this effect in an editor (Emacs/Vim/VSCode) so that you can review a long code file without scrolling too much?

thats actually super easy if i didn't misunderstand you

    .col-style {
        columns: 250px;
        height: 100vh;
    }
    <div classes="col-style"><p> everything in here will be in columns of 250px width and the scroll bar will be going to the right instead of the bottom</p></div>

try it out on the linked articles <body> element :) (you'll also have to remove the margins on that page however, as they're using negative values)

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.

Yeah, I tried that out. It works pretty well, except that it's not always obvious how the files relate to each other at a glance - I tried it out on an Org-mode file with a lot of small headlines, so that made it more difficult. It would be nice to see in my modeline which window shows which part of the file.

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

Thanks, but I feel that the benefit of thin columns only really comes when you can keep many of them on the page at once.

Update: I've managed to get at least part of this working by combining Emacs' built-in follow-mode with the built-in (I believe) eww browser, creating a multi-column browser. Here it is showing the GNU Emacs Wikipedia page: https://i.redd.it/t9joft2nbvy71.png

I found out that the author of this article wrote it using a markup language called (confusingly) Scroll: https://scroll.pub/. I'm not sure I want to bother learning another markup language when there are many extensions to Markdown already, but this author apparently favors the multi-column layout.

I find scrolling all the way to the bottom of a thin column to get old fast, however, especially when the article is longer than can fit into a single page.

It's pretty easy to constrain the height of the article text div element to be slightly less than screen height (using `height: 100vh`, or maybe slightly smaller if you have a header), which makes the columns fit vertically within the screen but causes more columns to appear off-screen to the right. However, you can override PageUp and PageDown to scroll left and right instead: https://github.com/publicdomaincompany/scroll/issues/10#issu....

That's pretty satisfying if you like to read in thin columns - almost like a poor man's PDF but completely in HTML.

I am not sure this would work for me - one of the important challenges in writing is to keep each sentence readable and not too complex, while not making the writing boring by avoid any complexity whatsoever. So thin columns would make this harder, it's easier to scan a sentence if it's just on one or two lines. And I also think it's nice to see the piece as the reader sees it while you write it, more or less. But hey, to each their own.

I always wanted to have a text editor capable of writing several columns of text side by side. This way, I could have a large file split into several columns with easy visualization. Editors like vim can split the screen vertically, but they're not great at keeping these columns in sync for the same file. This could be similar to the text flow option you'd find in desktop publishing software.

Emacs' follow-mode does what you're looking for, I think:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Fo...

Interesting. The tradeoff is of course that the wider columns are the more you're able to see at once, which is also important for editing.

I wonder whether it would be useful to be able change the column width with a keyboard shortcut. That way you could use small columns when you want to focus on the details and bigger columns when you want to focus on the big picture, both in writing and reading.

Interesting - I think wider columns produce exactly the opposite outcome. Too much space to cover and width to contemplate, hampering my ability to edit quickly. I don't think the width extra width helps you ingest and manipulate the words more efficiently.

The horizontally-condensed version of the same text allows me to see all of those same words, by the way. Just laid out in a format that isn't quite so exhausting to handle.

I even narrowed the HN editor while writing this reply and editing it for mistakes/grammar.

I don't mean that the extra width itself helps, I just mean that assuming vertical space is limited, then extra width means more words fit on the screen.

Cool hypothesis! Reminds me of the Alphasmart Neo[0], which a lot of writers seem to like because it allows you to go into a writing (vs editing) state of mind:

[0] https://duckduckgo.com/?q=alphasmart+neo&t=ffab&iax=images&i...

Column width has always affected my writting. The line breaks can hide some flow issues where punctuation might be necessary. For this reason I write on three emacs windows with different widths: one as narrow as suggested by OP, one more or less at target printer width, and one in between.

I recall reading somewhere that in typesetting the goal is to have 10-12 words / line because that is how much of a line the eye reads without side-to-side scanning.

Personally I find that with long lines I often waver to a different line as I scan from left to right. Thus I need to re-read the line which otherwise I would have read in a single pass.

That's why ~90 characters per line is not about the limitations of our huge-ass monitors, but about the limitations of our brains.

(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.)

First thing I noticed when getting a rotating monitor and put it in portrait mode was that reading speed went up. Not sure if it's less head movement and consequently neck strain, but anecdotally this helped my reading speed. Not sure about writing.

Interesting. Scrivener 3 actually defaults to using no where near all the screen real estate for words when writing, keeping it in a thinner column (which I now wonder if has a way to configure it), and I wonder if a similar idea was why they did that.

So turns out you can configure it. On Windows under file -> options -> appearance button at the top -> Main Editor then change the default editor width. I assume it is at least similar on Mac though the tutorial I saw said the first part was Scrivener instead of Windows.

Writing thin allows me to have three 72-column panes open in a single GVim Window all of which can help me peek at related content much more effectively than switching tabs etc.

It would be interesting to find out whether you can get the same effect by moving the screen further away, thereby reducing the field of view you have to scan through.

Anyone know of a vim or NeoVim setting or add-on to do this?

Goyo + VimPencil

For neovim: https://github.com/Pocco81/TrueZen.nvim

The problem of thin columns is the scrolling in my opinion. Currently the writer can't restrict the column height. So readers should scroll down and up if the post is long.

If browsers provide a CSS descriptor to limit the column height so that the page contains multiple columns and, if overflows, the overflowed content is shown in the downward direction (not horizontal direction), then maybe I can try this.

To try and help with the editing-too-much-while-writing issue, I created a small thing that prevents you from being able to edit as you write: https://write-on.io/

(basically just a text box that doesn't let you erase content)

I was convinced as soon as I read the title. I like that the blog used multiple columns to make it’s point.

I noticed this effect when ACM CHI switched their format. When I was writing in two thin columns, my writing really seemed to act more professional. I have a feeling it is because of the association and not reading fluency, as suggested, but I do agree there is an effect!

I one time read book that had 4 columns on every page. It was the hardest thing I read. It was a Amazon createspace for some out of print Modernist work (Tarr by Wyndham Lewis), get the Oxford Classics edition which you can now buy on Amazon.

Interesting, I wonder if screen writing came to a similar format for the same reasons.

I’d say, Chinese and Japanese are writing vertically for thousands years.

Does 'thin' == low word count? Or a small amount of space taken up by the words? What if I set my text width to 60 but then make it take up the full screen does it still apply?

Did anybody else just narrow down your browser to try HN that way?

Yes and I like it better

Does anyone know of a PDF reader than will show three pages side by side? And allow the right arrow to flip forward by one page on each press?

I believe SumatraPDF could do this.

Thanks :)

I don't use Windows, but your comment led me to look at this GitHub issue discussing this feature in SumatraPDF: https://github.com/sumatrapdfreader/sumatrapdf/issues/246#is...

Someone there mentioned that Firefox supports this. I just tried it (it's called 'Wrapped Scrolling') and it works well. I can't see how to advance by a single page at a time, but that's minor thing.

Feels to me that this is basically pushing to keep your writing as rapid as your talking.

To a large extent, I think this is probably right. Helps if you work in the pauses and the general quirks of your speech into the text.

Probably up in the air on whether or not this is a good idea or not. I'm sure a lot has to do with you are talking to and why.

Also note, this is not "as rapid as your thinking." Such that, I'm sure your mileage varies depending on how you read. (Do you have an inner voice, for example.)

It depends. Japanese, Chinese, Korean, Mongolian, etc. writers are using vertical layout for text without problem.

https://www.w3.org/International/articles/vertical-text/

Cool take.

I just checked, and it looks like Ulysses has a default width of 64 characters. Swapped it to 50. Let's see what happens.

Blog author suggests 36 characters. I have done 50 before but am now tempted to try 36.

Edit 1: I did some quick experimentation with columns that were 36, 40, and 50 wide. There is something magical about 36. With 50 my eye movements were conscious. With 36 it was as if I was able to read the whole column in peripheral vision. Much more immersive. I wonder now about narrower fonts, if they could produce the same effect.

I can see the logic in this. You seek less.

Ironically, HN is probably the most egerious example of wide columns

why is the article not formatted in a thin column?

Reply on news.ycombinator.com