https://bugs.documentfoundation.org/show_bug.cgi?id=155494
--- Comment #13 from William Friedman <[email protected]> --- Thank you, Attila, for the detailed response. I have never used MS Word in any sustained way (or, for that matter, in any occasional way), so I can't speak to their design choices. In one of the threads I read related to this matter, someone made a general point about how LO shouldn't merely mimic Word when Word's implementation of something is bad. I agree with that point, and if this is indeed how Word handles extra spaces entered at the end of the line, then I think Word's implementation is bad, too. I want to address what you wrote here: "we want to be able to hit more spaces, but we want to see as there would be no spaces there .. some cases we want to be able to move into it.. some cases we don't.. we dont want to break line because of them.. but if you put 1 letter in the middle, then suddenly show the spoaces at next line, and change its behaviour..." My first question is *why* "we want to be able to hit more spaces, but we want to see as there would be no spaces there." Why *not* treat spaces entered at the end of the line exactly as any other text character, wrapping to the next line and inserting spaces just as if someone typed a long string of "a"s or whatever? Until I can understand why anyone would "want to see as there would be no spaces there" I can't really relate to the controversy. The fact that spaces are not shown until a letter is inserted, which "change[s] its behaviour" seems like argument enough that not displaying and treating spaces at the end of lines as regular characters is a poor choice. My simple feature request, then, would be to treat spaces like any other text character, that they wrap to the next line and continue to be inserted at the margin. I hope you or someone else can explain why this solution would be bad or negatively affect use cases that I can't currently think of. Whether or not my suggestion is wrongheaded or naive, I think the current implementation is worse than the old implementation where extra end-of-line spaces would simply move the cursor to the beginning of the next line and not display the added spaces. Beyond the bizarre visual artifact of going beyond the margin -- which, if more spaces are added, continues until the cursor itself is no longer visible, this implementation causes problems in Tables (and, I imagine, multi-column pages) when spaces cause the cursor to appear in the next cell, despite still changing the original cell. The implementation is also problematic because selecting the entire line with spaces that go beyond the margin only visually selects until the margin, even though the extra spaces are selected as well. In addition, try the following steps, which initially drew my attention to this issue: 1. Right justify LTR text. 2. Type spaces at the end of the line (or a line of spaces). 3. Notice that the cursor disappears entirely, rather than going beyond the line. I hope these issues will at least push for a reconsideration of this new implementation, and at best, lead to accepting my suggestion that spaces be treated as ordinary characters. -- You are receiving this mail because: You are the assignee for the bug.
