I decide to make a real wrap word => disable all wrap when we disable "wrap word" because if we do it "wrap to the border" when we insert a big url it's wrap and send as wrapped
=> we can't never click on full url (it's a bug in qt)

How did this work before 4.7.2?  I have been using kmail for around 7 years and not once have I ever used any word wrap except on the border and have never experienced the long url issue, and have sent plenty of them through the years.

How does using word wrap handle this issue then?  It would seem like the same problem.

So it looks like I am stuck with either sticking with 4.7.1 for eternity, or always have an extremely short word wrap of 78 chars or less?

Every other email client in the world, including kmail up to this point has this support.  IMHO I find it amazingly difficult to think this is a good decision, that if you don't have word wrap enabled you just have one long line until you hit return.

"have never
experienced the long url issue, and have sent plenty of them through the years."
a lot of users have it, and I have it.
So it was a bug.

" IMHO I find it amazingly difficult to think this is a good
decision, that if you don't have word wrap enabled you just have one long line
until you hit return."
you define "no wrap word" so it's not an error.
If you want a wrapping use wrapping.


And for me it's more critical to not be able to send an email with a long url that don't wrap a text when we decide to no wrap.

OK, so there is a bug with it some how, I just haven't seen it, I can believe that.

So does this bug exist when using word wrap now?

The problem I have is I send code and output from code all the time that is much longer than 78 chars.  So doing a hard wrap there messes up the output, but having it do the previous soft wrap seemed to work just fine, where the receiver can just make their window larger to see the unwrapped text.

I am still confused why doing a soft wrap (meaning wrap on boarder) isn't possible, or how it messed anything up in the first place.  I am curious how the hard wrap method handles this scenario as well.

I appreciate your time and your explanations.  I just don't want to have to switch clients, or have to continually turn on and off the word wrap option.  I would be surprised if I was the only person seeing this issue.

The dynamic word wrap functionality worked fine for me in the previous releases. I used it heavily because I need to send long URLs. And the URLs always worked on the receiving sides. I can confirm that the long URLs were sent WITHOUT line breaks when I enabled dynamic word wrapping.

It is really a pity that the dynamic word wrap is not existing anymore in the recent version of the kmail2 composer. This forces me to use an external editor, which supports dynamic word wrap. A really inconvenient work-around and not really what I expect from an email composer. 

Are you sure that your problems with long URLs really originated in dynamic word wrap? Every simple text editor (also qt based, such as kate) provides dynamic word wrap in the windows without introducing actual line breaks in the files...

I'd appreciate, if you rethought your decision and enabled dynamic word wrapping again. I agree with Danny that this is an issue for many people.

Hi Laurent,

might I also ask you to re-think your decision? Everybody in KDE-land lived with the expected behaviour that Danny describes for years (10 for me). I, personally, have never noticed any issues with long URLs - is it true that a soft break that only exists in the editor window *display* could corrupt the URL? I'll check next weekend on another machine with KDE4.6, can't believe.

The "fixed" behaviour now is just crazy. Every paragraph I write in my e-mail is one single line only (that extends to many many times the window width and requires extensive horizontal scrolling). This is crazy from a usabiltiy standpoint!
Of course, I can switch to fixed linebreak at 78 but this is not what I want. The receiver's mail client should decide when to break the lines - a smartphone is much different from a 16:9 widescreen... Same goes with me when composing the text - way different between Netbook and Desktop. 78 for everything is not the solution!

Please revert the change or think about a solution that fixes the URL problem without breaking basic mail editing functionality...

Thanks
Tobias

Vote for reopening and fixing this issue! Kate and KWrite have the option "Dynamic Word Wrap" ant don't have problems with long urls, here is example screenshot: http://wstaw.org/m/2011/12/15/plasma-desktopyJ4399.jpg

And here is this text in kmail2 composer: http://wstaw.org/m/2011/12/15/plasma-desktopky4399.jpg

If you don't want to fix this globally, please do the option in settings!

This issue not fixed!

I think KMail use "static" wordwrap instead "dynamic". For example:
1. http://wstaw.org/m/2011/12/20/snapshot105.png kate don't breaks text lines!

2. http://wstaw.org/m/2011/12/20/snapshot106.png - Message from first snapshot looks perfectly in gmail, kmail .. everywhere!

3. Reply message without wordwrap http://wstaw.org/m/2011/12/20/snapshot108.png and  with wordwrap http://wstaw.org/m/2011/12/20/snapshot109.png
And the result: http://wstaw.org/m/2011/12/20/snapshot110.png

