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.

Bug 101172 - Shortcut conflict for Camel case word movements/selections
Summary: Shortcut conflict for Camel case word movements/selections
Status: VERIFIED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@editor
URL:
Keywords: UI
: 102414 110817 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-16 15:52 UTC by Jiri Prox
Modified: 2007-11-05 13:44 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Making camel-case-style navigation optional (14.10 KB, text/plain)
2007-04-26 03:49 UTC, Vitezslav Stejskal
Details
camelcase option UI proposal (18.76 KB, image/png)
2007-09-04 13:11 UTC, Ondrej Langr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Prox 2007-04-16 15:52:11 UTC
NetBeans IDE Dev (Build 070416)
1.6.0_02-ea; Java HotSpot(TM) Client VM 1.6.0_02-ea-b02
Linux version 2.6.5-1.358 running on i386
en_US (nb); UTF-8

There is shortcut conflict between actions Insertion Point to Next Camel Case
Position and Insertion Point to Next Word, both are assigned to Ctrl-Right 
Second conflict is between Insertion Point to Previous Camel Case Position and
Insertion Point to Previous Word, Ctrl-Left.
Comment 1 Vitezslav Stejskal 2007-04-16 23:09:34 UTC
It's not a conflict. Both actions are applied for different mime types.
Insertion Point to Next Word applies generally for all editors, but java where
it was replaced by Insertion Point to Next Camel Case Position. The
Tools-Options unfortunately is not able to show shortcuts by mime type.

If you meant that both actions should be available (in java editors) and that we
should use ctrl-arrow for navigating by words and some other shortcut for
navigating by camel humps please reopen.
Comment 2 Jiri Prox 2007-04-17 10:12:07 UTC
Yes, it see it now, but IMHO ctrl-arrow is well known shortcut for jumping
between words, used in many others editors, so it'd be fine to support it. Are
there any free shortcuts suitable for moving through camel case words?
Comment 3 Miloslav Metelka 2007-04-17 15:48:31 UTC
BTW I've experienced some negative reaction that Ctrl+<arrows> jump by camel
case and not entire words like before. We should possibly make an option for
camel case use or find another shortcut for it. But it affects also
ctrl+shift+<left/right> so the latter option will be more difficult.
Comment 4 Vitezslav Stejskal 2007-04-18 00:38:27 UTC
Yeah, in fact it was originally bound to ctrl-alt-arrow, which unfortunately is
used by linux window managers to switch workspaces. So, we changed it to just
ctrl-arrow. I am really not sure what shortcuts we should use because all
natural ones are already taken:

ctrl-arrow: navigation by words
ctrl-shift-arrow: selection by words
alt-arrow: switching editor tabs

We actualy need two shortcuts for each direction and they should have a form of
something-arrow and something-shift-arrow.

Ideally, I'd like using alt, but we would have to sacrifice switching editor
tabs by alt-arrow as it is now. Maybe it won't be a big problem, because this
functionality can currently be accessed by several (!) independent shortcuts -
shift-F4 opens the 'Documents' window and ctrl-tab/ctrl-shift-tab pops up a
little tooltip-like window with current editor files allowing to select the one
you want. The ordering is a bit funny/chaotic, but that could be fixed easily I
suppose.

Here is the proposal - let's leave ctrl-tab/ctrl-shift-tab for swicthing between
editor tabs and use alt-arrow and alt-shift-arrow for camel case
navigation/selection. Then ctrl-arrow, ctrl-shift-arrow can be used for
navigating/selecting by words as it used to be.

Opinions?
Comment 5 Miloslav Metelka 2007-04-18 16:40:32 UTC
I would rather use Alt+Left/Right like in a web browser - for history navigation
i.e. instead of Alt+K/L. For me it would be more logical and a desired change
(even though the existing users are probably already used to the existing
Alt+Left/Right functionality pretty much).

Personally I would rather use the camel case jumping as an option for existing
Previous/NextWordAction i.e. without additional shortcuts.
The camel case jumping/selection could be turned on/off in tools->options. BTW
both main competitive IDEs do it in this way.
Comment 6 Vitezslav Stejskal 2007-04-19 00:18:16 UTC
Ok, using Tools-Options and letting users choose what navigation style they like
is another way. Let's consider it for a while:

