zufuliu
行中空格恰好位于换行行尾时，没有显示出来
我明白你的意思，空格依然是存在的，但是你没有理解我的意思，我的意思是现在这样的处理逻辑是无法让人意识到这里是有一个空格的，我认为更好的逻辑是到“第一组 1”的末尾之后，再让光标向后移动一位是空格，光标在空格之后，之后再让光标向后移动一位是第二行的第一个 1 之后。
我粗略试验了一下其他编辑器对这个问题的处理：
1 Github 的编辑框，移动光标时的处理逻辑和现在的 Notepad4 一致，但是可以选定到空格之后。
2 这是 IDEA 的处理逻辑，移动光标和位置选定都可见空格，只不过光标移动到下一行是到第一个 1 之前。
Unicode Line Breaking Algorithm https://www.unicode.org/reports/tr14/#SP
The space characters are used as explicit break opportunities; they allow line breaks before most other characters. However, spaces at the end of a line are ordinarily not measured for fit. If there is a sequence of space characters, and breaking after any of the space characters would result in the same visible line, then the line breaking position after the last space character in the sequence is the locally most optimal one. In other words, when the last character measured for fit is before the space character, any number of space characters are kept together invisibly on the previous line and the first non-space character starts the next line.
Unicode Line Breaking Algorithm https://www.unicode.org/reports/tr14/#SP
这个规定的意思应该是说换行行尾有多个空格的情况，只显示为一个空格吧？下一行从第一个非空白字符开始，我现在用的笔记本软件就是这样处理的。但是问题是会吞掉一个空格，三会变成二，二会变成一，一也会变成零
- 这才是显示空格：浅红色圆点。
- 那里只有一个位置，光标能放两个位置才不合理吧？两个光标位置之间，不应该是有东西的吗？
- 并没有吞掉空格。是可以选中的（有背景色）。要真切反映空白字符，需要转换成可视的，低一档的方式，观察选中的表现，再低一档的，观察用键盘移动光标的表现。
PS: 你的“选中”和“显示”的定义不太对啊
具体来说，作者描述的是这个问题：
在这张图片中，光标在A后面时往右移动，会跑到下一行B的前面
事实上，这和空格没有关联，因为这张图也能复现这个问题 实际问题是，没有办法将光标定位到【A的末尾】，它要么位于A之前，要么位于下一行的B之前 而浏览器（Github编辑框）可以，IDEA也可以 浏览器的行为和Notepad4相同，但是额外的，可以使用鼠标将光标移动到A之后，只是视觉上，实际上和上述【B之前】处于相同的位置。 IDEA的把软换行看成一个字符，光标在A的末尾继续移动，会移动到下一行B之前，就像softwrap的换行是一个特殊字符
Thanks @roj234 👍
When no wrap occurred, caret position after space is before B.
After wrap, caret position after space is still before B, but on next subline line instead of the subline where last character (space in this case).
CC @nyamatongwe, tested virtual spaces options (the document could be updated to use a table for these flags) at https://www.scintilla.org/ScintillaDoc.html#SCI_SETVIRTUALSPACEOPTIONS, no one works.
问题就在于，不转换成可视符号之外的感知空白字符的方法，是间接推导法，就像很多错觉图一样，你的第一感觉错了。 当光标既可以在软换行前一行的行尾，又可以在软换行后一行的行首时，不显示行号和控制字符的，会造成和真换行分不清。 把问题表述并分析清楚而已。还不能提啦？
tested virtual spaces options (the document could be updated to use a table for these flags) at https://www.scintilla.org/ScintillaDoc.html#SCI_SETVIRTUALSPACEOPTIONS, no one works.
Added table with https://sourceforge.net/p/scintilla/code/ci/e64769e07e21f6cc73afd5e1c7eada6200a2eb01/ .
Virtual space is currently not possible inside a document line, only at the end. Emulating a virtual soft line break character would be complex.
An option to draw the caret at the end of a wrapped display line instead of the start of the next line would be possible. Another possibility would be an option to draw the caret (or an alternative split caret) at both the end of the wrapped display line and the start of the next display line. Any change would have to account for both drawing and invalidation and maybe other aspects such as hit testing for mouse actions. The potential benefits need to be weighed against the cost of adding complexity and maintenance.
There are some options for showing whitespace SCI_SETVIEWWS and this could be expanded to show whitespace at the end of wrapped lines or at the end of all lines.
draw the caret at the end of a wrapped display line instead of the start of the next line would be possible.
VSCode and Sublime Text does this, and move caret after B when press left arrow again. VSCode can put caret before B (on second subline) with manually click, where Sublime Text can't.