中文
我们需要决定 TUI 默认如何处理鼠标。
目前 TUI 开启了 mouse capture，以便可靠接收滚轮事件。代价是终端通常无法再用普通拖拽建立原生文本选区，这正是 #347 报告的问题。鼠标点击需求（#35、#130、#342）也依赖 mouse capture。
在当前 crossterm 输入模型下，我们无法可靠地“只捕获滚轮，同时把普通拖拽留给终端”。因此这里需要做一个产品选择，而不是悄悄替所有用户决定。
如何投票
下面有三条投票评论，分别对应三个方案。请只给你支持的那一条点 👍。如果你的选择取决于默认值、终端类型或 SSH/tmux 使用方式，也欢迎留言说明。
粘贴问题（#12、#312）是另一条技术链路。无论本次投票选择哪种鼠标策略，bracketed paste 和长文本粘贴都可以独立修复。
English
We need to decide how the TUI should handle the mouse by default.
The TUI currently enables mouse capture so it can receive scroll-wheel events reliably. The tradeoff is that terminals usually cannot create a native text selection with a normal drag, which is the problem reported in #347. Mouse click support requested in #35, #130, and #342 also depends on mouse capture.
With the current crossterm input model, we cannot reliably capture only the wheel while leaving normal drag selection to the terminal. This is a product choice, so we would like users to decide it openly.
How to vote
There are three poll comments below. Please add 👍 to exactly one option. If your answer depends on the default, your terminal, or whether you use SSH/tmux, please leave a comment as well.
Paste behavior reported in #12 and #312 is a separate input-path issue. Bracketed paste and large-paste handling can be fixed independently of the mouse policy chosen here.
Related issues / 相关问题
感谢 @Polaris-F、@aldev814、@msuadOf、@meichuanyi、@lonelymeko 和 @coder-movers 提出这些问题并参与讨论，也感谢 @lichengzhe 早期实现滚轮支持。
Thank you to @Polaris-F, @aldev814, @msuadOf, @meichuanyi, @lonelymeko, and @coder-movers for raising these issues and joining the discussion, and to @lichengzhe for the earlier scroll-wheel implementation.
中文
我们需要决定 TUI 默认如何处理鼠标。
目前 TUI 开启了 mouse capture，以便可靠接收滚轮事件。代价是终端通常无法再用普通拖拽建立原生文本选区，这正是 #347 报告的问题。鼠标点击需求（#35、#130、#342）也依赖 mouse capture。
在当前 crossterm 输入模型下，我们无法可靠地“只捕获滚轮，同时把普通拖拽留给终端”。因此这里需要做一个产品选择，而不是悄悄替所有用户决定。
如何投票
下面有三条投票评论，分别对应三个方案。请只给你支持的那一条点 👍。如果你的选择取决于默认值、终端类型或 SSH/tmux 使用方式，也欢迎留言说明。
粘贴问题（#12、#312）是另一条技术链路。无论本次投票选择哪种鼠标策略，bracketed paste 和长文本粘贴都可以独立修复。
English
We need to decide how the TUI should handle the mouse by default.
The TUI currently enables mouse capture so it can receive scroll-wheel events reliably. The tradeoff is that terminals usually cannot create a native text selection with a normal drag, which is the problem reported in #347. Mouse click support requested in #35, #130, and #342 also depends on mouse capture.
With the current crossterm input model, we cannot reliably capture only the wheel while leaving normal drag selection to the terminal. This is a product choice, so we would like users to decide it openly.
How to vote
There are three poll comments below. Please add 👍 to exactly one option. If your answer depends on the default, your terminal, or whether you use SSH/tmux, please leave a comment as well.
Paste behavior reported in #12 and #312 is a separate input-path issue. Bracketed paste and large-paste handling can be fixed independently of the mouse policy chosen here.
Related issues / 相关问题
感谢 @Polaris-F、@aldev814、@msuadOf、@meichuanyi、@lonelymeko 和 @coder-movers 提出这些问题并参与讨论，也感谢 @lichengzhe 早期实现滚轮支持。
Thank you to @Polaris-F, @aldev814, @msuadOf, @meichuanyi, @lonelymeko, and @coder-movers for raising these issues and joining the discussion, and to @lichengzhe for the earlier scroll-wheel implementation.