max / goingson
| 1 | -- The email body column records which of its two formats it holds. |
| 2 | -- |
| 3 | -- `emails.body` has always held one of two things, decided at sync by |
| 4 | -- `mime_parse::extract_body_with_html`: a `text/plain` part arrives as it was |
| 5 | -- sent, and anything else goes through `pter::convert`, which produces |
| 6 | -- MARKDOWN. One column, two formats, and until now no flag, so every reader |
| 7 | -- had to guess. Both of them guessed wrong in opposite directions: |
| 8 | -- `utils.js:formatEmailBody` treats the body as text and escapes it, so pter's |
| 9 | -- markdown reached the reader as literal `**bold**` and `[text](url)`, and the |
| 10 | -- quasi port carries `Node::rich` unconditionally, so a plain message whose |
| 11 | -- asterisks happen to look like markdown renders as markdown. |
| 12 | -- |
| 13 | -- Two values, and TEXT rather than a bool, matching `events.tz_kind` (063). |
| 14 | -- The set is open in one direction: a body that is neither (raw HTML kept |
| 15 | -- verbatim, say) is a plausible third case, and a `body_format` column takes |
| 16 | -- it as a new value where a `body_is_markdown` flag would take it as a rename. |
| 17 | -- |
| 18 | -- plain the body is the bytes a `text/plain` part carried, or text the |
| 19 | -- user typed into compose. Rendered as text, escaped. |
| 20 | -- markdown the body is pter's output: machine-produced markdown, converted |
| 21 | -- from HTML that arrived from outside the app. Rendered through a |
| 22 | -- markdown renderer. |
| 23 | -- |
| 24 | -- 'plain' is the default and the backfill, which is the conservative direction |
| 25 | -- rather than the correct one, and the distinction is worth stating. Existing |
| 26 | -- rows cannot be reclassified without re-parsing the source message, which the |
| 27 | -- database does not keep -- and the rows that came from HTML are exactly the |
| 28 | -- ones that read wrong today. So an existing markdown row stays mislabelled |
| 29 | -- and keeps rendering exactly as it does now, while everything synced after |
| 30 | -- this migration is labelled correctly. Defaulting the other way would take |
| 31 | -- every genuinely-plain row in the database and start rendering its asterisks |
| 32 | -- as bold, which is a new bug applied to the majority to retroactively fix the |
| 33 | -- minority. The mislabelled rows age out as folders resync. |
| 34 | -- |
| 35 | -- Not synced: `emails` is absent from the sync manifest (emails stay |
| 36 | -- per-device), so this column is local like the rest of the table. |
| 37 | |
| 38 | emails ADD COLUMN body_format TEXT NOT NULL DEFAULT 'plain'; |
| 39 |