Bug 258913 - [PATCH] dynamic word wrap always moves visible part of document down to display entire line
Summary: [PATCH] dynamic word wrap always moves visible part of document down to displ...
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: part (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: VHI major
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 252412 299951 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-12-05 15:28 UTC by Christian Blohmann
Modified: 2012-11-08 09:43 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.5


Attachments
short file that exhibits the problem (6.58 KB, text/plain)
2010-12-05 17:00 UTC, Christian Blohmann
Details
Four long paragraphs of text to reproduce error. (11.69 KB, text/plain)
2011-05-24 20:21 UTC, Lucas Vinicius Hartmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Blohmann 2010-12-05 15:28:57 UTC
Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

When I move up or down in a document and then start typing the visible part of the document moves down so that the entire dynamically wrapped line becomes visible. This becomes really annoying when the lines are long as when writing prose. Perhaps this behavior is intended for writing code, but it makes editing my science papers very tedious, since almost every time I start typing the cursor jumps to the bottom of the screen.

Reproducible: Always

Steps to Reproduce:
Turn on dynamical word wrap. Move the visible part of the document so that the beginning of a dynamically wrapped line isn't visible. Start editing that line.

Actual Results:  
The visible text jumps down to display the beginning of the line.

Expected Results:  
The visible part of the document stays where it is, which is where I wanted to have it, rather than being moved to where the dynamic word wrap wants to have it.

Might be related to bug 252412
my kate version is 3.5.1
Comment 1 Milian Wolff 2010-12-05 16:31:29 UTC
please attach a testfile that exhibits this behavior and maybe tell us what width your editor window has, if required.
Comment 2 Christian Blohmann 2010-12-05 17:00:18 UTC
Created attachment 54167 [details]
short file that exhibits the problem

Here is a sample file that reproduces the problem reliably in kate and kile. My editor window is set to display 80 columns by 33 lines of fixed-width text. The issue appears with other size settings as long as some line is dynamically wrapped and a piece of it at the beginning isn't visible. Just scroll down a bit and start typing.
Comment 3 Lucas Vinicius Hartmann 2011-05-24 20:09:46 UTC
I do have the same problem. Really annoying.

The first line of text on the window is always aligned to a hard-wraps (enter, '\n'). Only keyboar navigation can put a soft-wrap there.

Mouse wheel and scroll bar do also count hard wraps only, and scroll weirdly when long soft-wrapped lines are on top of screen.

If a soft-wrap is at the top of screen and you type anything, the scroll rearranges to put a hard break back there. Seems like a small feature, but when editting long paragraphs this may prevent viewing the text that comes on the line below, which breaks concentration.

Bug https://bugs.kde.org/show_bug.cgi?id=273236 is most likely the same as this one.
Comment 4 Lucas Vinicius Hartmann 2011-05-24 20:21:42 UTC
Created attachment 60283 [details]
Four long paragraphs of text to reproduce error.

1 - Load on any kate-based editor.
2 - Resize window to about 80-100 columns.
3 - Enable soft word wrap.
4 - Try mouse or scrollbar. BUG: Will jump paragraphs/hardwraps instead of softwraps.
5 - Navigate by keyboard so that a softwrap is at the top of screen.
6 - Place the cursor on the center of screen.
7 - Type. BUG: Scroll will align a hard-wrap on top of screen or, if not possible, move so that the cursor is visible on the bottom-most line.
Comment 5 Milian Wolff 2011-05-27 17:35:35 UTC
yeah, confirmed.
Comment 6 jhzhang 2011-12-10 15:33:27 UTC
comment the line bellow in "void KateViewInternal::editEnd(int editTagLineStart, int editTagLineEnd, bool tagFrom)" in "SRCPATH\part\view\kateviewinternal.cpp" will fix the bug.

  // fix start position, might have moved from column 0
  //m_startPos.setPosition (m_startPos.line(), 0);

somebody add this line to fix a problem, but i do not know why he makes the cursor to column 0.
Comment 7 Dominik Haumann 2011-12-10 18:16:59 UTC
It got added when switching from Smart Cursors to Moving Cursors:
https://projects.kde.org/projects/kde/kde-baseapps/kate/repository/diff?rev=a59b50911fd17e998bf90e5564f5aff41b47b61b&rev_to=3e8afa05b2a670d3514cf7f1e039463ff88e8c96

Christoph, can you have a look? ;)
Comment 8 Lars Schillingmann 2012-02-12 20:21:13 UTC
This behavior occurs frequently when working with kile and long paragraphs (Kate Version 3.8.0, KDE 4.8.00).
Comment 9 Christoph Cullmann 2012-02-21 07:46:18 UTC
I think I added this to avoid that the first line scrolls out of view if you start to write a new document and hit return.
Comment 10 Lars Schillingmann 2012-02-21 18:31:40 UTC
I locally tested comment #6 on the kubuntu ppa kate (kde 4.8.0) source package and it seems to work fine. Starting a new document, entering a line, and hitting enter does not seem move the first line out of view for me (comment #9).
Comment 11 Dominik Haumann 2012-02-29 14:03:26 UTC
Commenting out the line introduces another bug: Assume the text:

