SQLite Forum

(email) Lack of paragraph wrapping in text/plain emails makes them hard to read
Login

(email) Lack of paragraph wrapping in text/plain emails makes them hard to read

(1) By Mark Lawrence (mark) on 2020-03-15 12:29:35 [link] [source]

Subject says it all.

(2) By Stephan Beal (stephan) on 2020-03-15 12:35:24 in reply to 1 [link] [source]

Similarly, code blocks in markdown are also running way off the right of the screen. My recommendation, Richard, would be:

.markdown pre > code {
  overflow-x: scroll;
}

And give the plain-text bodies:

white-space: pre-wrap;

(3) By Chris (crustyoz) on 2020-03-15 12:53:53 in reply to 2 [link] [source]

In the olden days that I remember well, mechanical typewriters 
used a 10 character per inch font. On a 8.5"x11" or A4 page with 
1" margins that allows for 65 characters on a line.

I've used that as a guide for __all__ plain text that I write, 
by pressing the __Enter__ at around that 65 character line 
length. My editor has a line width set for that without 
auto-wrap and I can use the reformat keyboard command to rewrap 
a paragraph to suit.

Replying to this thread interrupted me doing edits to 
application documentation written by me several years ago where 
that convention is followed, so it is fresh in mind.

It has the nice advantage that each line is fully readable in 
the Fossil side-by-side diff display.

Because the editor lets you write in a "stream of consciousness" 
does not mean you must use it that way.

Having written the above and clicked the __Review__ button, I am 
reminded that HTML ignores such niceties and wraps to the window 
width unless non-plain text markup is imposed. So, I enclosed 
this text in back-ticks.

(4) By punkish on 2020-03-15 13:06:01 in reply to 3 [link] [source]

most modern email clients have a format=flowed setting which makes the text flow to the width of the mail client. You are welcome to use backticks reserved for code blocks, but that is really not necessary. My email client shows your text with line breaks just as well as it would have had you written a normal paragraph not restricted by the technologies of the olden days.

(5) By Mark Lawrence (mark) on 2020-03-15 13:56:49 in reply to 4 [link] [source]

The format=flowed setting is unreliable (not all clients support it, or support it well). But that is the wrong end of the process to focus on. Generation, not consumption, is where you support all client scenarios the best.

There are two common formats for email:

text/plain: text is text, exactly as it appears please with no assumptions about how the receiver can or can not reformat it. So if you are generating this format it is sensible[1] and polite to not treat it like it flows. Think RFC documents.

text/html: not-for-humans text to be rendered, according to however the client likes.

This forum software could (should) be wrapping and storing _all_ input (since the default html text input form flows) with no impact to Markdown & HTML rendering, better viewing of Plain Text messages[2], and much more readable emails.

[1] https://www.researchgate.net/publication/234578707_Optimal_Line_Length_in_Reading--A_Literature_Review
[2] This message for example is really too wide in the web view as well

(6) By Stephan Beal (stephan) on 2020-03-15 14:20:12 in reply to 5 [link] [source]

This forum software could (should) be wrapping and storing all input (since the default html text input form flows) with no impact to Markdown & HTML rendering.

This forum system is based on Fossil's SCM core, and the SCM core necessarily stores precisely what it is given, not some arbitrarily modified form of it (e.g. auto-wrapped using arbitrary word-wrapping rules hard-coded into it (80-ish columns is a historical limitation/convention which almost never applies nowadays in environments where people are using web-based forums)). People who want their posts to be wrapped "nicely" must either do so themselves or use one of the two HTML-friendly formats (noting that the format can be changed after posting, if desired, by editing the post). Having Fossil (which includes its forum engine) automatically modify any input at all would be taking a step down a Dark Path.

(8) By Mark Lawrence (mark) on 2020-03-15 15:34:24 in reply to 6 [link] [source]

I was not suggesting that the SCM core stores anything other than what it's given. And it is precisely in a non-web context (email) that I started this thread. Given that this forum replaced a mailing list only days ago I find your characterization of column width conventions "historical" a little bit ... wrong :-)

Why should a web forum and SCM core (even if implemented in the same tool) suffer the same constraints as each other? Forum posters do not need or expect exactly the same direct relationship between the HTML/form and the database, like software developers do expect between the $EDITOR/file and the database. Particularly for input which will be rendered and styled on display. I don't see the dark path at all.

Point remains: Neither of the two HTML-friendly formats (or the plain for that matter) are text friendly for those who prefer to receive messages via email, regardless of whether authors think they are wrapping nicely or not. Formatting text on input or output can be philosophical or implementation dependent, sure, but I would really appreciate it if my SQLite forum mails provided the same quality reading experience I had with the mailing list.

(9.1) By Stephan Beal (stephan) on 2020-03-15 16:01:33 edited from 9.0 in reply to 8 [source]

Given that this forum replaced a mailing list only days ago I find your characterization of column width conventions "historical" a little bit ... wrong :-)

This forum software's been in use on the Fossil site since July or August of 2018. That instance operates at a whole different scale than the sqlite3 mailing list, though, and some growing pains are not unexpected in migrating that heavy-traffic/high-user-count list to this forum software.

The "historical" reference was more to what crustyoz said above about wrapping text, out of long-standing habit, at 65 columns. Even text terminals nowadays run, more often than not, in a windowed environment with 100+ columns. (And those environments where that is not the case are normally not systems where fossil is likely to be used.)

I don't see the dark path at all.

The Dark Path would be for the engine to modify any user-provided input in any way. Fossil has an age-old policy of retaining literally every bit of user input in the exact same pattern of bits the user entered.

i understand and sympathize with your argument against that policy, but also fundamentally believe that implicit modification of user input, by just about any software system, is a flaw in that system. That said, it's not my (admittedly hard-line) opinion which matters here - this is a policy decision which would require approval from Richard to change.

Point remains: Neither of the two HTML-friendly formats (or the plain for that matter) are text friendly for those who prefer to receive messages via email.

FWIW, i've been using this forum software heavily since Day 1 and have not had any appreciable problems reading posts via email (gmail, to be precise - perhaps text-mode email readers are indeed problematic in this regard). Nor, to the best of my fallible recollection, has it be brought up as a major usability problem for any of the fossil forum's posters. That said: see the note in the first paragraph about the scale that forum operates at compared to this forum.

Edit: per Richard's request, this topic is one for the Fossil forum, and i'll avoid responding to future posts on this topic in the sqlite forum, other than possibly to direct them to that forum.

(7) By punkish on 2020-03-15 15:01:33 in reply to 5 [link] [source]

The format=flowed setting is unreliable (not all clients support it, or support it well).

I think therein lies the rub. One could respond (somewhat justifiably) that one gets a client that support format=flowed.

But that is the wrong end of the process to focus on. Generation, not consumption, is where you support all client scenarios the best.

Perhaps, but not in the eyes of the one who is offering this forum. SQLite, the main product of DRH and his crew, and whoever else contributing to its source directly,1 does a seemingly impossible and incredible job of supporting all kinds of clients (OS and hardware). Many of them I've never even heard of let alone ever using them knowingly. In his view, the Fossil-based forum does a better job of supporting the users, and many users agree, some don't. That's how it goes.


  1. ^ by the way, I really don't know who all work on this lovely little db besides Richard. I have many folks I can thank for their help – Dan Kennedy, Keith Medcalf, Simon Slavin (there used to be a gentleman named Igor – a wizard with SQL – he seems to not be around any more). But who all actually work on creating SQLite on a day-to-day basis? Many thanks to them, and to all those who love helping others.