- What would be the default value for this option? The word-style or
camel-case-style navigation? (me == camel-case)
- Shall we apply this option for all editors or just for java? (me == java-only)

What do others think?
Comment 7 Vitezslav Stejskal 2007-04-19 00:52:01 UTC
As a reference the actions are called:

Insertion Point to Next Camel Case Position
Insertion Point to Previous Camel Case Position
Extend Selection to Next Camel Case Position
Extend Selection to Previous Camel Case Position

Their word-style equivalents are called:

Insertion Point to Next Word
Insertion Point to Previous Word
Extend Selection to Next Word
Extend Selection Back

Comment 8 Miloslav Metelka 2007-04-19 08:26:30 UTC
Agreed completely with the prev-prev note.

Regarding actions: we can possibly just retain

Insertion Point to Next Word
Insertion Point to Previous Word
Extend Selection to Next Word
Extend Selection Back

and make their java impls to check the option and modify its behavior accordingly.

Regarding option name I've seen "Smart caret positioning in Java names" or we
can have e.g. "Camel case positioning in Java names" I guess users should
already know the meaning of it.
Comment 9 Vitezslav Stejskal 2007-04-19 09:41:23 UTC
Good, I've seen the new Java options category and its panels and it looks like a
place where this new camel-case-style navigation option should be. I'm not sure
who is overlooking the design of those panels, but perhaps we could find a spot
for this option somewhere. 

Re. action names - yes, we should definitely have just one set of actions and
change their behavior according to the value of this option.

