Bug 53418

Summary: cursor jumps to the first column before reaching end of line
Product: [Applications] konsole Reporter: Daniel Clemente <dcl441-bugs>
Component: generalAssignee: Konsole Developer <konsole-devel>
Status: RESOLVED NOT A BUG    
Severity: normal CC: cerebro84, gerard, paubree
Priority: NOR    
Version: 1.1.3   
Target Milestone: ---   
Platform: Mandrake RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: screenshot
Another screenshot showing Bug 53418 with some comments about the bug.

Description Daniel Clemente 2003-01-25 20:33:07 UTC
Version:           1.1.3 (using KDE KDE 3.0.5)
Installed from:    Mandrake RPMs

I have font = 'large', and when konsole is opened it appears at 62x20. I usually maximise it (it gets to 86x32) and eventually, after running some programs that display a lot of output (like mplayer or wget), I see the problem:
  I start to write, but when I reach column 62, the cursor jumps to the start of the line (the same line), overwriting what I wrote.
  It should continue until it arrives to column 86 (the last one) and then jump to the next line and first column.

   However, I can press Enter and the command will be executed normally. Pressing left/right keys and inserting or deleting some text causes total chaos.

  See the attached screenshot, where I typed "1234567980" five times.
Comment 1 Daniel Clemente 2003-01-25 20:34:11 UTC
Created attachment 808 [details]
screenshot
Comment 2 Daniel Clemente 2003-04-07 00:29:06 UTC
I think this is a blocking bug; I have seen it with every version I tested. Can
someone please investigate it further?
Comment 3 Stephan Binner 2003-04-07 17:00:27 UTC
*** Bug 55330 has been marked as a duplicate of this bug. ***
Comment 4 Stephan Binner 2003-04-07 17:03:18 UTC
> Can someone please investigate it further? 
 
Why not you? "sometimes" and "eventually" are not good descriptions how to 
reproduce this bug. Looking at these two reports it may be even Mandrake-specific 
(shell, libreadline, ...). Does this bug still occurs with Mandrake Linux 9.1? 
  
  
  
Comment 5 Daniel Clemente 2003-04-07 20:22:23 UTC
binner: you're right, this can be Mandrake specific, as I have only seen it on
Mandrake PCs (also 9.1). Thanks for the idea, I'm going to investigate it further.
 BTW, I have seen similar bugs that happen only by resizing the window (lost
chars, broken lines, etc.)
Comment 6 gerard 2003-04-07 20:30:53 UTC
Subject: Re:  cursor jumps to the first column before reaching end of line

Le Lundi 07 Avril 2003 08:22 PM, vous avez 
Comment 7 Datschge 2003-04-07 23:16:55 UTC
I can reproduce it here using ArkLinux alpha7. To reproduce this bug do following: 
(1) Open konsole, (2) start a "full screen" app like top, then (3) maximized the konsole 
window. Now (4) quit top and (5) keep writing text, it will break at the right border of the 
windowed size of konsole and overwrite itself at the beginning of the same row. Now 
when you restore the previous window size the rows are shown correctly again. This 
behavior is independent of chosen initial window size and font size. 
Comment 8 Daniel Clemente 2003-04-07 23:54:18 UTC
Thank you very much, Datschge! That reproduces the bug also on my Mandrake9.1
with icewm. However, it does not only affect konsole... aterm, xterm, Eterm,
etc. do the same.
Comment 9 Stephan Binner 2003-04-08 10:36:53 UTC
Happening with every terminal emulator? Good indication that it isn't a Konsole bug. 
Comment 10 gerard 2003-04-08 13:07:30 UTC
Subject: Re:  cursor jumps to the first column before reaching end of line

Le Mardi 08 Avril 2003 10:36 AM, vous avez 
Comment 11 Datschge 2003-04-08 15:55:48 UTC
I can confirm that xterm shows the same behavior like konsole using the procedure I 
mentioned above, so resolving this bug as invalid since it's not related to konsole per 
se seems valid to me. 
Comment 12 Daniel Clemente 2003-04-08 23:41:29 UTC
Ok, no problem. But now that we have identified the bug, where should we file
it? It doesn't happen only in Mandrake but in ARK Linux (and probably others).
They have one thing in common: they both run KDE (I tested this on a Debian with
no KDE and worked ok).
Comment 13 Stephan Binner 2003-04-12 12:18:10 UTC
Believe or not, they have much more in common (e.g. ncurses). Report the bug to your distributor, 
he should be able to fix it or identify and report it to the correct upstream source. 
Comment 14 Daniel Clemente 2003-04-13 20:54:06 UTC
Ok, I filed this one: http://qa.mandrakesoft.com/show_bug.cgi?id=3747
Thanks, Binner, Datschge and Gerard.
Comment 15 wjl 2003-06-22 16:03:20 UTC
This isn't a bug. =) 
 
See this howto for more info on how to correctly create color prompts with  
bash. As was mentioned, you have to use \[ and \] around control characters so  
that bash can count characters correctly.  
  
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/  
  
Especially see:  
  
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html  
  
Which specially talks about this issue.  
 
Comment 16 Stephan Binner 2004-04-30 20:01:56 UTC
*** Bug 77817 has been marked as a duplicate of this bug. ***
Comment 17 Stephan Binner 2004-04-30 20:13:42 UTC
*** Bug 68533 has been marked as a duplicate of this bug. ***
Comment 18 cerebro84 2004-04-30 20:42:35 UTC
I've got no more this problem. But I don't know why...
Comment 19 kreuzritter2000 2005-02-26 06:07:45 UTC
I still do have this bug on KDE 3.3.1 running Slackware 10.0.

You can simple reproduce this bug, by maximizing the konsole window
and entering a lot of text into the konsole by hand (copy & paste will not show this bug!).

For example just enter this:
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc .... (and a lot more c characters)

It will end somewhere at the right side and start all over again at the beginning overwriting your bash prompt and user name.
This means, it will NOT jump into the next row.

In normal operation this can happen when working within large directory names
entering long commands.

For example when you are in
/usr/local/share/bla/images/
and enter a long command like this one, it can happen: 
user@home:/usr/local/share/bla/images# cp /usr/local/share/bla/images/blablub.x /home/user/images/nature/xyc/12345/

This bug is existing since the beginning of KDE 2.0 and probably earlier.

xterm and gnome-terminal do NOT show this bug, they work correctly.
So i don't think it is a distribution or other library problem.
It is definatly kde konsole specific.

 
Comment 20 kreuzritter2000 2005-02-26 06:27:34 UTC
Created attachment 9843 [details]
Another screenshot showing Bug 53418 with some comments about the bug.

The KDE Version is KDE 3.3.1 running on Slackware 10.
Comment 21 Kurt Hindenburg 2005-03-13 00:20:48 UTC
I just tested on KDE 3.4 and HEAD using steps in comment #7.  The text layout works fine here...

About comment #15:
%echo $PS1
\[\033[0;32m\](\[\033[1;34m\]\u\[\033[1;32m\]@\[\033[1;34m\]\h\[\033[0;32m\])-(\[\033[0;36m\]$(date +%H:%M)\[\033[0;32m\])-(\[\033[0;36m\]\w\[\033[0;32m\])\[\033[0;36m\]>\[\033[0;37m\] \[\e]30;\w\a\]

comment #19: again I can't reproduce uses your steps.


Read the bug report on commet #14 for more info....
Comment 22 kreuzritter2000 2005-03-14 03:07:09 UTC
Then see at my screenshots as prove.

It still does happen.
The only problem is, it is not allways reproducable.

Sometimes it works, sometimes not.