C12.7: POP3 fetch by UIDL

2026-10-19 21:40:25 -04:00
1 parent 890bd80d4d
commit 4d0d64ff54
@@ -320,6 +320,6 @@ cargo run -p ely-doc          启动一个应用（ElyDoc 先 cargo build -p ely
 - 2026-10-18：Word 公式（R8.2，Gitea #9）。附件 math.docx 的六类公式逐类核对（本机无 Word，以文件所写为准）：键盘输入、OMML（内核转为公式对象）、MathType（OLE，显示随带的 WMF 预览）、上下标、图片原本就对；差别在两处根因。其一，运行的 `w:position`（升降）原先只给文字，图片与 OLE 公式所在的运行失去它（25 张图片与一个 ½ 浮在行上）：补丁 `0049-writer-inline-objects-move-with-their-run.patch` 把它作为固定升降写到对象的锚字符上（按锚字符自己的字号换算百分比，不扩展到其后的文字），版面让“作为字符”的对象随锚字符的固定升降移动（vertAlign 的自动上下标不动对象，同原样）；各导出本就写出锚字符的升降，DOCX 往返仍为 `w:position`。其二，EQ 域原先只认 `\o`、`\s\do` 与注音，其余（如分数 `\f`）整个消失：补丁 `0050-writer-eq-field-parser.patch`（读法）与 `0051-writer-eq-fields-as-formulas.patch`（导入）把 EQ 域转为公式对象：`\f` 分数、`\r` 根式、`\s` 上下标、`\b` 括号、`\l` 列表、`\a` 阵列、`\i` 积分与求和求积；`\x` 与 `\o` 只留内容（无框、无叠印），`\d` 只前移，`\ai`、`\di` 只是行距（不升降），开关不分大小写；每个命令字符保留其运行的上下标（Word 照此画），同一段上下标里字样变了仍是一个上下标；斜体字母写成标识符（StarMath 与 OMML 都画成斜体，DOCX 往返不丢），斜体的数字与符号写成 `ital` 文字，存为 DOCX 后成正体（OMML 无此写法，已知限制）；没有底的上下标以空文字为底（空的底在 OMML 里是占位符，重开成 `<?>`）；公式取域的字号；读不通的命令以其域代码显示为文字，不消失。只有整个域是 `\s\do N(文字)` 时照原样成为下移的文字，其余都经读法（原先小写的 `\s\do` 读到第一个括号即止，其后丢失）。`client/tests/word.rs` 以 `tests/fixtures/office/word.docx`（由 `.work/r8/gen/eq.py` 生成，不入库）核对公式文本（含开头的空格、大写开关、读不通的域、字样变化的下标、`\ai`、`\di`、小写 `\s\do` 的尾部与嵌套）、DOCX 往返后的斜体、下标与无占位符、锚字符的升降与图块里图片低于文字（去掉版面的升降即失败）。审查三轮：第 3 轮的四处已修并以上述测试核对，未再审查（每条至多三轮）。仍与 Word 不同：编辑区里公式与图片四周有内核的辅助框线（`ShowBoundaries`，视图辅助，不印出）；DOCX 另存后重开行距变宽，因内核导出改写文档默认字体与段距，与公式无关。
 - 2026-10-18：工作表过多时标签条（R8.3，Gitea #8）。组件库 `navigation::Tabs` 横排时可横向滚动（滚轮同样），标签可窄于自然宽度；所选标签在所选或标签条宽度变了时滚入视口，在绘制时以刚排好的宽度判定（原先只在首帧滚一次，其后右栏打开、标签条变窄，所选标签被挤出视口）；手动滚动保留到二者之一再变；横排的标签至多与标签条同宽，名字过长以省略号结尾（组件库 e56a343、3a68d1b、7d704d9，同批带入上游列外壳拖动的四个提交）。ElyTable 的标签条随之收缩，添加按钮留在其旁；标签条的状态按工作簿各记一份（元素 id 带标签号），切到另一工作簿时其所选标签照样滚入。`navigation/tests/tabs.rs` 以 30 个标签核对：首帧滚到所选、滚轮回到第一个、新选的滚入、变窄后所选仍在末端（去掉按宽度判定即失败）、长名的所选标签整个在标签条内（去掉宽度上限即失败）；ElyTable 的 `tests/strip.rs` 以 `sheets::strip` 画两个各有 30 张表、都选第 30 张的工作簿，滚回开头后来回切换，所选标签每次都在标签条内（两个工作簿共用一个 id 即失败）。Windows 真窗口（`.work/r8/strip3.png`）：30 张表、第 30 张为当前，1100 宽时标签条末端为它。
 - 2026-10-18：ElyMark 公式（R8.4，用户定两项都做）。行内公式照块公式由 RaTeX 排版（原只显示着色的 TeX 原文）：gpui 的文本里放不进图片，组件库 `render/math_text.rs` 把每个行内公式换成等宽的不断行空格（U+00A0，按字体量出个数），排好的公式居中画在其上，行高随最高的公式撑开；空格串与词一样整个折到下一行，画在其所在行（折行处的序号 gpui 读作上一行末）；按下与右键所在的字节经换算读回公式的原文；排不出的公式照旧显示 TeX 原文，其后以危险色写出 RaTeX 给的原因与位置，记警告（不含公式）。`\(…\)` 读作行内公式，`\[…\]` 读作块公式（ChatGPT 等常写的分隔符；GitHub 不认，Typora 默认不认）：解析前逐字节把成对的分隔符换成 `$`（长度不变，位置照旧对得上）。成对只在同一段落、标题或单元格里（跨列表项、CR 空行不成对）；不跨代码、公式、HTML 标签、链接地址与引用标签、图片、脚注引用，`<code>`、`<kbd>` 之间（含嵌套；交叉闭合照可视的读法关闭与重开）的文字照原文；`\\(` 不换。公式里与段落里另有的 `$`（含 `\$`）解析时暂写成文本里没有的控制字节，解析后还原，不与换上的 `$` 配对；相邻的两个公式之间暂插一个空格，解析后去掉，仍是两个公式。公式节点的范围是整对分隔符，值是写下的 TeX 原文。独占一段的 `\[…\]` 为块公式（段首可有一至三个空格）。组件库公开 `documents::markdown_tree`，ElyMark 的 HTML、PDF、纯文本导出都经它解析（`markdown_options` 不再公开），纯文本里独占一段的公式照块公式写其 TeX。同时查出（组件库 e095f06）：RaTeX 的 SVG 以 pt 定尺寸，usvg 按 px 量墨迹，两者差 4/3，每个公式的画面右侧与下方多出约四分之一的空白（块公式因此偏左）、导出的公式比正文大 4/3；现生成时即把根改为 px。`markdown/tex/tests.rs` 与 `tree/tests.rs` 核对分隔符的各种情形（相邻、`\$`、链接地址、`<code>`、跨块），`math_text.rs` 的窗口测试核对公式排进并读回原文、折到第二行的公式画在第二行首（改回按起点定位即失败）、排不出的公式写出原因（组件库 a20e712、5fba7b3、de961eb），`math/tests.rs` 核对画面与公式同宽（改回 pt 即失败），ElyMark 的 `visual.rs` 核对导出与纯文本。Windows 真窗口（`.work/r8/mark/visual2.png`）：`$…$`、`\(…\)` 排在行内，`\[…\]` 居中成块，行内代码与转义的 `\\(` 照原文。
