Version: 4.3 (using KDE KDE 3.3.1) Installed from: Debian testing/unstable Packages OS: Linux I get this assertmessage for each column which my cursor is behind column 22. So for example i click on column 26 i get this message 4 times.
I've tried around some more and it's not always behind column 22 but sometimes sooner. Not exactly sure, but could have to do something with the number of tabs i'm using before that (the asserts come on a earlier column if i use more tabs).
It seems this bug is related to the fact that the Kate part is slow when dealing with long lines. These asserts go to stderr (~/.xsession-errors). If I send stderr to /dev/null the slowness with long lines of kate part goes away.
Same here, I often run kate or kwrite from the console i'm in. It is irritating that it fills the whole konsole history sometimes with the asserts :-)
It has alwo been commented out for kde 3.4a1 by David Faure. The commit log for v. 1.83 is: his warning is driving me crazy. It happens all the time (e.g. I simply do Ctrl+U to view a webpage's HTML). CCMAIL: rodda@kde.org According to Hamish, it actually is a problem, so I left it in there despite my desperate desire to comment it out some months ago.. But I guess someone should analyze the code and find out what the problem really is.
It has also been commented out for kde 3.4a1 by David Faure. The commit log for v. 1.83 is: his warning is driving me crazy. It happens all the time (e.g. I simply do Ctrl+U to view a webpage's HTML). CCMAIL: rodda@kde.org According to Hamish, it actually is a problem, so I left it in there despite my desperate desire to comment it out some months ago.. But I guess someone should analyze the code and find out what the problem really is.
Created attachment 8718 [details] Fix the problem Under a minute of debugging later, this patch solves the problem. I'm not entirely sure it's the desired behaviour since I've got no idea how this input method stuff is supposed to work (what's preedit all about?), or even what that code is supposed to do. Nonetheless, can this be committed?
It looks sane, but I don't know anything about the input stuff either. I add the developer who has added the im code to the CC list of this bug, in the hope he can tell if it is OK.
Richard's solution is wrong for CJK(Chinese, Japanese, Korean) people. The problem is when removing the text, the place of cursor is not updated. For example, imagine the situation strlen of current line = 2 and cursor-pos = 1. Then, remove the text from position 0 to 2. Calling KateRenderer::textWidth in this situation causes the problem. Please test this patch. If there's no problem, I'll commit this patch. --- kateviewinternal.cpp.orig 2004-12-20 03:16:23.000000000 +0900 +++ kateviewinternal.cpp 2004-12-20 03:49:56.000000000 +0900 @@ -3009,6 +3009,10 @@ } if ( m_imPreeditLength > 0 ) { + // reset cursor position before removing text + cursor.setPos( cursor.line(), m_imPreeditStart ); + updateCursor( cursor, true ); + m_doc->removeText( cursor.line(), m_imPreeditStart, cursor.line(), m_imPreeditStart + m_imPreeditLength ); } @@ -3034,6 +3038,10 @@ } if ( m_imPreeditLength > 0 ) { + // reset cursor position before removing text + cursor.setPos( cursor.line(), m_imPreeditStart ); + updateCursor( cursor, true ); + m_doc->removeText( cursor.line(), m_imPreeditStart, cursor.line(), m_imPreeditStart + m_imPreeditLength ); }
On Sunday 19 December 2004 19:00, Kazuki Ohta wrote: > The problem is when removing the text, the place of cursor is not updated. The problem happens without removing text. The problem is that m_imPreeditStartLine isn't cursor.line(), so calling textWidth(m_imPreeditStartLine, cursor.pos()) is wrong (since cursor.pos() might not be on that line). Usually, m_imPreeditLine is the first line in the document (for me, at least). I've not tested your patch, but I can reproduce the bug by going to kateviewinternal.cpp, to the line which I changed, and typing some stuff near the end. No removal occurs. m_imPreeditStartLine is the first line.
Created attachment 8731 [details] patch for KDE3.3.2 > No removal occurs. m_imPreeditStartLine is the first line. I see. For the people which doesn't use InputMethod, m_imPreeditStartLine is always 0. Then, the line you pointed behaves wrongly. For the InputMethod using people, the problem which I pointed occurs in removing preedit text. So, there's two ways which causes the assertion failure. Complete patch is attached. Please try.
Can anyone confirm this patch works? It's really annoying when using Konsole...
I don't see this problem in cvs HEAD. So either it has been solved, or it's not present if the special input method is not used.
This line is commented out. The actual bug remains, but we will not release kate with this line enabled.