Bug 168534 - Static word wrap sets courser to the beginning of the new line
Summary: Static word wrap sets courser to the beginning of the new line
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 170884 193543 197554 197745 211124 218494 220598 242685 273730 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-08-06 19:15 UTC by john Terragon
Modified: 2011-05-22 22:11 UTC (History)
17 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description john Terragon 2008-08-06 19:15:32 UTC
Version:           3.1.0 (using 4.1.00 (KDE 4.1.0), Debian packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.25-pata-alt2

The static wordwrap in kate 3.1 (kde 4.1) has this problem: both the last word of the line and the cursor are moved to the beginning of the next line (the cursor should be moved after the end of the word moved to the next line). 

John
Comment 1 Dominik Haumann 2008-08-12 12:18:53 UTC
The problem is in KateDocument::editWrapLine:

  // ...
  else
  {
    nextLine->insertText (0, l->string().mid(col, pos));
    l->truncate(col);

This part does not work out with the doEdit call below.

    m_buffer->changeLine(line);
    m_buffer->changeLine(line+1);

    // no, no new line added !
    if (newLineAdded)
      (*newLineAdded) = false;

    history()->doEdit( new KateEditInfo(this, m_editSources.top(), KTextEditor::Range(line, col, line+1, 0), QStringList(), KTextEditor::Range(line, col, line+1, pos), QStringList()) );
  }

Anyone an idea how to fix it?
Comment 2 Rolf Offermanns 2008-08-12 14:18:32 UTC
I confirm this bug on Kubuntu 8.04.
Comment 3 Dominik Haumann 2008-09-15 19:09:31 UTC
*** Bug 170884 has been marked as a duplicate of this bug. ***
Comment 4 Dominik Haumann 2009-06-05 00:14:33 UTC
*** Bug 193543 has been marked as a duplicate of this bug. ***
Comment 5 Ryan Reich 2009-08-27 22:13:06 UTC
Using:
Qt: 4.5.0
KDE: 4.2.2 (KDE 4.2.2)
Kate: 3.2.2
(OS: Ubuntu Jaunty, 9.04)

I get a problem much like this, but intermittently.  Sometimes, when I type past the static word-wrap boundary (using static word wrap, of course) the cursor jumps to the _end_ of the first word on the next line.  For example, if the text on line 2 already exists and I start typing on line 1:

                      | (word wrap)
The quick brown fox ju...
Mary had a little lamb

and then continue, I will get the following:

                      | (word wrap)
The quick brown fox
juMarymped had a
little lamb

because the cursor jumped to the end of "Mary" when the line wrapped, rather than having itself wrapped to the same position.  This may be exactly what the original report claimed, in which case I'm glad to provide another case and this illustration.
Comment 6 Dominik Haumann 2009-09-23 08:31:19 UTC
*** Bug 197554 has been marked as a duplicate of this bug. ***
Comment 7 Pascal Létourneau 2009-10-05 00:00:05 UTC
*** Bug 197745 has been marked as a duplicate of this bug. ***
Comment 8 Michel Ludwig 2009-12-13 16:18:40 UTC
*** Bug 218494 has been marked as a duplicate of this bug. ***
Comment 9 Andreas K. Huettel 2009-12-13 16:28:32 UTC
Still present in KDE 4.3.4, and annoying as ever. :]
Comment 10 Dominik Haumann 2010-01-03 01:23:27 UTC
*** Bug 220598 has been marked as a duplicate of this bug. ***
Comment 11 Michel Ludwig 2010-01-03 11:57:32 UTC
*** Bug 211124 has been marked as a duplicate of this bug. ***
Comment 12 j__n 2010-03-20 15:28:23 UTC
Not sure about the original description, but I definitely agree with comment 5 (kwrite 4.3.4).

This happens if I am editing the last word on a line, and my cursor is not at the end of the word.  Usually, I am adding a previous word, and there is not a space (yet) between the word I am adding and the last word of the line (inadvertently making a word longer than it needs be) and when the "word" I am editing is pushed to the next line, the cursor is pushed to the end of the "word", instead of keeping its position in the "word", as expected.

