Version: 1.7 (using KDE 3.3.0, SuSE) Compiler: gcc version 3.3.3 (SuSE Linux) OS: Linux (i686) release 2.6.8.1 If one enters <tab>s at the start of lines, they count 8 spaces. After adding a signature, they are reduced to 1 space Create an ordered list and save (to template). After restoring the list formatting has gone away. Sometimes you can't add bold or italic markups by pressing the buttons, nothing happens.
The second issue has been resolved.
Hi, I think I found a bug in Qt. I found it because someone was complaining about KMail not sending tab characters. It seems that in revision 1.49 of qrichtext.cpp the change was made : In QTextParagraph::paint(), a tab character is changed into a space. When I delete the uc[(int)ii] == '\t' in for ( uint ii = 0; ii < qstr.length(); ii++ ) if ( uc[(int)ii]== '\n' ) || uc[(int)ii] == '\t' ) uc[(int)ii] = 0x20; the tab character gets saved (but maybe this has other consequences). Regards, Edwin Schepers.
The previous was sent to qt-bugs@trolltech.com The third issue has been solved too.
*** Bug 88157 has been marked as a duplicate of this bug. ***
On Saturday, 18. sep 2004 14:26 Edwin Schepers wrote: > Hi, > I think I found a bug in Qt. I found it because someone was > complaining about > KMail not sending tab characters. > It seems that in revision 1.49 of qrichtext.cpp the change was made : > In QTextParagraph::paint(), a tab character is changed into a space. > When I > delete the uc[(int)ii] == '\t' in > for ( uint ii = 0; ii < qstr.length(); ii++ ) > if ( uc[(int)ii]== '\n' ) || uc[(int)ii] == '\t' ) > uc[(int)ii] = 0x20; > > the tab character gets saved (but maybe this has other consequences). Hi Edwin, We are aware of this issue. The attached patch should solve the problem. Please try it out and let us know how it works out for you. The fix should also be in the latest snapshot. Best regards, Sigrid Trolltech AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway Created an attachment (id=7590) patch.diff
It seems there are many more bugs in kmail editor. When saving and restoring mails with attachments, often every NEWLINE is expanded to 2 NEWLINES. Italics and bold buttons don't work, ordered list are lost after saving and restoring...
*** Bug 90354 has been marked as a duplicate of this bug. ***
On Wednesday 22 September 2004 03:45, Edwin Schepers wrote: ... > Reading #86925, it could be that Don has a solution for this one. > Don ? My patch just changes from using <p> tags to using <br> tags. Let me try at home and get back to you. I couldn't reproduce any of the other bugs "When saving and restoring mails with attachments, often every NEWLINE is expanded to 2 NEWLINES. Italics and bold buttons don't work, ordered list are lost after saving and restoring...". I couldn't reproduce any of these problems. Don.
> > Reading #86925, it could be that Don has a solution for this one. > > Don ? > > My patch just changes from using <p> tags to using <br> tags. Let me > try at home and get back to you. > > I couldn't reproduce any of the other bugs "When saving and restoring > mails with attachments, often every NEWLINE is expanded to 2 > NEWLINES. Italics and bold buttons don't work, ordered list are lost > after saving and restoring...". I couldn't reproduce any of these > problems. Belonging to SuSE rpms I am always up to date, so maybe some bugs disappeared. I will try anew: Opening a new message and entering arbitrary, unformatted text, <RETURN> inserts a newline. Formatting a block instancing as an ordered list, and formatting back to standard, insertion of <RETURN> has changed to paragraph (2 newlines). Right now the italics button is grey, no chance to format any word this way. Ah, just yet I inadvertently saved this reply: the bold "instancing" (you see?) in the preceding paragraph survived, but every newline in the text above has changed to a newparagraph. And: after saving and restoring the italics button was activ, but selecting text and pressing the button results didn't change anything. Now the italics button is grey again. Colouring text doesn't work. When choosing colours in the dialogues colour wheel, RGB values toggle between 0 and 1 and the choosen colour is not took over. Kind regards Frank <html><head><meta name="qrichtext" content="1" /></head><body style="font-size:10pt;font-family:Misc Fixed"> <p>> > Reading #86925, it could be that Don has a solution for this one.</p> <p>> > Don ?</p> <p>></p> <p>> My patch just changes from using <p> tags to using <br> tags. Let me</p> <p>> try at home and get back to you.</p> <p>></p> <p>> I couldn't reproduce any of the other bugs "When saving and restoring</p> <p>> mails with attachments, often every NEWLINE is expanded to 2</p> <p>> NEWLINES. Italics and bold buttons don't work, ordered list are lost</p> <p>> after saving and restoring...". I couldn't reproduce any of these</p> <p>> problems.</p> <p></p> <p>Belonging to SuSE rpms I am always up to date, so maybe some bugs disappeared. I will try anew:</p> <p></p> <p>Opening a new message and entering arbitrary, unformatted text, <RETURN> inserts a newline. Formatting a block <span style="font-weight:600">instancing </span>as an ordered list, and formatting back to standard, insertion of <RETURN> has changed to paragraph (2 newlines).</p> <p></p> <p>Right now the italics button is grey, no chance to format any word this way.</p> <p>Ah, just yet I inadvertently saved this reply: the bold "instancing" (you see?) in the preceding paragraph survived, but every newline in the text <span style="font-style:italic">above has changed to a newparagraph. And: after saving and restoring the italics button was activ, but selecting text and pressing the button results didn't change anything. Now the italics button is grey again.</span></p> <p><span style="font-style:italic">Colouring text doesn't work. When choosing colours in the dialogues colour wheel, RGB values toggle between 0 and 1 and the choosen colour is not took over.</span></p> <p>Kind regards</p> <p>Frank </p> </body></html>
On Thu, 30 Sep 2004 08:17 pm, Don Sanders wrote: <snip> > I couldn't reproduce any of the other bugs "When saving and restoring > mails with attachments, often every NEWLINE is expanded to 2 > NEWLINES. Italics and bold buttons don't work, ordered list are lost > after saving and restoring...". I couldn't reproduce any of these > problems. When I switch to html mode, the font drop down menu is set to an empty entry, that's when the bold & italic buttons don't work/get stuck. But selecting a font makes them behave. Sam > Don.
earl grey wrote : > I once had this problem when my default font (Helvetica) was not in the > list of available fonts. I don't know how this can happen but it did. > In this case, my font-dropdown was initially empty. After changing my > default font is was initially filled. > Could it be the case for you too? yes exactly the same, including the Helvetica font, funny that! I did (and do) assume it's a problem with my computer,
This must be what is happening to me. Doing a program in python also. Normally use Nedit. But when open it with Kedit and save, it screws up the indents. Everything shifted left. Luckily found NOT to use kedit or kwrite for opening anything programmed prior with another editor and had a backup. bash-2.05b$ python main.py File "main.py", line 25 def run(self): ^ IndentationError: unindent does not match any outer indentation level Tested other editors: Code: bash-2.05b$ python main.py File "main.py", line 25 def run(self): ^ IndentationError: unindent does not match any outer indentation level 1) Kedit: Looks fine when load up, save and program fails. Load back up in kedit and everything shifted left. 2) Kwrite: It loads up with all indents shifted left. Same results when save. 3) Abiword and Kate looks fine, nothing shifted and prog works after saving it. So three editor don't change the indent, two do. Use kde 3.2.3 because 3.3.0 is too buggy.
Oops, forgot to remove the second: Code: bash-2.05b$ python main.py File "main.py", line 25 def run(self): ^ IndentationError: unindent does not match any outer indentation level
David: wrong bug report for your comments about kedit/kwrite. This report is about kmail's editor (when composing a mail to be sent).
Darn, thought was following a link that said was a duplicate of a kedit problem. Sorry.
Went back and found where came here from. The bug was a kedit bug and they said that http://bugs.kde.org/show_bug.cgi?id=88157 was a duplicate of this bug here. So it is marked Resolved. Where to report, where to report. Darn, used to love kedit, but can't have it changing my corrupting my source code.
Well ok, if you meant kedit explicitely (and not kwrite), then indeed those reports are related. kedit and kmail's composer both use the Qt class QTextEdit, where the bug is. See comment #2 - and the patch in #5. I wonder which Qt version has the bug and which one has the fix - this report wasn't explicit about it.
see also #90688, comment #5
Good news, the "tab replaced with space" problem is solved in Qt 3.3.4. I was about to say that on my Debian Sarge system with the upgraded libqt3c102-mt package (based on Qt 3.3.4) the problem still occurred, but after restarting the X session, the problem disappeared. Thank you guys.
Yes, I'm seeing it fixed as well on my Arch Linux box since the latest Qt upgrade. Very cool! And my thanks as well to the boys at Trolltech for fixing this one. So this bug can probably be closed now.
Ok, thanks for reporting back.