aaa aaa aaa aaa aaa|
aaa aaa aaa aaa aaa|
aaa aaa aaa aaa aaa|
aaa aaa aaa aaa a  | line hidden by dynamic word wrap
X a aaa aaa aaa aaa| first visible dny. wrapped line
aaa aaa aaa aaa aaa|

Now put the cursor in front of X (i.e. first column), and press backspace. The cursor moves to the end of the previous line, but the view does not scroll one line up.

Besides this issue, I couldn't find any other bug.

Christoph, can you take a look again?
Comment 12 Christoph Cullmann 2012-07-04 11:50:29 UTC
Git commit a569ec0c819da17713dd99f9a18cb966a1284c88 by Christoph Cullmann.
Committed on 04/07/2012 at 13:49.
Pushed by cullmann into branch 'master'.

fix first part of bug, avoid jumping
still the second problem remains, if you delete the text at start of view, view isn't moving

M  +1    -4    part/view/kateviewinternal.cpp

http://commits.kde.org/kate/a569ec0c819da17713dd99f9a18cb966a1284c88
Comment 13 Christoph Cullmann 2012-07-04 12:10:35 UTC
Git commit 0a642efe79a363b515aaddfa6eaf6333f3534c16 by Christoph Cullmann.
Committed on 04/07/2012 at 14:09.
Pushed by cullmann into branch 'master'.

fix the problem, now both things work: the view doesn't jump and the view does scroll

M  +13   -1    part/view/kateviewinternal.cpp

http://commits.kde.org/kate/0a642efe79a363b515aaddfa6eaf6333f3534c16
Comment 14 Christoph Cullmann 2012-07-04 12:14:50 UTC
Git commit fbee7a49321dec8ffe2889a144fb79219e38e777 by Christoph Cullmann.
Committed on 04/07/2012 at 14:09.
Pushed by cullmann into branch 'KDE/4.9'.

fix the problem, now both things work: the view doesn't jump and the view does scroll

M  +13   -1    part/view/kateviewinternal.cpp

http://commits.kde.org/kate/fbee7a49321dec8ffe2889a144fb79219e38e777
Comment 15 Christoph Cullmann 2012-07-04 12:14:50 UTC
Git commit 8caf31db3dadbb5ce06d7937fd17050bf3920c20 by Christoph Cullmann.
Committed on 04/07/2012 at 13:49.
Pushed by cullmann into branch 'KDE/4.9'.

fix first part of bug, avoid jumping
still the second problem remains, if you delete the text at start of view, view isn't moving

M  +1    -4    part/view/kateviewinternal.cpp

http://commits.kde.org/kate/8caf31db3dadbb5ce06d7937fd17050bf3920c20
Comment 16 Dominik Haumann 2012-07-05 14:02:35 UTC
Git commit 80d64c7a90d707c003627932d3de460d9c343ece by Dominik Haumann, on behalf of Christoph Cullmann.
Committed on 04/07/2012 at 13:49.
Pushed by dhaumann into branch 'KDE/4.8'.

fix first part of bug, avoid jumping
still the second problem remains, if you delete the text at start of view, view isn't moving

M  +1    -4    part/view/kateviewinternal.cpp

http://commits.kde.org/kate/80d64c7a90d707c003627932d3de460d9c343ece
Comment 17 Dominik Haumann 2012-07-20 16:27:09 UTC
*** Bug 299951 has been marked as a duplicate of this bug. ***
Comment 18 Dominik Haumann 2012-11-08 09:43:41 UTC
*** Bug 252412 has been marked as a duplicate of this bug. ***