What is the best default line width?

[jolars]

This is a hot potato, but what line width should we use as a default for Panache? It's currently 80, but it's of course arbitrary and just taken for historical reasons and because I typically find it works nicely.

However, it's certainly not the best line width for readability. So something like I let Chat GPT run a deep research on this, and I'm pasting it below. It seems like the research, if the report is to be trusted, says that somewhere around 50-75 might be best. So the question is, should we lower the default to something else? I'm only giving three options here, because I think lowering it more than 70 would lead to disruption from other elements protruding beyond that all the time, like urls etc.

Executive Summary (Chat GPT deep research report)

Experimental research on line length (characters-per-line, CPL) in prose shows optimal ranges generally in the 50–75 CPL region for reading from screens. Classic lab studies (e.g. Dyson & Kipping 1998; Dyson & Haselgrove 2001) found intermediate line lengths (~55 CPL) yield the highest comprehension and speed【40†L56-L64】【29†L68-L72】. Very short lines (≤30 CPL) slow reading and comprehension, while very long lines (≥100 CPL) can also reduce comprehension【40†L56-L64】【29†L68-L72】. These findings were on standard proportional fonts on monitors. In fixed-width (monospaced) contexts, proportional fonts generally allow slightly faster reading. Mansfield et al. (1996) found Times (proportional) read ~5% faster than Courier (monospace)【26†L822-L830】. Arditi et al. (1990) similarly reported proportional spacing gave a small speed advantage at normal print sizes【73†L73-L77】. For low vision or magnified text, fixed-width spacing can become advantageous, but for typical reading and code-like text, proportional spacing reads faster.

Implications for monospaced source text: Controlled studies suggest aiming for about 50–60 CPL is safest for comfort and comprehension, even in monospaced fonts. For example, Dyson (2001) found 55 CPL produced peak comprehension【29†L68-L72】. However, code indentation and markdown syntax complicate this. As a practical default, wrapping Markdown source to about 70–80 characters per line (including spaces) is reasonable: it lies in the broadly optimal range, accommodates indentation, and remains readable in a fixed-width editor. We conclude with moderate confidence that ~50–75 CPL is ideal for prose, and modestly higher (~70 CPL) is acceptable for code contexts, noting trade-offs (e.g. readability vs. line count) and individual differences.

