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.
Product Version = NetBeans IDE 7.2 (Build 201207171143) Operating System = Windows 7 version 6.1 running on x86 Java; VM; Vendor = 1.7.0_03 Runtime = Java HotSpot(TM) Client VM 22.1-b02 C++ development; It would be convenient to: 1: Be able to select an entire output window with a short-cut &/or right-click option. I suggest CTL-A as a shortcut. Selection is currently by highlighting an area; good' for small regions, really cumbersome for extended displays. I hope that the output windows (in C++) will include, at least, 'Output', 'Variables', and 'Call Stack'. 2: Be able to copy any output window into the clipboard. I suggest CTL-C as a shortcut. By now, CTL-A and CTL-C are 'standard' across many applications for the 'select all' and 'copy' operations. The CTL-SHIFT-C shortcut is a relic of DOS, inherited into Windows and at some time was in little favor anywhere (including Windows). It would be (I think) a good thing to retire it's use in Netbeans also (IMHO). art
Used Product Version: NetBeans IDE Dev (Build 201210250001), Java: 1.7.0_10-ea; Java HotSpot(TM) 64-Bit Server VM 23.6-b03 ... Ctrl+A (Select All) works in output window ... Ctrl+C also works It might be a problem of terminal emulator ... so assigning to CND team for further evaluation
I"m not sure this is entirely related to the Terminal since the user is asking for the ability to make, presumably textual, copies of the Variables and CallStack windows so that one can for example stuff a copy of a stack trace into a bug report. I believe there have been RFE's like this filed against SolStudio as well. A note on CTL-SHIFT-C though. This is the accelerator associated with the Copy operation on the terminal-based output windows. The reason for this is not an anachronism ("relic of DOS") but rather because a terminal often runs shells, unix application editors like vi and emacs and CTL-C means a very different thing in those circumstances (typically "interrupt") and it wouldn't do to steal it for the Copy operation. It's basically a conflict of two 'standards'. We've chose CTL-SHIFT-C to match KDE's konsole. (I though gnome-terminal did the same, but I can't figure wht my fc12 version is actually using). That said we may be able to provide a SelectAll operation in the Terminal based output window let's say with the accelerator CTL-SHIFT-A. But I have a question ... what if the output window is spewing output at a prodigious rate ... should the SelectAll operation contain output up to the point of the SelectAll operation or Copy operation? And what about stuff that scroll out of history? What i'm trying to get at is that SelectAll may make sense for static text as in an editor or mail client but not in a highly active output window.
Thanks for explaining the rationale for CTL-SHIFT-C and giving me the considerations your group uses for copying the contents of a window. I understand the issues you are presenting, but, present the following for your consideration: 1: Using CTL-SHIFT-C for a copying in the Terminal (output) window is at variance with other copying commands in other contexts within Netbeans. The result is that the user is presented with an inconsistent view of how to do similar operations. I understand why it was done, to be in conformance with other standards, but, this puts the the process catywampus with Netbeans. The issue becomes of where to be consistent. 2: My request is to allow a CTL-SHIFT-A (copy-all) in both the terminal window, and at least, the 'variable' window. The issue of copying dynamically changing data is (to me - perhaps not to the code modification group) one of drawing a line in the sand and then going forward. For me, the ability to copy a static window is fine. Insisting that a copy-all operation on a dynamic window requires that the operation commences with the view as seen at the time of the copy is fine (to me). In a similar vein, if a copy-all operation commences and data in a terminal window is to be removed from the terminal buffer, then stop the output (suspend the task). If it is not possible to suspend output, then either do not perform the copy - and inform the user - or copy what is possible - which may be impossible. I guess, again for me, a little crumb is better than starving. 3: The copy operation is to allow me to migrate data from the output window to an editor. Migrating data from the output window allows me to see, search, and manipulate the data in a more convenient fashion than in the limited sized output window with the subset of editing commands supported. 4: The copy operation in the variable (or other?) window allows me to have a memory. When using a debugger and going from method to method it is useful to have some means of remembering the contents of variables. Without a (logical) pen and pencil I would have to rely on memory, and at my age this is a poor substitute for almost anything. At the end, thank you. I appreciate whatever effort you can make and, this is a suggestion not a defect so I expect you to make a decision based on the groups needs and viewpoints, not mine. art
Sorry, no-can-do for converting SHIFT-CTRL-C to CTRL-C, at least for the terminal. The IDE, despite it's "integration", is not the whole world. The main purpose of the terminal is to provide an escape from the IDE. Think of it as a wormhole into a different universe. A world where for example on can run emacs or vim which some consider to be IDE's in their own right. If you view the output window as merely an output window then the consistency argument makes sense. If that's all you're interested in you can choose StandardOutput as the value of ConsoleType in the CND project Run properties and there you will get all the consistency with the IDE that you want. However the Terminal is specifically oriented towards processing unixy _interactive_ input and output and CTRL-C is pretty important in that world. Suppose we _did_ decide to "usurp" CTRL_C for Copy, then how would a unixy terminal user interrupt their program? The thing is, processing of the CTRL_C for the purpose of interrupts is not the task of a terminal/IDE but an OS managed subsystem. Check out http://wiki.netbeans.org/TerminalEmulatorPty to see how all that works.
I've forked a bug, #223747, to deal with SelectAll in the terminal. I suggest that this bug focus on converting information presented in a non-textual fashion, eg. in the Variables, Stack etc. windows, to a textual form. I think there already exists such an RFE against OracleSolarisStudio. Given that the windows of interest are mainly in the debugger I'd recommend assigning this bug to debugger and changing the subject to something more appropriate. In NB culture the word "output" is likely to evoke textual output not any output of a debugger etc.
Hi Ivan; Thanks. Now where is the "StandardOutput as the value of ConsoleType in the CND project Run properties". Compared to those who do the work, I'm a complete doofus. I've looked at Tools->Options->Miscellaneous->Terminal & ->Windows and don't find the option. I've sorta' glanced at all the Netbeans Option tabs and nothing strikes me as appropriate. Where is the fool option? thanks art
(In reply to comment #6) > Hi Ivan; > > Thanks. Now where is the "StandardOutput as the value of ConsoleType in the CND > project Run properties". Compared to those who do the work, I'm a complete > doofus. I've looked at Tools->Options->Miscellaneous->Terminal & ->Windows and > don't find the option. I've sorta' glanced at all the Netbeans Option tabs and > nothing strikes me as appropriate. Where is the fool option? This stuff is part of the Project properties. Select a project and then Properties from the context menu.