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.
Select some content in the output window, with it scrolled back from the bottom. Press CTRL-C to copy it to the clipboard. The output window scrolls to the bottom. This is desirable behavior in a terminal on user input, and indeed is the default behavior of XTerm. However, in the case of meta-actions which are not intended to be providing input, this needs to be suppressed (does the OW actually need to be sensitive to user input at all when it's displaying program output or compilation results?)
I don't see this behaviour in compiler OW or when OW displays output only. Please attach example, if you have another opinion. But when executed program uses input (opens input stream), then it should be sensitive on user input IMO.
Yes, it works fine for output only. When I do System.out.println("....") OW changes to I/O mode and CTRL+C works properly but a square character is displayed. Why is the OW in I/O when I'm doing only output ? Or am I wrong ?
I encountered this when testing an app that I set up to write voluminous debug output and needed to copy a portion of it into the unit tests that would need to match this output in the future. I did also see the square characters appear for my CTRL-C keystrokes. I think it's worth differentiating meta keystrokes, or at least doing this optionally in the output window - the two things it's likely to be used for are: Java - Copy to the clipboard C - Brutally terminate the program in neither case is scrolling the window useful. As long as we do send those keystrokes to the application's standard in as well, everything works as expected in all cases.
I think I should reassign it to Ivan..
Target milestone -> 3.3.1.
Target milestone -> 3.4
*** Issue 21035 has been marked as a duplicate of this issue. ***
Target milestone was changed from '3.4' to TBD.
Set terget milestone to TBD
*** Issue 26285 has been marked as a duplicate of this issue. ***
doesn't seem we can fix it for 3.5 -> target = 4.0
*** Issue 21207 has been marked as a duplicate of this issue. ***
If someone types a ^C to Term (under stock NB) currently the copy action may happen but you also get a square printed and may get other side-effects per this bug report. Term has a mechanism where the keystrokes for all actions associated with it's containing window can be used to defeat their printing (as squares). (See Term.setKeyStrokeSet()). There is an issue that the registered KSS is in terms of KeyStrokes made up of KeyCodes, while Term needs to filter out Key_Char_s. I've dealt with his as best as I can but when testing discovered that the set of Kestrokes registered with Term is not quite right. This is done in OutputTabTerm.updateKeyStrokeSet() where it uses lookup to get _some_ keymap. When I dump it it's a pretty large keymap. It contains keystrokes not relevant to OW and is missing keystrokes like Ctrl-A. So are we registering the correct keymap?
'keystroke_set' is a collection of KeyStrokes in the form: ks3 = getKeyStroke(VK_C, CTRL_MASK) we use Term.maybeConsume() in keyPressed and keyTyped events. During keyTyped the event->KS mapping gives us ks2 = getKeyStroke((char) ('c'-64), CTRL_MASK) ks2 and ks3 while logically equivalent don't hash to the same so maybeConsume() says yes to ks2 and the Ctrl-C gets passed on. So to detect whether something in 'keystroke_set' needs to be dropped we need to check at keyPress time but take action at keyTyped time. 'passOn' helps us do that.
closed
moving terminal emulator issues to terminalemulator component. To see the correct version and target milestone of this issue look at Issue Activity table.