Study (citation)	N, Population	Font & Size	Display	Lines tested	Task & metrics	Key results (opt. CPL, significance)	Limitations
Duchnicky & Kolers 1983 (Human Factors)	Unreported (lab adults)	Monospaced (VDT font)	CRT monitor (scrolling)	50 vs 40 cpl; columns of 1/3, 2/3, full	Read 30 passages (~300 words) via scrolling; reading rate (wpm) and comprehension	50-char lines read ~30% faster than 40-char【67†L474-L482】; wider columns (2/3 & full width) read ~25% faster than narrow (1/3)【67†L474-L482】 (p<0.01). Comprehension not reported as impaired.	Scrolling text, fixed content, old hardware; detailed stats not fully given.
Dyson & Kipping 1998 (Visible Language)	n=24, adults (UK)	Proportional (screen)	CRT monitor (paged/scroll)	25, 40, 55, 70, 85, 100 cpl	Silent reading of ~800-word documents; total reading time, comprehension Q’s	Long lines read fastest: 100 cpl > 25 cpl (statistically significant) with no loss of comprehension【40†L56-L64】. Subjective ease rated best at ~55 cpl; longest lines rated hardest despite speed.	Small N; one display size; unreported font name/size; mixed paging/scrolling conditions.
Dyson & Haselgrove 2001 (Int’l J HCI)	n=36, adults (UK)	Proportional (screen)	CRT monitor	25, 55, 100 cpl	Read passages at normal & fast speeds; comprehension accuracy and reading rate	Medium lines best: 55 cpl yielded highest comprehension at both speeds and was read faster than short lines【29†L68-L72】. Very short (25) and very long (100) lines produced lower comprehension. All effects p<0.05.	Only 3 line lengths tested; used timed reading tasks; no monospaced font involved; user comfort not measured.
Shaikh & Chaparro 2004 (HFES Proc.)	n=20, college students (US)	Proportional (screen)	CRT monitor (news layout)	35, 55, 75, 95 cpl	Read online news stories; measured speed, comprehension, satisfaction	Mid-range optimal: Comprehension and satisfaction peaked at ~55 cpl, dropping off at very short (35) and very long (95) lines (differences often significant). (Reported in HFES conf abstract.)	Details unpublished online; no p-values given here; general population of young adults.
Rubin et al. 2006 (Ophthal & Phys Opt)	43 subjects (20/20–20/50 acuity)	Mixed: Times, Courier	CRT monitor	Standard ~70 cpl; subset at 35, 90 cpl	Read MNREAD passages (3 lines) at 40 cm; measured reading speed and acuity	Line width: No significant effect on reading speed by changing from 70 to 35 or 90 cpl (p>0.3)【1†L315-L323】. Font: Larger type improved speed; Courier (mono) did not outperform Times or Arial for normals.	Intended for low/mild vision; small fonts near acuity limit; reading aloud not silent; fonts fixed in MNREAD.
Mansfield et al. 1996 (IOVS)	n=50 normal, 42 low-vision (US)	Times-Roman (prop), Courier-Bold (mono)	Printed MNREAD charts	~56 cpl (Courier), ~60 cpl (Times)	Timed reading of sentences; MNREAD metrics (speed wpm, critical print size)	Prop vs Mono: In normal readers, Times (prop) gave ~4.7% faster max reading speed than Courier (mono) (p<0.001)【26†L822-L830】. In low-vision, Courier had slight acuity advantage only at smallest text.	Only two fonts tested, on charts (not dynamic display); fixed number of chars/line (60 vs 56); vision tests context.
Arditi et al. 1990 (JOSA A)	Unreported (N~10 adults)	Identical font: fixed vs proportional spacing	Likely CRT	Varying print size (Angular char width)	RSVP reading at large vs small print sizes, speed measured	Spacing effect: At normal (large) print sizes, proportional spacing read slightly faster than fixed-width; at small sizes, fixed-width reading was faster【73†L73-L78】. (Morris et al. 1994 failed to replicate at normal sizes.)	Very small sample; manipulated print size and spacing together; RSVP paradigm (rapid serial visual presentation) – unlike normal reading.

Table: Key experimental findings on line length (CPL) and font type. Results emphasize optimal CPL and any monospaced vs proportional differences, with sources indicated.

Synthesis and Recommendation. Across studies in normal reading conditions, mid-range line lengths (~50–75 CPL) consistently support fast reading and good comprehension【40†L56-L64】【29†L68-L72】【67†L474-L482】. Very short lines (<30–40 CPL) force extra eye-return movements and reduce speed, while very long lines (≫80 CPL) degrade comprehension and comfort. In monospaced vs proportional font comparisons, fixed-width text is rarely superior for fluent reading: typical readers are slightly faster on proportional text【26†L822-L830】【73†L73-L78】 (likely because proportional spacing aids word shape and crowding). Hence, for reading code or Markdown source in a fixed-width context, one can treat optimal CPL similarly to prose: aim for moderate line length.

Confidence: These conclusions are supported by multiple peer-reviewed experiments on screen reading. No large-scale meta-analysis was found, and some findings (e.g. exact optimal CPL) vary by study design. However, recommendation is robust: wrap text so lines are not extremely short or long. A conservative default of around 70–80 characters per line (monospace) is practical: it lies near the empirical optimum, while allowing space for indent and markup. This roughly corresponds to the traditional 70–75 CPL for prose【40†L56-L64】【29†L68-L72】. Users with low vision or very large monitors may adjust differently (e.g. ensure at least ~50 CPL as a minimum【21†L310-L318】), but for typical code editing, ~70 CPL is a sound default.

Caveats: Markdown source often contains lists, code blocks, and inline markup; overly long lines can hurt diff-ability and editing. Also, some users prefer narrower lines (≈60 CPL) for readability (this lies at the edge of recommended ranges). The evidence is mostly on plain-text prose; code reading might prioritize different factors (e.g. semantic grouping). Finally, most studies used Latin-script alphabets and Western languages; different effects might occur for other scripts or reading modes.

