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.
While many of the multi-caret shortcuts seem available, the one for "Add caret and enter multi-caret mode" (CTRL+SHIFT+CLICK) does not seem to be available in the key bindings. This key binding conflicts with the OS X key binding so must be changed or editable. Product Version: NetBeans IDE Dev (Build 201607070002) Java: 1.8.0_92; Java HotSpot(TM) 64-Bit Server VM 25.92-b14 Runtime: Java(TM) SE Runtime Environment 1.8.0_92-b14 System: Mac OS X version 10.11.4 running on x86_64; UTF-8; en_AU (nb) User directory: /Users/bryan/Library/Application Support/NetBeans/dev Cache directory: /Users/bryan/Library/Caches/NetBeans/dev [1]: https://netbeans.org/bugzilla/show_bug.cgi?id=262728
@brettryan: Which mac-specific key-combination do you propose? Please check out other mac tools, which support multi-carets!
(In reply to markiewb from comment #1) > @brettryan: Which mac-specific key-combination do you propose? Cmd+Shift+Click, I would have said Cmd+Click but that of course is go to declaration. > Please check out other mac tools, which support multi-carets! One of the most popular editors for OS X based web authors is typically sublimetext [1] which we should aim to provide as smooth a transition as we can for those users. I mostly raised this bug as a feature request but marked as defect only due to the collision, however; if you like, you can close this bug and not implement the feature but provide a sensible default and refer to issue:262728 [2] instead which I am presently putting together sensible defaults that are closely related to sublime text while also trying (hard I might add) to not conflict with existing NB bindings. NetBeans IDE is presently getting pretty crowded with shortcuts due to the sheer size of functionality it provides, it's unavoidable. Thus, it does make a few things harder to match closer for users coming from other tools. Keep an eye on [2] for my suggestions. [1]: https://www.sublimetext.com [2]: https://netbeans.org/bugzilla/show_bug.cgi?id=262728
(In reply to markiewb from comment #1) > @brettryan: Which mac-specific key-combination do you propose? > Please check out other mac tools, which support multi-carets! Ok, check out issue:262728 [1] where I've completed my analysis and research of what does not presently conflict and I think are viable options. [1]: https://netbeans.org/bugzilla/show_bug.cgi?id=262728
(In reply to brettryan from comment #0) > > This key binding conflicts with the OS X key binding so must be changed or > editable. > Currently it is hardcoded http://hg.netbeans.org/core-main/file/tip/editor.lib2/src/org/netbeans/api/editor/caret/EditorCaret.java#l2679 http://hg.netbeans.org/core-main/file/tip/editor.lib2/src/org/netbeans/api/editor/caret/EditorCaret.java#l2714 http://hg.netbeans.org/core-main/file/tip/editor.lib2/src/org/netbeans/api/editor/caret/EditorCaret.java#l2749
Created attachment 161376 [details] Proposed patch @brettryan: Please try out the patch! It should work with Cmd+Shift+Click. Please give your feedback. I cannot test it on a mac.
(In reply to markiewb from comment #5) > @brettryan: Please try out the patch! It should work with Cmd+Shift+Click. > Please give your feedback. > > I cannot test it on a mac. Sure thing, I'm away for the weekend busy getting rather properly drunk. I shall be returning on Monday.
@brettryan: Can you please review the patch and try it out using your mac!
Sorry, had been away for a week. Have just tried it out and it's not working unfortunately. I have debugged and can confirm that the result of isControlShiftDown is actually returning true, it just isn't inserting any additional carets. This is caused by the isLeftMouseButtonExt(MouseEvent) method which does a check for InputEvent.META_MASK being NOT present. As a consequence it returns false. I've tested the validity of the logic by commenting out that line: private boolean isLeftMouseButtonExt(MouseEvent evt) { return (SwingUtilities.isLeftMouseButton(evt) && !(evt.isPopupTrigger())); // && (evt.getModifiers() & (InputEvent.META_MASK/* | InputEvent.ALT_MASK*/)) == 0); } Which does in fact get the multi-caret support working, however I would need to investigate what the purpose of that check is for, which you might be better equiped to understand :) Again, sorry for the delay, I'm back up and running and should be able to respond quicker.
Created attachment 161551 [details] Proposed patch v2 @brettryan: Try this patch! It is more similar to the BaseCaret-Implementation
Nah still no go, man. The difference I can see is that the test is now more inclusive. (evt.getModifiers() & (InputEvent.META_MASK | InputEvent.ALT_MASK)) == 0); is still testing for InputEvent.META_MASK but is now in addition checking existence of InputEvent.ALT_MASK. What does the check for InputEvent.META_MASK actually do in this context?
Multicaret owner should review this issue.
(In reply to Svata Dedic from comment #11) > Multicaret owner should review this issue. You are right. Miloslav, can you please help! @brettryan: Can you please provide the output of "evt.getModifiers()" when you press CMD-Shift on Mac. This might help Miloslav.
Not sure why, but no keys depressed always produces 0x10 (KeyEvent.VK_SHIFT). NOTHING = 0x10 | 10000 SHIFT = 0x11 | 10001 CMD = 0x14 | 10100 CMD+SHIFT = 0x15 | 10101 Just to point out the obvious which I mentioned previously. We want to check for META_MASK (0x04), but the problem is with isLeftMouseButtonExt(MouseEvent) doing the reverse. Here's what's happening. In mousePressed(MouseEvent) there is a check before entering the main block of the method: if (c != null && doc != null && isLeftMouseButtonExt(evt)) { This check for isLeftMouseButtonExt does the following condition: return (SwingUtilities.isLeftMouseButton(evt) && !(evt.isPopupTrigger()) && (evt.getModifiers() & (InputEvent.META_MASK | InputEvent.ALT_MASK)) == 0); Note here that this is checking that the presence of META_MASK is NOT present (== 0) and because it is, we don't get the main body being executed. That's what led me to my question. What is the purpose of this check in the first place?
This should be resolved by latest fix of issue #262728. *** This bug has been marked as a duplicate of bug 262728 ***
(In reply to Miloslav Metelka from comment #14) > This should be resolved by latest fix of issue #262728. > > *** This bug has been marked as a duplicate of bug 262728 *** Agree, though the reasoning for raising the two was the intent of this feature request was to provide support to alter the bindings.