https://bugs.documentfoundation.org/show_bug.cgi?id=155494
--- Comment #61 from William Friedman <will.fried...@gmail.com> --- > IMO, instead of the spaces over margins, our usual metaphor for text not > fitting to the space - which is a red triangle showing "more content outside > of the bounds" - could be used instead. Cf. to a fixed-size table cell / > frame, having too much text. I think either this or the solution you offered in comment 59 is superior to the current behavior, and would more closely match the original request in bug 104683. (Which the patch which causes this behavior was intended to solve, but IMO does not.) If it were possible to add a counter as was originally requested there, all the better (see below). > However, the cursor would still not move to the next line immediately, since > it will walk through every space in the hidden space run. It is IMO the only > sane behavior - skipping all the whitespace at once is inconsistent. This is the core issue. Prior to the change resulting from the "fix" to bug 104683, as soon as a space invisibly traverses the margin, the cursor would go to the next line and remain "stuck" there if additional spaces were added until a non-space character was entered. I happen to prefer that, because at least it indicated clearly where the next non-space character would go. I don't think there's a clear "sane" choice in this case, because I think that *every action that changes text should result in some visual indication that text is being changed.* This principle is violated both by: 1) freezing the cursor at the end of the line when pressing the space bar invisibly inserts spaces past the margin, *and* 2) by freezing the cursor at the beginning of the following line when pressing the space bar invisibly adds spaces to the previous line. That is why I think a counter would be superior to a static visual indicator that there is "something" invisible; it would indicate that changes are being made. > > > The question of how the spaces are actually treated is a secondary > > issue to this bug. > OK - got confused then by the text in comment 0. But then, are the bugs > marked as duplicates actually duplicates? You are right that in my "expected results" text I also conflated cursor movement with the internal treatment of spaces. Bug 155935 is a duplicate since it relates only to cursor movement. Bug 158082 requests that spaces move to the next line, which was the second part of my request rejected here, which I suppose is NAB. (But I don't think you're right that the current standard treatment of spaces is particularly desirable, nor that the number of users cc'ed on a bug report reflects anything about the desires of the larger user base. For a complaint about this going back to 2015, which requests a change that violates the standard, see https://bugs.documentfoundation.org/show_bug.cgi?id=43100#c6.) -- You are receiving this mail because: You are the assignee for the bug.
