Replies: 3 comments 22 replies
-
|
air defaults to 80, so @lionel- and @DavisVaughan might be able to share their reasoning. |
Beta Was this translation helpful? Give feedback.
-
|
It feels somewhat odd that you can set both of these If But perhaps I am missing some other use case of |
Beta Was this translation helpful? Give feedback.
-
|
Can you kindly add an option so we don't need to learn about config files. Like html-tidy, perltidy, etc. all have. In fact mutt(1) has -e:
That way we need not even have write permission on the whole computer, but still be able to change config options. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
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.
3 votes ·
Beta Was this translation helpful? Give feedback.
All reactions