Your comments
I'm seeing this as a problem too, on Textastic 2.0 as bought and installed today. I'm working on a 21K text/markdown file, in editing prose. Why that may be relevant is of course that the *logical* lines (ie: separated by newline characters in the text) equate to paragraphs, and as such are soft-wrapped (using 80-column width) and can take up tens of lines; then editing in the middle of that is quite sluggish. On the plus side, while touch-typing on a wireless keyboard, it doesn't seem to lose keystrokes as it catches up, so buffering is working.
There's still a noticeable delay when typing at the end of text; early days to tell for sure if it's faster than or as bad as editing long paragraphs higher up.
There's still a noticeable delay when typing at the end of text; early days to tell for sure if it's faster than or as bad as editing long paragraphs higher up.
There are existing ssh client applications in the app store; I already have iSSH, iTeleport, TouchTerm and Server Admin that do this; so presumably this is just a matter-of-time thing than anything that's likely to be a serious blocker. :-) I've only just heard of this app (linked to from TextMate forum), and am very likely to be buying it shortly, but SFTP support instantly makes it far more useful, so a big +vote from here. :-)
Customer support service by UserEcho
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.)