editable
editable copied to clipboard
使用 Cmd + 右方向键,光标不会定位到当前行的最后一位,而是下一行的首位
Description 在官方 Playground 中,使用 Cmd + 右方向键,光标不会定位到当前行的最后一位,而是下一行的首位。这与 word、slate 等主流编辑器的行为是不一样的。
Recording
这是 editablejs 的行为,定位行尾时到了下一行:
这是 slatejs 的行为,注意看光标位置,能够在一行内首尾切换:
Sandbox 在官方 Playground 即可复现,因为英文单词直接存在空格,效果不明显,使用中文复现效果更佳。
Steps
- 输入一大段中文或无分割的英文字母,让内容自然折行
- 将光标定位到行中间
- 反复使用快捷键: Cmd + 左 和 Cmd + 右
- Cmd + 左可以定位到行首,但是 Cmd + 右却定位到下一行的行首,而不是当前行的行尾。
Expectation
- Cmd + 右 能和 word、slatejs 等主流文本编辑器一样,能把光标定位到行尾。
- Windows 上支持 end 和 home 快捷键,功能与 Cmd + 左、Cmd + 右 一致
Environment
- Editable Version: 我猜应该任意版本都有问题,
- Operating System: Macos(理论上 Window 中 end 快捷键也能复现,但是貌似 editablejs 未支持该快捷键)
- Browser: Chrome, 我觉得任意 PC 端浏览器都能复现
Context 我猜是 editablejs 使用的 slatejs 作为选择位置状态,而 slatejs 因为浏览器天然第支持这个功能,所以即便是选择位置在下一行的行首,也会显示到这一行的行尾。而 editablejs 因为是自己做的光标展示,所以无法实现这个功能。 所以 editablejs 是不是应该增加一个额外的状态 —— 光标当前选择的位置:
- 当前的字符的前面
- 当前选择字符的上一个字符的后面
这样就能对齐浏览器自身的行为。且在上一个字符的后面时,对 Cmd + 左 的行为改为是跳到上一行的行首。这样改动应该是最小的。
发现除了 Cmd + 右外,还有很多场景与 word 不一致,例如:
- 点击一行的最后一个字的右侧,editablejs 的光标会下一行;而 Word 等主流行为是该行末尾
- 光标在一行的倒数第二个字符处,然后点击右,editablejs 的光标会下一行;Word 等主流行为也会移动到下一行;而 VSCode 等个别编辑器,光标会留在当前行的末尾。