> I get a problem much like this, but intermittently.  Sometimes, when I type
> past the static word-wrap boundary (using static word wrap, of course) the
> cursor jumps to the _end_ of the first word on the next line.  For example, if
> the text on line 2 already exists and I start typing on line 1:
> 
>                       | (word wrap)
> The quick brown fox ju...
> Mary had a little lamb
> 
> and then continue, I will get the following:
> 
>                       | (word wrap)
> The quick brown fox
> juMarymped had a
> little lamb
> 
> because the cursor jumped to the end of "Mary" when the line wrapped, rather
> than having itself wrapped to the same position.  This may be exactly what the
> original report claimed, in which case I'm glad to provide another case and
> this illustration.
Comment 13 Ryan Reich 2010-03-20 15:41:36 UTC
(In reply to comment #12)
> Not sure about the original description, but I definitely agree with comment 5
> (kwrite 4.3.4).
> 
> This happens if I am editing the last word on a line, and my cursor is not at
> the end of the word.  Usually, I am adding a previous word, and there is not a
> space (yet) between the word I am adding and the last word of the line
> (inadvertently making a word longer than it needs be) and when the "word" I am
> editing is pushed to the next line, the cursor is pushed to the end of the
> "word", instead of keeping its position in the "word", as expected.

This is exactly what happens to me.  Interestingly, it appears no longer to occur in kde-4.4.1 (kile-2.0.84).  Can others verify this?
Comment 14 Dominik Haumann 2010-03-20 18:01:35 UTC
Just for info: this is certainly not fixed in KDE 4.4. Maybe in KDE 4.5, with new text cursors...
Comment 15 Ryan Reich 2010-03-20 22:11:42 UTC
(In reply to comment #14)
> Just for info: this is certainly not fixed in KDE 4.4. Maybe in KDE 4.5, with
> new text cursors...

You are right; I did a simple test but misinterpreted it.
Comment 16 j__n 2010-03-21 10:08:42 UTC
After a bit more testing, I'd like to add the following clarification.  This only happens if there is already text on the next line.

e.g. If I have:
abcdefghijklm nopqrstuvwxyz abcdefghijklm nopqrstuvwxyz abcdefghijklm qrstuvwxyz
a

and I try to prepend p before q in the last word on the first line, my cursor jumps after the z.  But, if I have (note the blank second line):
abcdefghijklm nopqrstuvwxyz abcdefghijklm nopqrstuvwxyz abcdefghijklm qrstuvwxyz

and I try to prepend p before q in the last word on the first line, my cursor stays after the p, as expected.
Comment 17 j__n 2010-03-21 10:10:47 UTC
ergh, that word wrapped when i posted.  my word wrap is set to 80, and the first line should have 6 sets of "words"
Comment 18 Dominik Wujastyk 2010-04-28 17:39:53 UTC
I originally reported the following as a Kile bug, but it belongs here, rather.]

------------------------------------

Public bug reported:

Binary package hint: kile

Splash screen: Kile 2.1 beta 3

$ kile --version
Qt: 4.5.2
KDE: 4.3.5 (KDE 4.3.5)
Kile: 2.0.84

Installed version: 1:2.1.0~svn1079982-0ubuntu1~karmic1~ppa1

Running under an up-to-date Ubuntu 9.10,

apt-cache policy kile
kile:
 Installed: 1:2.1.0~svn1079982-0ubuntu1~karmic1~ppa1
 Candidate: 1:2.1.0~svn1079982-0ubuntu1~karmic1~ppa1
 Version table:
 *** 1:2.1.0~svn1079982-0ubuntu1~karmic1~ppa1 0
       500 http://ppa.launchpad.net karmic/main Packages
       100 /var/lib/dpkg/status
    1:2.1.0~svn1014763beta2-1ubuntu1 0
       500 http://archive.ubuntu.com karmic/universe Packages


--- Bug report:

I've got static word wrap on, at column 62.  When my typing gets to the
end of a line, the cursor often jumps to a position a few characters
along in the next line.

For example, with * marking the position of my cursor, when I type "i",
the following is the before and after scenario.

Obeyesekere (impact in Sri Lanka), Montgomery (medical pract*),
Taylor, and

Obeyesekere (impact in Sri Lanka), Montgomery (medical
practi),* Taylor, and

So the cursor has jumped two chars forward, and my typing is in a mess.

I can't routinely repeat the error, and I'm not sure about all the
features of it.  It seems to vary according to the exact layout of the
text.  But the above example was repeatable.

Dominik Wujastyk

** Affects: kile (Ubuntu)
    Importance: Undecided
        Status: New

--
word wrap faulty: cursor jumps forward on new line
https://bugs.launchpad.net/bugs/523883
You received this bug notification because you are a direct subscriber
of the bug.


=======================================================================

And from Andreas Wenning (Kile maintainer):

Thanks for reporting this bug!

This is most likely a bug in the katepart (from kdelibs) then, which
both kate and kile uses for the editing window. Your bug seems to be a
problem with the KDE program itself, and not with our KDE packages.
While we appreciate your issue, it would be better if it was tracked at
https://bugs.kde.org, so that the KDE developers can deal with this
speedily and have direct communication with you as the reporter for more
effective debugging.

Thanks!

** Also affects: kde4libs (Ubuntu)
  Importance: Undecided
      Status: New

** Changed in: kile (Ubuntu)
      Status: Incomplete => Invalid

** Changed in: kde4libs (Ubuntu)
      Status: New => Invalid
Comment 19 Sonmez Sahutoglu 2010-04-28 19:22:02 UTC
Just in case this helps. 

I am using and up to date Ubuntu 9.10
with 
Qt: 4.5.2
KDE: 4.3.5 (KDE 4.3.5)
Kile: 2.0.85

I can reproduce the bug on kile and kate.

Start with the following document.
"We construct higher-dimensional versions of the famous domains and show that the
Bergman projection operators for these domains regular"

then bring the cursor to in front of the word "show" in the first line. the cursor should be
touching the word "show". Then try to write the following
"let see if we make a mistake"

you will get:
"We construct higher-dimensional versions of the famous domains and let see
ifshow make a mistake that the
Bergman projection operators for these domains regular"

However, if the cursor does not touch the word "show" then you get
"We construct higher-dimensional versions of the famous domains and let see
if we make a mistake show that the
Bergman projection operators for these domains regular"

Also, if I redo every step both programs crash at the end.

Thanks,
Comment 20 Dominik Haumann 2010-04-28 23:25:38 UTC
finally fix static word wrap bug for KDE 4.5.

This is simple due to the new TextBuffer supporting wrapLine and unwrapLine
out of the box. There is still an issue remaining: If you have a bookmark in
the already wrapped line and then undo the wrap, the bookmark moves up, which
is wrong. But this is another bug report and iirc not a new issue.

This fixes bug #168534.

Commit:
http://gitorious.org/kate/kate/commit/c2a6ffe748bca6923af61ee791a30c32e085d588
Comment 21 Christoph Cullmann 2010-04-30 22:28:03 UTC
SVN commit 1121214 by cullmann:

dhaumann:

    finally fix static word wrap bug
    
    This is simple due to the new TextBuffer supporting wrapLine and unwrapLine
    out of the box. There is still an issue remaining: If you have a bookmark in
    the already wrapped line and then undo the wrap, the bookmark moves up, which
    is wrong.
    
    This fixes bug #168534.

BUG: 168534


 M  +2 -2      katedocument.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1121214
Comment 22 Christoph Cullmann 2010-04-30 22:28:40 UTC
SVN commit 1121215 by cullmann:

dhaumann:

    add unit test for word wrap with cursor check
    
CCBUG: 168534


 M  +11 -0     CMakeLists.txt  
 A             katedocument_test.cpp   [License: LGPL (v2+)]
 A             katedocument_test.h   [License: LGPL (v2+)]
 M  +10 -0     movingcursor_test.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1121215
Comment 23 Michel Ludwig 2010-06-26 18:03:08 UTC
*** Bug 242685 has been marked as a duplicate of this bug. ***
Comment 24 Michel Ludwig 2011-05-22 22:11:09 UTC
*** Bug 273730 has been marked as a duplicate of this bug. ***