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.
Using eclipse keymap on linux, with locale FR-fr (azerty keyboard) One of my most used shortcuts is for comments. It is ctrl + / It does not work as intended because it is recognized as ctrl+shift+: (as per test field in the keymap pane). On an azerty kbrd, the / is 'above' : thus shift+: Workaround is to add the recognized shortcut I believe this is one of more.
Ctrl+SLASH is perfectly known in the keymap. The 'bug' is that shift+COLON is not recognized as SLASH And because I smell that the keymap was bulk imported somehow, I think there must be more 'bugs' like this one (that what I meant with "I believe this is one of more.")
Yes, this is a general issue. We record shortcuts using the base keys, so instead of CTRL + ")", we record CTRL + SHIFT + "0". Naturally if a 'slash' key is not present on French keyboard (it' shift + ":"), the keystroke will not be recognized. BTW I identified the same issue with e.g. IntelliJ Idea and Eclipse. The trouble is that the JDK keystroke encoding scheme is not portable across keyboard layouts: pressing the same *character* + modifiers will result in different KeyStrokes on different keyboards. Also all the netbeans configuration is defined in JDK scheme, so: I would recommend to close the defect as WONTFIX. It's however somewhat rude to non-english speaking countries :-/ You can find a 'slash' key just one position left from the right shift key, the trouble is that you have to learn and use physical locations (on English keyboard) of keys, although the characters you see are located elsewhere on national kbd. It might be possible to NOT display shift for printable characters, so Ctrl+shift+slash would become Ctrl-?. That could effectively lead to another physical key combination on a natural keyboard than it used to be. KeyStrokes would have to be translated for display, naturally. However I fear the solution would be fragile cross-platform, especially considering Macs with Alt-char combinations. Petre - do you consider the issue is so important from usability point of view that the workaround outlined above is not sufficient for users ?
*** Bug 217279 has been marked as a duplicate of this bug. ***
Please note there are issues on MacOS X (even with US keyboard) in JDK-7. Keyboard events seem to be changed in a way that it's not possible to decode the modifier + base key combination. See also defect #223818
*** Bug 231915 has been marked as a duplicate of this bug. ***
Thanks Svata for the triaging. I was not aware of the keybinding export as HTML action, my entry point was shortcuts.pdf file. If possible, I would like to improve a bit the html export. (If no RFE in progress I will try that) Regards, Eric PS: As I have another setup (may not match eclipse keymap) // The follwing is for Default Netbeans Keymap this particular toggle comment action has a nice alternate: CTRL-SHIFT-C What happens in menu bar(see issue in previous comment #5) draw me to the idea that keybindings may not be ordered. If they where, it would be easier to apply the following rule: 1rst: try to use alphanumerical based keybindings as the default 2nd: list the other keybindings. which in fact applies only once for toggle comment action
*** Bug 244456 has been marked as a duplicate of this bug. ***
*** Bug 243930 has been marked as a duplicate of this bug. ***
*** Bug 155117 has been marked as a duplicate of this bug. ***
(In reply to Svata Dedic from comment #9) > *** Bug 155117 has been marked as a duplicate of this bug. *** As you considered a bug report from 2008 with a more generic description to be a duplicate of this, I add here my comments, too. The doc says "Ctrl-[ Moves the insertion point to the highlighted matching bracket." There's no [ key on Hungarian layout. [ is on AltGr+F, so this shortcut won't work. I'd like to add an alternative shortcut Ctrl-Ő, as Ő is the key in the position of [ in the US keyboard. But Options/Keymap doesn't let me use the keys with national characters. (This does work in Eclipse, BTW.) And yeah, WONTFIX being "somewhat rude" is an understatement.
(In reply to t_gergely from comment #10) > The doc says "Ctrl-[ Moves the insertion point to the highlighted matching > bracket." > There's no [ key on Hungarian layout. [ is on AltGr+F, so this shortcut > won't work. I'd like to add an alternative shortcut Ctrl-Ő, as Ő is the key > in the position of [ in the US keyboard. But Options/Keymap doesn't let me > use the keys with national characters. (This does work in Eclipse, BTW.) > > And yeah, WONTFIX being "somewhat rude" is an understatement. You know - according to the process, I should file a defect against JDK and close NB defect as 'wontfix', as partially I am dealing with platform/core lib deficiency and the most proper way is to fix platform, not NetBeans. After the platform bug is addressed, adjustments can be done to NB code. But still I would like to spend some cycles to investigate possible workarounds.
*** Bug 247267 has been marked as a duplicate of this bug. ***
*** Bug 253593 has been marked as a duplicate of this bug. ***
Happens in 8.1 too.
This is a big problem because I can't use Ctrl + Shift + ] for example the multi caret support. Because ] is only accessable via Alt Gr 9.
Folks, the issue has probably no nice solution. All codes I get from JDK are mapped through the keyboard layout. With some effort, I might be able to detect that e.g. ; (typed with shift on some keyboards) has an extra modifier (compared to US layout) and *might* be able to work around that - but even then (following the example) [anythin]-SHIFT-; shortcuts would be doomed anyway. It COULD be possible, instead of simple selector between shortcut profiles, to have a matrix: overlay mapping of shortcuts for the profile AND specific keyboard layout. I think I have no cycles to provide such definitions (for an unknown number of layouts). If there will be enough support from the community, I might be able to create infrastructure, in a form of a patch, and rely on community to provide the shortcut definitions. So whoever is an active and proud user of a national keyboard during development AND is willing to spend some time to collect, think out and maintain shortcut definitions - add yourself to CC: and vote (or at least speak up).