对 xxx 的希望

你可以从此处看到我的事物观念。

查看政治性内容请前往愿景。

对 vim 的希望

当然这些都是通过自定义化可以解决的问题，但是我觉得这些东西可以变成 vim 的默认设置而不是自定义设置。

• visual 下按 (,[ 等括号类可直接为选中区域添加闭合括号。
• 保留非 vim 的 Ctrl 组合键功能，例如复制粘贴等。
• 删除选中区域时不复制到剪贴板。（区分删除和剪切）
• 更改指令查找替换方式（太麻烦了），直接搜索高亮，然后选择其中的一些或全部，进行直观替换。（这要求一个新 mode）
• 增加 保持光标 与 新建光标 功能，并可任意移动任一光标，方便随机修改。

对移动端剪贴板的希望

桌面端剪贴板有 ditto

无论是国内输入法的长时间保存剪贴板，还是谷歌输入法的一小时后删除的剪贴板，都有其取舍与不便之处。我选择折中说——

• 剪贴板数据永久保存仅文本数据，可手动访问，而应用对剪贴板的访问通过条数来限制。（例：仅能访问最近一条）

对浏览器的希望

• 原生支持 ts when
• 参考一下人家 Arc 的设计理念

对计算机教育的希望

绝大多数的大学，计算机教育就是一坨屎。本段为纯粹的发泄段。

• 取消思政课
• 取消大学物理，大物实验，数字电路
• 使用最新的编程语言版本与工具链

对编程语言的希望

• 完整的 oop (class + interface / trait)
  • interface / trait 提供了自由组合，在泛型中具有极为强大的作用。只依赖虚函数继承的纯 class 不够完备。
• 充分的内置数据类型 (dict, tree and map)
• 清晰的所有权机制 (rust, 我们不要学 c++)
  • 并且可以选择是否使用 gc (import gc)
• 完善的包管理与二进制编译 (cargo, minimize release bin)
• 提供最高的自由度 (可以直接操作 pointer)
• 所有错误均为可恢复错误 (python)
  • 尽可能减少 undefined behaviour。ub 可以增加性能
• 通过 io 暂存变量 便捷的 serialization 支持
• 高度模块化
• 支持对函数式编程的优化，例如热更新 (hot-reloading)
  • 区别函数 (function) 与闭包 (closure)，推荐使用链式调用
• 自由选择静态类型与动态类型 (ts, any)
• 充足的语法糖 (js, kt)

可能算是各语言优点的融合怪。。不过确实不是很现实捏~

对算法竞赛 & OJ contest 的希望

• 支持所有主流语言的所有主要版本。（主流语言至少得包括 15 个吧，版本得支持最新标准，C++ 得支持多编译器吧）
• 提交后即时出结果。（I love IOI，这个是根据赛制决定的。然而我不喜欢非实时的赛制。）
• 样例必需具有典型性与足够的数量级。（出题人，您也不想您的母亲被人问候吧，）
• 需要对至少不止一个样例作出样例解释。
• 提供快读模版，否则请留出充足的 io 时间。
• 检查点不包含样例数据。
• 对于 online 的非正式比赛，在任何时候（赛前、中、后）都应能够参加比赛做题。

对聊天软件/协议的希望

用了一堆聊天软件，脑子里已经有了许多清晰的认知。

首先这里解释一些概念：

• Organization(org)：最基本的管理单位

• 会话：Organization 下属的一个管理单位，可以是 simple processer multiple comsumer（频道/公告），oneshot（私聊），mpmc（群组）等。

• 基础设置都分为：全局设置，org 内设置，会话内设置。

• 分组！打 tag！

  • 分组是一种抽象，但是细分不能层次超过两层，即用户最多点击两次就能进入任何会话。目前的聊天软件基本都如此设计。
  • 以 Organization 为核心，单个 org 内能够创建不同的会话，并进行细致的权限管理。
  • 普通成员可以在 org 中创建任意个私密会话，并加入 org 中的成员，私密会话对未加入成员不可见。也就是将所谓的“拉小群”功能集成到 org 本身。

• 多取一功能：对 org 内的一部分人@，而其中的任一一人回复，就会取消这个@对其他人的高亮提醒。

• 能够创建单条消息引用链接和多条。

• 需要完美的上下文定位功能。（这点现有聊天软件都做的很差）

• 支持较好的全局搜索功能（CJK）。

• 永久云端保存文本聊天记录，本机保存媒体。

  • 或者，静态文件以 hash 标识，唯一来源激励，人工响应判重系统，有效转发延时。

• 支持类正则式 pattern 屏蔽，按成员屏蔽。

• 完整地支持 markdown。（telegram 差了点）

• 支持自定义排版样式，html 或自定义排版语言。

• 设置是否允许其他人看到已读状态

• 提供 bot api

• 端到端加密压缩，节省存储空间与流量

  • org 内分发公钥

对推荐算法的希望

点名 B 站。

• 开源透明，任何人可管理自己的喜好。
• 提供喜好管理面板，可随时添加或删除。
• 算法以 tag 而不是某一类型视频作为推荐依据。
• 在面对一个被推荐的 tag 时，用户可选择：
  1. 封禁此 tag 半年 / 一个月 / 永久
  2. 减少此 tag 出现频率半年 / 一个月 / 永久
  3. 增加此 tag 推荐频率半年 / 一个月 / 永久
  4. 大幅增加此 tag 推荐频率 15 天

对翻译协作平台的希望

翻译平台我只用过 Crowdin 和 WEBLATE，当时已经有了一些想法。最近我和 Asuka Minato 被 GitLocalize 恶心到了^[1]，于是我开始深入思考一个好的翻译平台需要做到哪些东西。

• 接入机翻预翻译支持，人工润色，可以轻松很多。
  • 机翻本身质量不要太差。Google, deepl 都行，其他的得具体分析。
  • Crowdin 的机翻就不太够。
• 细粒度的协作，特别是志愿翻译更需要做到这一点。能够将翻译精确到句子，即可以只翻译这一句话，而不是整个文档。通过分散目标，能够充分调动译者的积极性，并且容易让更多的人参与。
  • 我本来是想为某项目翻两句的，然而它用的 GitLocalize 不支持细粒度，导致我没有动力而直接放弃。（毕竟是个我自己都不用的项目）
• 对他人的翻译做出修改与评价（评分）。
  • 对于大众翻译，译者的水平不尽相同。
  • 在不同场景下有不同的翻译需求。文档一般没有太多翻译空间，但是对于文学作品来说，听取不同的翻译意见是很重要的。
  • 评价当然也需要是细粒度的（针对某句翻译评价）。
• 统一专有名词与关键词的译法。
  • 我最近在看的 Re0 文库版，里面的人名都不统一。特别是前面译 巴鲁斯，后面直接变成 864，我真的没绷住，太野鸡了
• 容易与项目集成/接入。这是开发者要考虑的选项，也是一个翻译平台被选择的大前提。如果为了 i18n 而要手动将文档内容（例如 md）转成平台的支持格式（例如 yaml 或 binary），我肯定会觉得痛苦然后放弃的。
• 翻译内容安全性。由于内容全部存在云上，这对云服务商提出了一些要求（实际上也是最基本的需求）。反应速度先不说，至少翻译的东西不能丢吧。
  • 记得本地留备份。^[2]

对 RSS 阅读器的希望

• 不要太大，不要 electron 那样内置浏览器。
• 具有浏览器扩展或者类似功能，可以选中网页元素，自动推断订阅源。例如 RSSHub 和 ireader。
• 订阅源分组/分 tag，高维度控制。
• 集成社交媒体的 bot（例：telegram），可以通过其发送 RSS 消息。
• 自动 AI 总结。