Bug 144219

Summary:	the scrollstate of the konsole history is not maintained even if the cursor is visible
Product:	[Applications] konsole	Reporter:	Shriramana Sharma <samjnaa>
Component:	general	Assignee:	Konsole Developer <konsole-devel>
Status:	RESOLVED LATER
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Shriramana Sharma 2007-04-14 18:33:26 UTC

Version:            (using KDE KDE 3.5.6)
Installed from:    Ubuntu Packages
OS:                Linux

In a session, some history has disappeared off the top of the Konsole window. I need to see it to type my next command. So what I do is I increase the height of the Konsole window and I scroll back so that I can see both the current prompt line as well as my desired history. Then I start typing my command - hey presto the history goes back above the upper edge of the Konsole window. 

Anyone can reproduce this by starting Konsole in a (vertically) short window.

This should be fixed, since I am scrolling back to see the history and that purpose is lost.

If the scrollstate of the Konsole history would not show the cursor, then there might be sense in Konsole automatically scrolling back down, since it may be necessary to see what one is typing. But even then it is not mandatory, as one may be a good typist and type correctly even without visual feedback. Leave it to the user whether he wants to see his current typing line or not. He has scrolled back to see the history and the app should not hinder what he wants to do.

So it stands that the scrollstate of the Konsole history once altered by the user should not be reset by the application.

P.S: Maybe the "short description" needs to be more lucid but somehow I didn't get the words.

P.P.S: The order of resizing the window and scrolling back is immaterial. This bug is seen either way.

Comment 1 Robert Knight 2007-04-16 03:17:00 UTC

> So it stands that the scrollstate of the Konsole history 
> once altered by the user should not be reset by the application. 

The behaviour is intentional, and with your suggestion I can forsee a problem where users scroll up the terminal window, start typing and then wonder why they are not seeing their input displayed on screen.    

This problem will not exist in KDE 4 because it is possible to split the view top/bottom such that previous output and the current input area can be seen at the same time.