Re. the name of the option - 'Camel case positioning in java names' sounds good
to me, I think it's commonly used for refering to this feature and to the style
of writing java identifiers.
Comment 10 Petr Hrebejk 2007-04-19 09:58:38 UTC
Please be carefull (not saying don't put it there) the node may be removed or
heavily modified later. Depends on Jano Rojcek.
Comment 11 Vitezslav Stejskal 2007-04-19 23:16:47 UTC
I meant to CC Sandip Chitale (sandipchitale) rather than ? (sandip). My sincere
appologies.
Comment 12 _ sandipchitale 2007-04-20 01:25:31 UTC
I agree with making it an option which is referenced by the action impl to do 
the user specified thing. Eclipse does it that way. Their option is called:

[ ] Smart caret positioning in Java names (overrides platform behavior)

in the Windows:Preferences:Java:Editor panel.

For future consideration:

IMHO this is not a Java only thing. Other languages have a similar notion of:

- camel case
- dash separator
- _ separator
- other?

in case of other languages. So some mime-type lookup based mechanisms should 
be put in place to provide the "calemCase" next and previous positions for the 
respective language. Then the option will not be java specific but may appear 
for any language that wants to support such function.
Comment 13 Miloslav Metelka 2007-04-20 10:33:53 UTC
IMHO we should do it selectively although we can have some common miniSPI into
word move/select actions in the future.

BTW currently we have the following options in SettingsNames that control the
basic word movement actions:

    /** Acceptor that recognizes the identifier characters.
    * If set it's used instead of the default Syntax.isIdentifierPart() call.
    * Values: org.netbeans.editor.Acceptor instances
    */
    public static final String IDENTIFIER_ACCEPTOR = "identifier-acceptor";

    /** Acceptor that recognizes the whitespace characters.
    * If set it's used instead of the default Syntax.isWhitespace() call.
    * Values: org.netbeans.editor.Acceptor instances
    */
    public static final String WHITESPACE_ACCEPTOR = "whitespace-acceptor";

Those can be (and already are) overriden by individual languages. Possibly we
could have some more contextual SPI in the future that could e.g. allow to
traverse lexical tokens around the caret.
Comment 14 Vitezslav Stejskal 2007-04-26 03:47:51 UTC
I've got a patch that makes the camel-case-style actions optionally fall back to
the default behavior (word-style). I'll apply it when trunk is not in high
resistance. In the mean time I am attaching it here.

I would need some help though. As mentioned before I'd like to expose this
option somewhere in UI, ideally a panel under the new 'Java Code' category in
Tools-Options. Here are my questions:

1. Would it be acceptable to have a 'General' panel that with this option on it?
It could also contain the 'View Java Packages As' option, which is now under the
'General' category.

2. Where in the code of java modules I should put this panel? Prehaps
java/editor? How/where do I register the panel?

(Sidenote: I guess my last comment on this was not very clear, because I said
'Java options', which sounds more like the old options node in the Advanced
Options mode of the Tools-Options dialog. In fact I meant the new 'Java Code'
category and its panels in the 'new/now normal' Tools-Options.)
Comment 15 Vitezslav Stejskal 2007-04-26 03:49:06 UTC
Created attachment 41687 [details]
Making camel-case-style navigation optional
Comment 16 Vitezslav Stejskal 2007-04-26 03:51:06 UTC
*** Issue 102414 has been marked as a duplicate of this issue. ***
Comment 17 Vitezslav Stejskal 2007-04-27 00:39:01 UTC
The patch is in trunk. The camel-case-style is on by default, but can be turned
off by "-J-Dno-java-camel-case-style-navigation=true". This will eventually be
controlled from Tools-Options. The camel-case-style actions 'hook' into the
'normal' editor actions for cursor movement, selection and deletion, so all
usual shortucts should use camel-case in java from now on (see issue #102414).

Checking in editor/java/DeleteToNextCamelCasePosition.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/DeleteToNextCamelCasePosition.java,v
 <--  DeleteToNextCamelCasePosition.java
new revision: 1.2; previous revision: 1.1
done
Checking in editor/java/SelectNextCamelCasePosition.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/SelectNextCamelCasePosition.java,v
 <--  SelectNextCamelCasePosition.java
new revision: 1.2; previous revision: 1.1
done
Checking in editor/java/AbstractCamelCasePosition.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/AbstractCamelCasePosition.java,v
 <--  AbstractCamelCasePosition.java
new revision: 1.2; previous revision: 1.1
done
Checking in editor/java/SelectPreviousCamelCasePosition.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/SelectPreviousCamelCasePosition.java,v
 <--  SelectPreviousCamelCasePosition.java
new revision: 1.2; previous revision: 1.1
done
Checking in editor/java/NextCamelCasePosition.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/NextCamelCasePosition.java,v
 <--  NextCamelCasePosition.java
new revision: 1.2; previous revision: 1.1
done
Checking in editor/java/JavaKit.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/JavaKit.java,v  <-- 
JavaKit.java
new revision: 1.38; previous revision: 1.37
done
Checking in editor/java/PreviousCamelCasePosition.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/PreviousCamelCasePosition.java,v
 <--  PreviousCamelCasePosition.java
new revision: 1.2; previous revision: 1.1
done
Checking in editor/java/DeleteToPreviousCamelCasePosition.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/DeleteToPreviousCamelCasePosition.java,v
 <--  DeleteToPreviousCamelCasePosition.java
new revision: 1.2; previous revision: 1.1
done
Checking in java/editor/resources/DefaultKeyBindings.xml;
/cvs/java/editor/src/org/netbeans/modules/java/editor/resources/DefaultKeyBindings.xml,v
 <--  DefaultKeyBindings.xml
new revision: 1.14; previous revision: 1.13
done
Comment 18 Vitezslav Stejskal 2007-04-27 00:44:02 UTC
I know ppl are busy, but could anybody please give some advice regarding the
Tools-Options panels and where to put the option for controlling navigation
style in java editors (camel-case vs words)? Please see some of the previous
posts here for more details. Thanks!
Comment 19 Jesse Glick 2007-04-27 01:40:05 UTC
My $0.02: I would always leave the CamelCase style on, so I don't care whether
and how it it permitted in Options to disable it, but maybe others really
dislike it.

Note that Emacs normally binds Ctrl-Left, Ctrl-Right, Ctrl-Backspace, etc. to
*-word commands, which operate over a mode-dependent syntax. Seems that the
java-mode syntax does not properly handle wordBoundaries, but the Lisp mode
definitely does, e.g.

  (set-buffer-frame nil)
   ^   ^      ^     ^

I don't think the Eclipse label "(overrides platform behavior)" is a good UI
style to follow. :-)
Comment 20 jrojcek 2007-04-27 09:39:34 UTC
Ondra Langr is currently working on a new shortcut keymap for 6.0.

Ondro, please take a look at this issue and help Vita to choose solution for the camle case movement. 
Thanks.
Comment 21 Ondrej Langr 2007-04-27 14:42:52 UTC
I believe it's reasonable to assume that for most (java) users, the camel case
should be the default behavior. Why? First, there are definitely not enough
(intuitive) shortcuts to cover both actions. Second, with a word being composed
of typically two or at most three camel case elements it's much faster for a
user to push control and arrow two or three times than to jump over one camel
case section for a user using typical jump-to-next-word action. The aim of the
user is to select the text, thinking about 'HOW' to select it breaks the flow. I
believe that most users used to camel case granularity would use it even when
jumping over a word consisting of two or more camel case sections. 

The option allowing to set the behavior does not fit into the Option dialog very
well. First, we do not have any other action which would be customized in
options this way, second, it can not fit into any existing group or tab. Anyone
who really wants to use the traditional caret-next-word action can map it to
ctrl - arrows it in keymap. 

The solution we should go for is to add new camel case actions and leave up to
editors which action they will map ctrl-arrow and ctrl-shift-arrow to. For java,
I belive it should be camel case granularity.

Comment 22 Vitezslav Stejskal 2007-04-30 02:57:16 UTC
I'd prefer to keep this discussion in one place and it seems that nb-usability@
has attracted more attantion so far. It's a private alias, so if somebody
strongly objects we will move it to public. Obviously, either way the outcome of
this discussion will be posted here.
Comment 23 Vitezslav Stejskal 2007-05-06 23:26:21 UTC
Feedback from nb-usability@:

We discussed this feature on yesterday's nb-usability meeting and the outcome
was unanimous: to leave the current state which is camel case as default
behavior and no option to change it except for keymapping.
The reason is that we actually only heard positive and neutral ("i'm getting
used to it") kind of feedback. If there will be numerous negative feedback, the
option will be introduced.

ondrej
Comment 24 Vitezslav Stejskal 2007-05-06 23:45:24 UTC
I'll keep the status quo and leave the code as it is now, which means:

- camel-case is on by default in java files
- it can be turned off by adding -J-Dno-java-camel-case-style-navigation=true to
the config file
- there are no special actions in Tools-Options for camel-case navigation

The last item is in contrary with the outcome from nb-usability, but since I
believe the main message was 'leave it as it is now' I'm not going to change
that unless somebody speaks up. But please keep in mind that with current
Tools-Options support users won't be able to freely assign/unassign shortcuts to
camel-case actions either. I can elaborate more on this, if somebody is interested.
Comment 25 Jiri Prox 2007-06-06 13:46:15 UTC
verified
Comment 26 Jiri Prox 2007-07-25 09:36:38 UTC
*** Issue 110817 has been marked as a duplicate of this issue. ***
Comment 27 matthies 2007-07-25 14:23:13 UTC
Previous comments noted the lack of negative feedback with regard to camel case positioning.
Well, here is some :), so I'm reopening this issue.

My main peeve is that selecting or deleting an identifier isn't easily possible any more (previously 
Ctrl+Shift+Left/Right or Ctrl+Delete/Backspace). With many identifiers you have to hit the shortcuts 3/4/5 times in a 
row, which is a nuisance. Not only the fact that you need to hit them multiple times, but also that you have to get the 
number correct to select/delete the right amount matching the identifier. You just can't blindly perform "just 
select/delete that identifier here" any more, instead it becomes an iterative process that requires a greater amount of 
consciousness.

