Community
Participate
Working Groups
CQ:WIND00215180 We have found an understandable but unexpected issue with the scroll lock feature, by exposing it via SSH to the following shell script: #!/bin/sh X=1 while true ; do X=`expr $X + 1` echo "Hello $X" done Running this script, the "scroll lock" feature does not work - - the problem with the test case is that new lines are printed so quickly, that the Terminal Widget's buffer runs over. Fix: Window > Preferences > Terminal : Set "Terminal Buffer" to 100000 lines Now, scroll lock works as expected even with this case (until 100000 lines are reached). The point is that when the terminal buffer size is exhausted, new lines are being added to the buffer and removed at its beginning, since we have a ring buffer. As a consequence, the "locked scroll location" always remains at the same place while the buffer under it gets rotated. Is this expected behavior, or should the scroll lock position rotate with its underlying source line when the buffer runs over ... up until the time when the "locked line" is expelled from the buffer? What do others think?
I think the scroll-lock position should move until it disappears. At some point I have been considering to implement a persistent ITerminalTextData. It would store the content of the teriminal that is scrolled away into a temp file. Since lines outside the dimensions of the editable area of the terminal can not change, this should be relatively simple. One could automatically use a PersistentTerminalTextData when scroll lock is enabled. The advantage would be that the lines you are looking at would never disappear (at the cost of a ever growing temp file).
it is definitel not "expected behaviour" and it is a very old bug, that seems to never getting fixed. i've seen it in all eclipse versions from at least 3.0 and opened at least one bug report against it which seems to have disappeared. scroll lock means: do not change the content displayed.
My definition of "scroll-lock": when new data arrives, do not jump to the end of the file. The Console View in eclipse does the same. Do you know other terminals that keeps an infinite history?
a) what does the "infinite history" to do with it? b) the only definition of scroll lock i know is: don't change the visible content. if the console displays a number of rows and i hit "scroll lock", i expect the console to display exactly the lines i locked, not scrolling anyway -- any kind of scrolling means it's broken, no matter why it happens. how that is accomplished, doesn't concern me (but, in fact, i would prefer to have a file buffering the content, not just a ring buffer in memory, which would be broken by design with respect to the issue at hand. after all, eclipse produces several temporary and persistent files, logs and other, why not saving the console's content to yet another, at least in case of scroll lock?).
> b) the only definition of scroll lock i know is: don't change the visible content. By that definition the eclipse console view is definitely broken. If the definition is: 1) show the content that is currently visible (until it falls out of the buffer) then the Console View is not broken, but the terminal is broken. A better definition could be: 2) stop updating the view (and buffer the incoming data) With that definition, the data would still be received but it would not be displayed. When the scroll-lock is released then all the pending data is played. This could also be seen as "take a snapshot of the current state". The ultimate definition would be: 3) stop (auto) scrolling and "infinitely" grow the buffer of visible content This would allow also to scroll to data that was appended after you press the scroll-lock button. I would consider 3) the ultimate solution. But is is relatively expensive to implement, because that would require to store the content of the visible (growing buffer) on disk. The problem here that text and the styles would have to be stored. Solution 2) is much simpler to implement. Because it would only require to buffer the incoming data in a file and then replay it once the scroll-lock state is switched off. Would definition 2) satisfy your needs?
#2 is fully sufficient. as long as the buffer is accessible by a well defined and easily memorized procedure, "scroll lock" could (should?) mean even locking manual scrolling. #3 seems totally out of reach, after all the current solution apparently was supposed to do that exactly -- and failed.
With all that discussion about buffering I'm wondering ... is the terminal forced to consume all the data that comes in from the remote? Serial, Telnet, SSH ... all support flow control. So when the Terminal doesn't consume any output any more, the remote could be blocked from producing more output. That's how the Ctrl+S / Ctrl+Q keys work on a typical UNIX-a-like. Or am I missing something ?
The Terminal component of the Eclipse Ecosystem has a new home. The Terminal is now part of the Eclipse CDT project[1]. This change means a new Git repo[2], P2 site[3] and Bugzilla component. The terminal will continue to be delivered as part of the quarterly Simultaneous Release of Eclipse as well. The marketplace entry[4] had not been updated in a few years. It will once again install the latest release of the terminal on the latest release of the whole IDE (currently 2020-03). If this bug is no longer relevant, please feel free to comment or close the bug. If you can confirm if this issues still occurs in the latest release please do let me know in a comment. [1] https://wiki.eclipse.org/CDT/User/NewIn911 [2] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git (in the terminal directory) [3] current release is 9.11 - P2 site https://download.eclipse.org/tools/cdt/releases/9.11/ [4] https://marketplace.eclipse.org/content/tm-terminal (This comment was added to all open terminal bugs along with changing the Product/component pair to CDT/terminal.)