4. After about 5 replies or more our quote looks like shit - http://wstaw.org/m/2011/12/20/snapshot111.png - THIS IS WRONG! Wordwrap must change only how message display, but not change original message and add new line symbol.

By the way, Kate have 2 options: http://wstaw.org/m/2011/12/20/snapshot112.png
"Dynamic" wordwrap in "Appearance" section and "Static" wordwrap in "Editing" section. Dynamic wordwrap it is only APPEARANCE!

Hi botan,

the Options -> Wordwrap in KMail Composer (Snapshot 108) has always toggled the static word wrap. No option for dynamic wrap.

Before the infamous URL "bugfix" in 4.7.2, dynamic word wrap was always on (and functional) by default. Don't see a reason why someone would not want dynamic word wrap in an e-mail composer window (not the place for source code or similar stuff where dynamic word wrap would harm).

I agree it would be nice to have both options (as in Kate) but reverting the URL "bugfix" would probably also do for most users and be almost zero effort.

Could anyone more familiar with KDE bug tracker tell us if voting for a "Wontfix" bug as proposed by Murz will work or should a new bug report be opened and voted for?

Thanks
xxtobi

*** This bug has been confirmed by popular vote. ***

The code already exists to _display_ a message with dynamic line wrap, both in a separate window and in the bottom pane of the main display. It doesn't break URL's when it wraps either. Seems like a pretty trivial task for a capable coder to provide the same behavior in the composer window. It sure would enhance the user experience and keep Kmail2 in the 21st century with its competitors. If others could figure out how to do dynamic word wrap and not break URL's, seems like Kmail2 programmers could also.

I wonder will the dynamic word wrap be re-enabled? Quite annoying thing (and I do not want to use static word wrap).

Can someone please reopen this issue? There seems to be a consensus: the change should be reverted to reactivate dynamic word wrap.

Were there any votes to change this feature from the original behavior?

If not, please revert to previous and submit the suggested change to a vote.

That is the way things are supposed to work in Open Source isn't it?

I liked dynamic wordwrap as well. I still use KMail from KDEPIM 4.4.5 together with KDE SC 4.7.4 cause Debian Qt/KDE packagers have not yet officially packaged KDEPIM 2. So I still seem to have dynamic wordwrap.

There is a workaround for this, although it is suboptimal and error-prone:
turn hard wrap on while typing, and turn it off before you send. Hard wrap actually is applied only at sending.

Bug 288882 is another bug report, so vote there before it is closed...

Thanks Martin for pointing to the other bug report. Vote submitted.  Let's hope that #288882  gets more attention than this one.

Bug 288882 was already confirmed by votes today :)

This "solution" seems to me like cementing the whole garden because you have had some issuses with moss in the lawn... or like bricking up all windows in an apartment building because some people complained about wind noises...

At least for me an editor really is not usable without dynamic line break... I really hope you find another solution to fix the url issuses some people encountered.

I agree. This "fix" never should have been committed - it is just an ugly hack, and renders the editor completely unusable for many people and makes it less uncomfortable for many others. I have to write my messages in another editor because of this.

Proper fix is to add support for dynamic and static word wrap like in kwrite or kate along with "no word wrap" mode. Currently we have only static word wrap at 78 symbols (why 78 symbols limit and not 200 like in kate/kwrite?) and no word wrap at all.

Previously we had static word wrap and dynamic word wrap (the most usable mode for writing e-mails). Why remove it instead of adding an option "no word wrap" for people who need it? By the way, almost nobody needs it, and even who do need it, do not need it most of the time. For example, I send long URLs in the e-mails pretty often, and nobody complained to me about broken URL (and I was using KMail without this "fix" for a long time, but upgraded recently). So this problem with "broken URLs" is greatly exaggerated, and definitely not a reason to make whole editor uncomfortable/unusable by committing ugly hack instead of the proper fix. Static word wrapping damages formatting of almost every e-mail message which is much worse than very small possibility of wrongly formatted very long URL.

Dynamic wrapping is must-have for any real-world text editor. Even simple command-line editors like nano have this capability.

Long URLs can also be embedded into a link (if you use html for writing emails), which is more readable anyway...

Hi all,

some good news (proposed fix) over at Bug 288882 - pleas VOTE :-)

Cheers
xxtobi

I can confirm that proposed fix actually works. Not only composer becomes actually usable after applying the patch from Bug 288882, but also I was able to successfully send very long URL with slashes, dashes and other symbols in it, and it remained intact and clickable in the sent message.