The action "Select Word" still selects a complete identifier, so I guess this could be an alternative (unless this is 
actually a defect); but there's no standard shortcut for it. More importantly, this behavior of the Ctrl+* shortcuts 
breaks consistency with other editors and other file types. I don't know about you, but I often have to or want to work 
with other editor software for specific tasks. It's not good to have to switch the shortcuts you use to select an 
identifier depending on which editor you happen to be working in at the moment, or which file type you're working with 
in NetBeans. Even within a Java source file in NetBeans, word positioning behavior now is different for words in 
comments and string literals than for normal source code. While I can see the benefit of being able to jump through 
camel case positions, I think this user interface inconsistency is a bad thing. My user experience certainly suffers.

So, I believe the minimum would be to provide this as a real option under Tools->Options.
Furthermore, specific camel case positioning actions should probably be available as dedicated actions, so that people 
who switched off camel case word positioning can still bind these to some other shortcuts. For example, non-Linux users 
might actually want to use Ctrl+Alt+* for these.
Comment 28 Vitezslav Stejskal 2007-07-25 15:32:42 UTC
Thanks for your feedback. We will see what can be done for nb6, but do not expect much.
Comment 29 Miloslav Metelka 2007-07-30 13:18:39 UTC
Please use Alt+Shift+J to select an identifier under cursor (used to be Alt+J in the old shortcuts).
Comment 30 Ondrej Langr 2007-08-01 14:19:54 UTC
The agreement from nb-usability was to introduce the option for camel case behavior. This option should have been in
Options|Editor (see http://ui.netbeans.org/docs/ui/options2/index.html#editor) and was intended to be implemented
together with moving the editor options from 'Advanced Options'. Unfortunately, moving advanced editor options has been
postponed for after 6.0 so the camel case option has also been forgoten. Is it possible to add the option for 6.0? If
so, let me know and I'll provide a UI draft. The option wording in the one linked above would have to be changed
slightly in order to respect that Editor|General is not Java-specific panel while camel case behavior is.
Comment 31 Vitezslav Stejskal 2007-08-20 12:34:06 UTC
Yes, adding the option should be simple. Please attach the proposed UI and I'll implement it. Thanks.
Comment 32 Ondrej Langr 2007-09-04 13:11:06 UTC
Created attachment 48039 [details]
camelcase option UI proposal
Comment 33 Ondrej Langr 2007-09-04 13:12:15 UTC
The proposed UI is attached. It is based on original option spec, but I reversed changes which were proposed but not
done.  I am not personally completely happy with this option, mostly because it is (as of now) java-specific option and
it will be present in general panel, but with current situation in option panel it is IMO the best we can do as the
option does not fit anywhere in the 'java code' node. 
Comment 34 Vitezslav Stejskal 2007-09-06 11:49:27 UTC
Cool, thanks for the spec. I'm making it P2 to give it more attention. Hrebejku, this one is probably something a
manager could fix :-). Have you got some free cycles?
Comment 35 Petr Hrebejk 2007-09-06 15:37:31 UTC
Yes, Sir.