- 2026-10-19（用户定）：ElyMail 的后端改为 Rust crate，取代 MailCore 2（其 Windows 构建是 VS 2013 工程加 2015 年前后的预编译依赖，POP 无 OAuth2）：mail-send、mail-parser、mail-builder，在应用进程的后台任务里运行，不另起 worker；MailCore 2 与 libetpan 的取码、构建与探测随之删去。正文以 html5ever 解析、净化后按块的子集由 GPUI 绘制，不当作完整页面；写信用 Markdown 文档组件，发出纯文本与 HTML。Gmail 与 Microsoft 走 OAuth（授权码加 PKCE，本机回环），客户端 ID 在构建时注入：`ELY_GOOGLE_CLIENT_ID`、`ELY_GOOGLE_CLIENT_SECRET`、`ELY_MICROSOFT_CLIENT_ID`，本机写在项目根的 `oauth.env`（不入库），CI 为仓库机密；缺 ID 的构建里该登录写明不可用，不退回别的方式。iCloud 不给第三方 OAuth，走应用专用密码向导（`imap.mail.me.com:993`、`smtp.mail.me.com:587`，无 POP3）。注册由用户做（Google Desktop 客户端，Entra 公共客户端，委托权限 IMAP、POP、SMTP 与 offline_access）。POP3（C12.1 审查后）由引擎自写，不用 async-pop：它留着点填充、丢末尾 CRLF、吞掉登录后的连接错误、不答 XOAUTH2 的错误挑战、在 trace 日志里写出密码。IMAP（第 2 轮审查后）同样自写，以 imap-proto 解析回复，不用 async-imap：它的 LIST、FETCH 等流式命令不看结尾的 NO 与 BAD（拒绝成了空结果），登录与命令中途的 `* BYE` 被丢掉（只剩断线），trace 日志写出密码与邮件。SMTP 的事务（MAIL、RCPT、DATA）也由引擎自走：mail-send 不给首行的点加点；正文有 8 位字节即带 `BODY=8BITMIME`，服务器不支持即拒绝。读信按 MIME 树与所在容器（C12.2），嵌套（多部分与内嵌邮件都算）深于 64 层即报错，超深的解析结果以迭代拆开再丢（直接丢弃会递归、栈溢出）；mail-parser 开 `full_encoding`；SMTPUTF8 按每一层的头块判定。本地存储（C12.3）：rusqlite 自带的 SQLite，`mail.db` 加内容目录（原文按 SHA-256），FTS5（trigram）可由索引与原文重建；`user_version` 记结构版本，升级前备份，失败即只读；原文文件在删去或替换邮件的事务提交前删去，删不掉即回滚。只有 HTML 的邮件经 html5ever 的树构建器取文字入索引，元素深过 512 层即停读（树构建器的开放元素栈扫描随深度平方增长）。凭据（C12.4）：密码与刷新令牌只进系统凭据库（keyring），被拒即只留在内存到退出；OAuth 换令牌与刷新经 ureq，回跳在 127.0.0.1 随机端口；Google 授权带 `access_type=offline` 与 `prompt=consent`（每次同意都发刷新令牌），Microsoft 另要 `profile`（无 `email` 时以 `preferred_username` 为地址），换码没有刷新令牌即报错；客户端 ID 由 `crates/ely-mail-engine/build.rs` 取环境变量或 `oauth.env`，该文件不存在即未配置，读不出或写错即构建失败。ureq 在 trace 级逐字节记下请求与回复（令牌、客户端密钥），`ely_platform::logging` 在任何 `ELY_LOG` 下都不记 `ureq`、`ureq_proto` 低于 info 的日志。账号（C12.5）：`ely_mail_engine::Account` 存在 accounts 表的 settings 列（JSON），凭据库名 `account:地址`；删账号先删凭据再删本地数据，本地删除失败即放回凭据，凭据库删不掉时内存里的凭据照留，不动服务端；地址在库里唯一，不分 ASCII 大小写（`Error::Taken`）。应用的库读写在后台、锁后进行，网络任务在应用自带的两线程 tokio 运行时上，结果交回 gpui。iCloud 收发都以完整地址为用户名。删去原文先改名为 `.散列.gone` 留在原处，事务提交后才删，失败即改回；打开库时按库里是否仍有邮件指向它放回或删去（C12.5 第 1 轮后）。对话框的请求（检查、登录、保存）在整个窗口里编号，回来时只作用于仍在等它的那个对话框；保存的结果照样更新账号列表，失败而对话框已换即以提示写明。端口记下上次自动填入的值，与之不同的即为键入，换安全方式不覆盖。IMAP 同步（C12.6）：文件夹按 LIST 存为邮箱（角色按 RFC 6154，INBOX 按名、库里不分大小写；有 LIST-EXTENDED 与 SPECIAL-USE 即以 `RETURN (SPECIAL-USE)` 取角色），不再列出的连同邮件删去；EXAMINE 缺 UIDVALIDITY 或 EXISTS 即报错；UIDVALIDITY 变了即清空重建；同一 UID 的 FETCH 回复合并；邮件头全取，正文只取 90 天内（`sync::BODY_DAYS`）：先读 BODYSTRUCTURE，无附件即取整封，有附件只取头与正文部分、按原结构重组，附件内容为空、部分号记在 `missing`，附件按需（C12.17），处置为 attachment 的多部分整个按需，related 里不看处置（RFC 2387）；新列由结构 v2 升级加上，UIDVALIDITY 不同于所记时只删别的 ULine truncated
+- 2026-10-19（用户定）：ElyMail 的后端改为 Rust crate，取代 MailCore 2（其 Windows 构建是 VS 2013 工程加 2015 年前后的预编译依赖，POP 无 OAuth2）：mail-send、mail-parser、mail-builder，在应用进程的后台任务里运行，不另起 worker；MailCore 2 与 libetpan 的取码、构建与探测随之删去。正文以 html5ever 解析、净化后按块的子集由 GPUI 绘制，不当作完整页面；写信用 Markdown 文档组件，发出纯文本与 HTML。Gmail 与 Microsoft 走 OAuth（授权码加 PKCE，本机回环），客户端 ID 在构建时注入：`ELY_GOOGLE_CLIENT_ID`、`ELY_GOOGLE_CLIENT_SECRET`、`ELY_MICROSOFT_CLIENT_ID`，本机写在项目根的 `oauth.env`（不入库），CI 为仓库机密；缺 ID 的构建里该登录写明不可用，不退回别的方式。iCloud 不给第三方 OAuth，走应用专用密码向导（`imap.mail.me.com:993`、`smtp.mail.me.com:587`，无 POP3）。注册由用户做（Google Desktop 客户端，Entra 公共客户端，委托权限 IMAP、POP、SMTP 与 offline_access）。POP3（C12.1 审查后）由引擎自写，不用 async-pop：它留着点填充、丢末尾 CRLF、吞掉登录后的连接错误、不答 XOAUTH2 的错误挑战、在 trace 日志里写出密码。IMAP（第 2 轮审查后）同样自写，以 imap-proto 解析回复，不用 async-imap：它的 LIST、FETCH 等流式命令不看结尾的 NO 与 BAD（拒绝成了空结果），登录与命令中途的 `* BYE` 被丢掉（只剩断线），trace 日志写出密码与邮件。SMTP 的事务（MAIL、RCPT、DATA）也由引擎自走：mail-send 不给首行的点加点；正文有 8 位字节即带 `BODY=8BITMIME`，服务器不支持即拒绝。读信按 MIME 树与所在容器（C12.2），嵌套（多部分与内嵌邮件都算）深于 64 层即报错，超深的解析结果以迭代拆开再丢（直接丢弃会递归、栈溢出）；mail-parser 开 `full_encoding`；SMTPUTF8 按每一层的头块判定。本地存储（C12.3）：rusqlite 自带的 SQLite，`mail.db` 加内容目录（原文按 SHA-256），FTS5（trigram）可由索引与原文重建；`user_version` 记结构版本，升级前备份，失败即只读；原文文件在删去或替换邮件的事务提交前删去，删不掉即回滚。只有 HTML 的邮件经 html5ever 的树构建器取文字入索引，元素深过 512 层即停读（树构建器的开放元素栈扫描随深度平方增长）。凭据（C12.4）：密码与刷新令牌只进系统凭据库（keyring），被拒即只留在内存到退出；OAuth 换令牌与刷新经 ureq，回跳在 127.0.0.1 随机端口；Google 授权带 `access_type=offline` 与 `prompt=consent`（每次同意都发刷新令牌），Microsoft 另要 `profile`（无 `email` 时以 `preferred_username` 为地址），换码没有刷新令牌即报错；客户端 ID 由 `crates/ely-mail-engine/build.rs` 取环境变量或 `oauth.env`，该文件不存在即未配置，读不出或写错即构建失败。ureq 在 trace 级逐字节记下请求与回复（令牌、客户端密钥），`ely_platform::logging` 在任何 `ELY_LOG` 下都不记 `ureq`、`ureq_proto` 低于 info 的日志。账号（C12.5）：`ely_mail_engine::Account` 存在 accounts 表的 settings 列（JSON），凭据库名 `account:地址`；删账号先删凭据再删本地数据，本地删除失败即放回凭据，凭据库删不掉时内存里的凭据照留，不动服务端；地址在库里唯一，不分 ASCII 大小写（`Error::Taken`）。应用的库读写在后台、锁后进行，网络任务在应用自带的两线程 tokio 运行时上，结果交回 gpui。iCloud 收发都以完整地址为用户名。删去原文先改名为 `.散列.gone` 留在原处，事务提交后才删，失败即改回；打开库时按库里是否仍有邮件指向它放回或删去（C12.5 第 1 轮后）。对话框的请求（检查、登录、保存）在整个窗口里编号，回来时只作用于仍在等它的那个对话框；保存的结果照样更新账号列表，失败而对话框已换即以提示写明。端口记下上次自动填入的值，与之不同的即为键入，换安全方式不覆盖。IMAP 同步（C12.6）：文件夹按 LIST 存为邮箱（角色按 RFC 6154，INBOX 按名、库里不分大小写；有 LIST-EXTENDED 与 SPECIAL-USE 即以 `RETURN (SPECIAL-USE)` 取角色），不再列出的连同邮件删去；EXAMINE 缺 UIDVALIDITY 或 EXISTS 即报错；UIDVALIDITY 变了即清空重建；同一 UID 的 FETCH 回复合并；邮件头全取，正文只取 90 天内（`sync::BODY_DAYS`）：先读 BODYSTRUCTURE，无附件即取整封，有附件只取头与正文部分、按原结构重组，附件内容为空、部分号记在 `missing`，附件按需（C12.17），处置为 attachment 的多部分整个按需，related 里不看处置（RFC 2387）；新列由结构 v2 升级加上，UIDVALIDITY 不同于所记时只删别的 ULine truncated
 - 2026-10-19（用户定）：代码与发布从 Gitea 搬到 GitHub 组织 ELY-Open-Source（`ELY-Open-Source/ElyOffice`；组件库 `ELY-Open-Source/Ely-GPUI-Components`，Cargo 的 git 依赖与 `fetch-references.sh` 随之改址，钉的提交不变；Kigi CLI 同在此组织）。历史、标签与发布已迁过，Gitea 停用，GitHub 是唯一的家。发布由 `.github/workflows/release.yml` 在推送 `v*` 标签时运行（只此一种触发，拉取请求到不了自托管机器）：macOS 在 `[self-hosted, macos-signing]`（Mac mini 的图形会话，Developer ID 签名并公证），Windows 与 Linux（WSL）在 `[self-hosted, ely-windows]`；各机的常驻克隆 `$HOME/ely-ci/ElyOffice` 从 GitHub 拉取。`scripts/ci.sh` 经 GitHub API 按标签取发布、没有就建（`GITHUB_TOKEN`，`contents: write`），同名文件先删再传：重跑只换本平台的文件。更新检查读 `api.github.com/repos/ELY-Open-Source/ElyOffice/releases/latest` 的 `<slug>.json`，清单的下载地址为 `github.com/ELY-Open-Source/ElyOffice/releases/download/v<版本>/<文件>`；0.1.8 及以前装好的应用仍查 Gitea，需手动装一次新版。官网 worker 读 GitHub API（可选机密 `GITHUB_TOKEN` 避开共享出口地址的限流），下载与源码链接指向 GitHub（GitHub 标志）；macOS 版已公证，去掉“未经公证”的提示。发布视频的源文件与成片里仍是 Gitea 地址，未改未重渲染。
 - 2026-10-19（用户定）：自有代码由 AGPL-3.0-or-later 改为 MIT（`LICENSE`，Copyright (c) 2026 Yang Zhang；工作区 `Cargo.toml`、Linux 包的许可字段、`docs/licenses.md`、官网）。第三方照旧：LibreOffice 与 `patches/libreoffice` 为 MPL-2.0 等，Git 为 GPL-2.0，MuPDF 为 AGPL-3.0；ElyPDF 链接 MuPDF，其发行包整体仍须按 AGPL 履行，Linux 包的许可字段据此写为 `MIT AND <引擎许可>`。