GNOME Bugzilla – Bug 750636
Wrapped line should not start with a space
Last modified: 2018-09-04 16:59:15 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1228962 Version-Release number of selected component (if applicable): evolution-3.16.2.1-2.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. In composer, in normal mode, type a line of text long enough to wrap. 2. At the point where the wrap occurs, add whitespace. 3. Actual results: Some whitespace appears at start of wrapped line. Expected results: Whitespace at start of wrapped line is suppressed. Additional info: Split occurs with an even number of spaces, but not an odd number, and only the last space is on the new line. Once there are nine spaces, all additional spaces wrap to the new line. Regression from the version in FC21. Very bothersome for those of us that double-space between sentences. ---------------------------------------------------------------------------- Is this what you want, to not start a line with a wrapped white-space, please? ---------------------------------------------------------------------------- That's correct. The whitespace can (should) be left on the previous line, but a wrapped line should never start with whitespace. (In case of a new paragraph, the preceding line would end with a hard return and the writer would put the indentation in explicitly, or the writer would include vertical whitespace.)
Created attachment 310894 [details] Testcase Test case that can be loaded in GtkLauncher (WK1), MiniBrowser (WK2) or any other browser. WK1, WK2 and Chromium are consistent in following behavior: if caret is moved and the end of the second line and pressing the Space key here inserts new spaces on the beginning of the third line and on next space removes it (the space is moved to the end of the second line) until the free space on the second line is filled with whitespaces. Firefox is handling this case correctly. So this is out of scope of Evolution, so I propose it to close it as NOTGNOME.
The behavior in Firefox is different from the behavior in Evolution Composer. In Composer[1], the first space between 'nec' and 'odio' is converted to a newline. Adding a space between 'nec' and 'odio' inserts the space at the beginning of the line with 'odio'. The next space added moves the two space characters to the end of the line with 'nec'. The next space is inserted at the start of the line with 'odio'. After the fourth space, all spaces are added at the beginning of the line with 'odio'. In Firefox, the wrap occurs between 'Praesent' and 'libero'. The first space appears at the end of the 'Praesent' line, followed by a newline. The second space also appears at the end of that line, The next space pulls 'Praesent' to the start of the next line and adds the space. Then additional spaces are added on that line between 'Praesent' and 'libero'. The Firefox behavior is what I would consider expected, and I am proposing that Composer should follow that convention. [1] In my display. In yours, I suppose the line break may occur elsewhere, depending on font size.
(In reply to mjs from comment #2) > The behavior in Firefox is different from the behavior in Evolution Composer. As I previously wrote: "Firefox is handling this case correctly." The problem is that Evolution uses WebKit as its rendering engine not Firefox.
(In reply to Tomas Popela from comment #3) > (In reply to mjs from comment #2) > > The behavior in Firefox is different from the behavior in Evolution Composer. > As I previously wrote: "Firefox is handling this case correctly." > > The problem is that Evolution uses WebKit as its rendering engine not > Firefox. So should this bug be refiled against WebKit?
How can we possibly consider such a major functionality issue as this to be not-my-problem? (or normal priority for that matter) This, along with the other bugs I've commented on, is driving away long time users like me from evolution. I don't like my emails to look like crap. Regardless of whether it's a WebKit bug or not, it makes this product unusable. Please, let's either drive the issue with WebKit, find a workaround or replace WebKit, but I'm trying as hard as I can to find an evolution replacement at this point, so please do something.
(In reply to Alex Williamson from comment #5) Please take a step back. > How can we possibly consider such a major functionality issue as this to be > not-my-problem? (or normal priority for that matter). I don't say it is not our problem, but now it is out of scope for us (mainly lack of time for Evolution development on my side). Things could improve once we port Evolution to WebKit2 as WebKit1 (on which Evolution is based) is not developed at all.
I hope there are some users left by the time these issues can be addressed.
At least for the trailing white spaces when these are wrapped: Created commit 7a9d481a3f in evo master (3.29.4+) Created commit 232589cc84 in evo gnome-3-28 (3.28.4+)
I think I found a new corner case, it's in combination with long URLs: a) plain text mode b) type: prefix text https://www.gnome.org/1234567890123... after text where '...' is replaced with more numbers, to make the URL at least 72 letter long (to occupy the whole line on its own). Then the resulting text looks like: prefix text https://www.gnome.org/1234567890123... after text The space before the 'after' word is wrong. There are some related things to mention, especially about the long URLs wrapping (bug #757504), due to [1] the text shown in the composer doesn't match the output on send. [1] https://gitlab.gnome.org/GNOME/evolution/issues/71
Extended fix for the wrapped anchors: Created commit 8794abbc99 in evo master (3.31.1+) Created commit f9ceddb667 in evo gnome-3-30 (3.30.1+)