Checking in editor/options/src/org/netbeans/modules/options/generaleditor/GeneralEditorPanel.java;
/cvs/editor/options/src/org/netbeans/modules/options/generaleditor/GeneralEditorPanel.java,v  <--  GeneralEditorPanel.java
new revision: 1.11; previous revision: 1.10
done
Checking in editor/options/src/org/netbeans/modules/options/generaleditor/Bundle.properties;
/cvs/editor/options/src/org/netbeans/modules/options/generaleditor/Bundle.properties,v  <--  Bundle.properties
new revision: 1.7; previous revision: 1.6
done
Checking in editor/options/src/org/netbeans/modules/options/generaleditor/Model.java;
/cvs/editor/options/src/org/netbeans/modules/options/generaleditor/Model.java,v  <--  Model.java
new revision: 1.10; previous revision: 1.9
done
Checking in editor/options/src/org/netbeans/modules/options/generaleditor/GeneralEditorPanel.form;
/cvs/editor/options/src/org/netbeans/modules/options/generaleditor/GeneralEditorPanel.form,v  <--  GeneralEditorPanel.form
new revision: 1.3; previous revision: 1.2
done
Checking in java/editor/src/org/netbeans/modules/editor/java/AbstractCamelCasePosition.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/AbstractCamelCasePosition.java,v  <--  AbstractCamelCasePosition.java
new revision: 1.3; previous revision: 1.2
done
Comment 36 matthies 2007-09-17 12:41:33 UTC
Verified in build 200709130000.