Sources: We prioritized controlled experiments and peer-reviewed articles【40†L56-L64】【29†L68-L72】【26†L822-L830】【67†L474-L482】. Noted gaps include a lack of modern eye-tracking studies on code-like monospace text and any large-scale systematic review of CPL. Nonetheless, the weight of evidence justifies adopting ~50–75 CPL as optimal, with ~70 CPL a reasonable baseline for monospaced Markdown.

[hadley]

air defaults to 80, so @lionel- and @DavisVaughan might be able to share their reasoning.

[mschilli87]

I guess for the same reasons others want either:
Sentence wrapping keeps diffs cleaner and makes it easier for me to find a specific location in the text (for example when spotting a mistake in the rendered document and opening the Rmd source to fix it).
Line wrapping ensures I can read everything in narrow windows. I usually edit in neovim with a vertical split for my R console and the terminal containing both arranged vertically next to a rendered version (web browser, PDF viewer, office suite).
Yes, I could rely on soft-wrapping but since I use relative line numbers to navigate the source in neovim, hard-wrapping long lines gives me a higher resolution to move within long sentences this way.

[jolars]

Interesting! I hadn't at all thought about the possibility of combining the two. But you would certainly get some strange wrapping that way., wouldn't you?

Don't worry, @DavisVaughan! I have no intention of forcing hard wrapping into sentence mode wrapping 🙂

[mschilli87]

Not sure what you mean by 'strange'. But maybe I just never came across any of the more weird special cases and/or solved them intuitively in way that would be hard to automate.

[jolars]

Not sure what you mean by 'strange'. But maybe I just never came across any of the more weird special cases and/or solved them intuitively in way that would be hard to automate.

Sorry, I meant something like this:

Here is a sentence that is going to be
wrapped.
And here comes the next one.

So, if hard-wrapping triggers after "be", before sentence wrapping triggers at ".". But maybe I misunderstood what you meant?

[mschilli87]

Nope. That's exactly what I want (with a larger width though).

[DavisVaughan]

It feels somewhat odd that you can set both of these

line-width = 80

[format]
wrap = "sentence"

If wrap = "reflow" just means "use line-width" then maybe there should just be

[format]
wrap = 80
wrap = "sentence"
wrap = "preserve"

But perhaps I am missing some other use case of line-width

[jolars]

I agree with your logic, but I remember I had some reason for favoring line width as a top-level option. It escapes me now, but it was likely that I imagined there were cases when you could not safely wrap something, like Yaml scalars, and in those case would want to signal this though the linter.

Also, I am not thrilled about an option that takes integers and strings. If someone sees a config with wrap = 80, I don't think they're intuitively going to think that that option also is used to set sentence mode wrapping.

[jidanni]

Can you kindly add an option

$ panache format --width=...

so we don't need to learn about config files. Like html-tidy, perltidy, etc. all have.

In fact mutt(1) has -e:

-e command
Specify a configuration command to be run after processing of initialization files.

That way we need not even have write permission on the whole computer, but still be able to change config options.

[jidanni]

All I know is I am at home composing a conference paper, and every time I run it through the formatter, the lines in my markdown break just after the width of my terminal.

[jolars]

Are you sure you really want this? It feels like a bad idea for differently people formatting the same repo to get different results based on command line settings?

Hm. The use case would be to invoke it on a repo without a Panache config, as an alternative to temporarily adding one yourself. But since we also already support a global config fallback, maybe youre right that this actually doesn't fill a real use case.

[mschilli87]

@jidanni has presented a use case: Writing Markdown email in mutt, on a machine without write access to the config files.

[jolars]

@jidanni has presented a use case: Writing Markdown email in mutt, on a machine without write access to the config files.

Fair enough! I am fine with keeping it. Ive been looking around and its not that uncommon for formatters to expose this kind of toggle so we would be in good company.

The question is probably then whether it should be a general --option key=value setting that maps directly into the config (simpler, but more verbose) or a curated set of dedicated arguments for common or just the top-level options. I am leaning towards the former.

[jolars]

I decided to go with --option/-o as a general override in cd49506. Thanks for all the input. This basically mirrors mutt, so I hope it satisfied your needs, @jidanni