0
Planned

Soft-wrap bug puts spaces at start of line

Rachel Greenham 13 years ago updated by Alexander Blach (Developer) 13 years ago 3
With a file containing blocks of prose text, as opposed to code, sometimes the soft-wrapping causes a space to be shown at the start of a line mid-paragraph; this happens when the text on the previous line exactly occupies the configured line width; ie: if the line width is 80, and the previous displayed line in a paragraph has exactly 80 chars, the space separating it from the text of the next line is itself wrapped to that next line. What should happen is that the last space on a line should be 'allowed' to break the line width restriction so the next word starts as expected at the start of the next display line.
Interesting. I just tried how TextMate and TextWrangler/BBEdit handle it and they indeed do what you wrote. I didn't know that this is the way it is implemented in other text editors.

So, technically, this is not a "bug", as this behaviour was intended by me :)

But, I'll see if I can change the behaviour in an update. I guess the same should happen with tabs?
Hmm, textmate is my primary editor when on a mac, and I never noticed it there...

fx: tries it, looking for it... Nope, I can't excite it on textmate, with soft wrap enabled (as you'd expect for editing plaintext prose).

Unknown for TextWrangler/BBEdit, I don't use those.

BTW, on this: "I didn't know that this is the way it is implemented in other text editors." Please don't take my word for it that what I described ("What should happen is that the last space on a line should be 'allowed' to break the line width restriction...") is actually how the desired behaviour is modelled in other editors that don't show this fault. It's just my random thought, with no experience of writing text editors, that that's how it might be done. It might be more that a 'soft' space (ie: a normal space) just has behaviour to it that's distinct from any non-whitespace character, or indeed a 'hard' or non-breaking space character; that those rules define wrapping but also that if they *are* wrapped on, essentially are consumed by that; ie: for the purposes of rendering the text, becoming a linebreak *instead* of a space. IYSWIM. :-)

As for tabs... I would concentrate on what works best for code-editing purposes, as putting tabstops in free-flowing (and more to the point freely re-flowable) prose anywhere other than at the start of a paragraph is fairly nonsensical. (Even *at* the start of a paragraph it's quite an anachronism.)
Maybe you got me wrong (or maybe I misunderstood you). I just wanted to say that two popular editors on the Mac (TextMate and TextWrangler) wrap lines just like you expected. They don't wrap spaces at the end of a line. TextMate does this for all whitespace characters (spaces and tabs). When you set a wrap column in TextMate (View -> Wrap Column), you can enter as many spaces as you want but it will only break the line as soon as you enter a non-whitespace character.

Textastic on the other hand currently always wraps the line at the specified column, even if the line ends in whitespace characters.

I'm going to change the behaviour in Textastic to what popular editors do.