This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
# 191 NetBeans IDE Dev (Build 061214) 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105 Linux version 2.6.17-10-generic running on i386 cs_CZ (nb); UTF-8 ---------------------------- I try to explain more: I'm having a file opened in editor + IRB console on order to try small pieces of code. So I'm switching a lot between IRB<->editor windows. The point is, that you click your mouse somewhere in the middle of IRB window (in order to give IRB window a focus), but you also put cursor to some line inside IRB console, and since it is not the last line with "prompt", you are unable to type:-(
I agree with this. Unfortunately, I think this is the behavior of the JRuby TextAreaReadline component, which I'm simply putting inside a NetBeans window. It would be nice if it behaved the way you're suggesting - mouse clicks should not place the caret at the nearest text position in the text pane, it should be placed at the end. I'll take a look and see if I can work around it, for example by adding a mouse listener and seeing (via the standard JTextComponent view to model computation) if the click is anywhere but the last line, and if so, set the caret to the end of the text document instead.
Mostly fixed in #192. The reason it's not completely fixed is that this works against the way Swing text areas work. They have their own mouse listener built in which responds to mouse clicks and moves the caret to the closest position. I added my own mouse listener, and put it into the event queue one extra iteration to increase the odds that my mouse click listener is run last. The click listener will check the coordinates of the click. If the click is on the last line of text, it will be processed normally (thus, you can still click somewhere in the middle of your current line input to edit it). However, if you click on any previous lines, it will force the caret to the last document position. Not ideal, but better than before. (While I was at it, I also improved focus handling such that the shell comes up with focus etc. I also added explicit caret hide/show code on focus loss. This is normally handled automatically for Swing documents, but it appears that the TextAreaReadline component messes with the editable property of the component. Once a text component is read only, it does not update the caret visibility.)
Forgotten TM
yup, seems to be working. As you mention in the comment in code, later can be determinated where prompt ends and user input begins, but for now good enough, verified (#195)
Reassigning this issue to newly created 'ruby' component.
Changing target milestone of all resolved Ruby issues from TBD to 6.0 Beta 1 build.