Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333790

Summary: [console] org.eclipse.ui.console.IOConsole - OutputStream-inserted text does not move caret, causing problems
Product: [Eclipse Project] Platform Reporter: Simon L. <simon-jena>
Component: DebugAssignee: Paul Pazderski <paul-eclipse>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: jurgen.vinju, paul-eclipse, pawel.1.piech, pj, remy.suen
Version: 3.6Keywords: helpwanted
Target Milestone: 4.14 M1   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on:    
Bug Blocks: 552030    

Description Simon L. CLA 2011-01-07 17:50:33 EST
Build Identifier: 20100617-1415

I noticed that putting some text to the console via TextConsole.newOutputStream().write(String) does put the text into the console correctly, but does not move the caret.

First of all, it looks weird, because the cursor is now at a position in the console where no inserting characters is possible. This alone needs to be fixed (or the caret needs to be positionable).
If the user does now input normal text into the console, e. g. by typing "test" or alike, the caret immediately jumps to the end of the uneditable region, and the typed characters are put in correctly. Still, its not intuitive, that the caret jumps around, and there is no possibility to control the caret of the IOConsole UI part.
But this also can cause exceptions: when typing a few characters in the console, and then writing some String into the console, the String is appended to the end of the previously typed text (but the caret is, as mentioned, still right before the via-OutputStream-inserted text). Now, when the user uses Backspace one or two times, an exception is thrown:

Exception stack trace: http://pastebin.com/mXA2619D

More about it: see reproduction guide.

Reproducible: Always

Steps to Reproduce:
Setup: Zero-configured IOConsole:
IOConsole ioConsole = new IOConsole("MyIOConsole", null);
ConsolePlugin.getDefault().getConsoleManager().addConsoles(new IConsole[] {ioConsole});

1) go to the console view
2) type some text, e. g. "Test" (do not press enter)
3) insert some String to the console via one of the console's OutputStreams
4) press backspace twice (e. g. by a handler activated by a toolbar button)


Reproduction video:
http://screencast.com/t/EE2G9SZtqwla

* Stracktrace at the end: http://pastebin.com/mXA2619D
* Console creation code: http://pastebin.com/SnZg2Rv0 (called by extension point org.eclipse.ui.startup)
* Toolbar button-executed code: http://pastebin.com/dKHqYp16
Comment 1 pajai CLA 2011-03-04 10:03:03 EST
Hi all,

Is there a workaround for this issue (e.g. a way to print to the console which the caret can deal correctly with)?

Cheers,
P.
Comment 2 Simon L. CLA 2011-03-05 07:54:54 EST
(In reply to comment #1)
> Hi all,
> 
> Is there a workaround for this issue (e.g. a way to print to the console which
> the caret can deal correctly with)?
> 
> Cheers,
> P.

I tried it quite a while (2-3 hours), but couldn't find any.
Comment 3 Pawel Piech CLA 2011-03-21 19:28:30 EDT
The code where the exception is coming from is pretty inactive so I don't know if anyone has much expertise in it.  A fix contribution would be much appreciated.
Comment 4 Paul Pazderski CLA 2019-06-17 15:51:49 EDT
I can not reproduce the exception part anymore but if the problem still exist there are high chances it is fixed with bug 548356.

For the cursor movement I plan to add another change for 4.13 which should improve this situation.
Comment 5 Paul Pazderski CLA 2019-10-11 04:48:50 EDT
I'll close it as fixed. There should be no more exceptions regards input handling in console.

The caret still don't move on output but it can now insert new input at its position where it jump to the end in the past. That means as long as the caret is not manually moved around (intentionally moved in a read-only position) the caret will not jump on user input no matter what output is appended meanwhile.
(there is one case left where it can jump in fixed width console until bug 552014 is fixed)

See also bug 550621 where I attached a video showing the changed input handling.