Bugzilla – Full Text Bug Listing
| Summary: | [key binding] Comment source code uses impossible keyboard shortcut | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Oyvind Harboe <oyvind.harboe> |
| Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alex.blewitt, csmclaren, douglas.pollock, georg.sendt, kozusznikj, lbloom, rdabra |
| Version: | 3.0 | ||
| Target Milestone: | 3.0 M7 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | 46589 | ||
| Bug Blocks: | |||
|
Description
Oyvind Harboe
doug could you comment on whether we are doing something wrong (with the shifted/unshifted key stroke guesser?). if not, send to jdt, and keep a note of this norwegian specific rule for when we document recommended key bindings. Øyvind is right. The offending key bindings are: "Ctrl+/" Comment "Ctrl+Shift+/" Block Comment I think platform-ui would like to strongly discourage people from binding anything but "Ctrl+[A-Z]" and "Ctrl+Shift+[G-Z]" key sequences. Numeric, function and punctuation key strokes are far too likely to conflict with window managers and locales. In this vein, we are planning on making the document mentioned by Chris. That aside, these two key bindings simply won't play nice with each other on at least the Norwegian, German, and Swiss German locales. Cross-testing, I can't seem to get the "Ctrl+Shift+/" key binding to work on the US locale on Windows XP using I20030816 (i.e., before overhaul of key bindings) -- possibly because Windows does it's own magic shift resolution. For perspective, other IDEs use the following: "Ctrl+Shift+T" - Comment (NetBeans) "Ctrl+Shift+D" - Uncomment (NetBeans) "Ctrl+M" - Comment (KDevelop) "Ctrl+Alt+M" - Uncomment (KDevelop) "Ctrl+K Ctrl+C" - Comment (Visual Studio) "Ctrl+K Ctrl+U" - Uncomment (Visual Studio) We are currently working with SWT toward a resolution of Bug 44003, which would most likely see us encouraging the use of multi-stroke key bindings. This seems to the approach taken by Microsoft Visual Studio to deal with a burgeoning collection of key bindings. Moving to text since they own most of the shortcuts. It works if users look at the "key" as whole i.e. if he treats "/" as pressing that key where / is printed on (not that character) i.e. me using a Swiss German key board I press: Ctrl + [7,/] ==> comment Ctrl + Shift + [7,/] ==> block comment The key binding dialog and the key sequence hints in the menus have to take this into account. doug? (It looks like the reason it wasn't working on Windows XP (US) was that the action itself is not enabling. What do you need to do to get it enabled?) Dani: the behaviour described is platform-specific. I don't believe it is portable. At least, this is not the default behaviour for GTK. On GTK, pressing "Ctrl+Shift+7" is registered as "Ctrl+/"; there is no way to access "Ctrl+Shift+/". JDT seems to be relying on the native widget toolkit behaviour to resolve what is really a conflict in the key binding in some locales. Even if all native toolkits worked the same, our key binding resolution algorithm is not capable of translating "Ctrl+7" into "Ctrl+/". It can only do the reverse translation (i.e., "Ctrl+Shift+7" -> "Ctrl+/" or "Ctrl+Shift+/"). This is a limitation of SWT, as they provide no key look-up facility. So, anything not on the menu will be bound by this limitation. For these reasons, we'd like to again strongly encourage other teams to avoid using punctuation or numbers as key bindings. Otherwise, i18n and platform issues will arise. Please stick to "Ctrl+[A-Z]" and "Ctrl+Shift+[G-Z]" key bindings wherever possible. To answer your suggestions: The key binding dialog expresses trapped key strokes in the "lower form". Typing "Ctrl+Shift+7" on a Norwegian keyboard would be registered as "Ctrl+Shift+7" -- rather than either of the other two possibilities: "Ctrl+/" or "Ctrl+Shift+/". This format is portable. Someone using the same keyboard on either a Windows or a GTK machine would be able to type the same key stroke and get the same result. The menus currently display the key stroke that is bound to that action/command. Again, the lack of an SWT key look-up table prevents us from translating key strokes to a "lower form". These are even more reasons why we would like to encourage people to avoid key strokes that have an "upper" and "lower" form. Would JDT please reconsider its use of "Ctrl[+Shift]+/" and "Ctrl[+Shift]+\" as key bindings? (and sorry for the long reply. I figured this request needed some background.) >strokes that have an "upper" and "lower" form
How would we know? There are many different keyboard layouts (actually
indefinitely since users can create their own layouts at least on the Windows
platform). Following that rule Platform-UI would also have to change Ctrl+.,
Ctrl+ and Ctrl+- since they also share the key with another character (at least
on my Swiss German keyboard).
While it is possible for a malicious user to make a keyboard that would break any policy we come up with for key bindings, it is not really reasonable to defend against that possibility. Also, I believe pretty much everyone will still keep 'c' and 'C' on the same key. Our rule is to stick to alphabetic keys specifically for this reason. Unfortunately, this bug catches us before we had time yet to officially propose a policy for key bindings. :( This is why you haven't heard anything about this, and this is why platform is still using "bad" key bindings. This bug is pushing the point however, as the current JDT comment and block comment key bindings do conflict. I'll see what we can do about getting the ball rolling a bit more. We will try to find a yet unused key binding. However a quick look shows that at least all Ctrl+ sequences are already taken. And overloading (by using different scopes) is not something I'd like to do (or see as a user). Why is the range for Ctrl+Shift only [G-Z] and not [A-Z]? See Bug 42009 for why "Ctrl+Shift+[A-F]" can cause problems. (It's a much disliked feature of GTK.) May I suggest multiple stroke key bindings? One of the suggestions that we are likely going to make is to move to multiple stroke key bindings. It will help clear out some of the key binding space. For example, Visual Studio uses "Ctrl+K" to start text formatting commands. So, "Comment" is "Ctrl+K Ctrl+C". Unfortunately, the key binding space is already crowded out of good prefixes. :( "Ctrl+Shift+I", "Ctrl+Shift+L", "Ctrl+Shift+N", "Ctrl+Shift+V" and "Ctrl+Shift+Z" are the only ones left in the recommended space. You could grab a couple of these, or you could just wait. I'd imagine that -- before 3.0-final -- there is going to be a shake down of key bindings. JDT can grab some good ones for multi-key bindings then. Windows also has this input mode switching feature. Though I can't remember whether it is on by default (if there's more than one installed) and which keys are used since I disabled those keys. One (out of two!) possible choices is Ctrl+Shift (!). Maybe we assign different key bindings depending on the platform. We already did so for carbon (mac). Mac is a special case. (I don't know how many times Mac has turned out to be a "special case" in the past few months, but it's getting irritating.) The Mac is really just mapping Control->Command. On the Mac keyboard, the Command key is even in the same place as a Control key on a Windows keyboard. It's really just cosmetic; there isn't much a difference under the hood. There is an argument for consistent key bindings across platforms. It goes something like this. Imagine a work environment similar to the platform UI team. I work on GTK primarily, Chris works on Carbon, and Nick (our technical lead) works on Windows. I have a design issue to go through with Nick, so he stops by my machine. We start working together on some code. At one point, Nick takes over the keyboard. Now, in this scenario, we can see how things can go wrong. Nick presses a Window-specific key binding, and nothing happens. Nick is surprised. I dislike surprising Nick (unless it's a pleasant surprise). (It also has the nice effect of simplifying our set of key bindings. What happens if you grab some other key binding on GTK to avoid a conflict, and then someone wants to use that key binding on Windows? I think this is a much faster route to exhausting our available key binding space....) Windows does have an input mode switching feature, but they were more sane about it. It is "Alt+Shift+[0-9]" (on the numeric keypad only). For example, 233=Ú, 245=§, 128=Ç, 129=ü, 130=é, etc. If there is a "Ctrl+Shift+" input mode for Windows, I've yet to find it. :) (Doesn't mean it's not there though.) >If there is a "Ctrl+Shift+" input mode for Windows, I've yet to find it. :)
On WindowsXp (which in contrast to Win2k is the version supported by Eclipse):
1. Open the control panel and then Regional Settings.
2. Click on "Languages" tab
3. Click on "Details"
4. Ensure there's more than one language installed
5. Click "Key Settings..."
6. Select "Switch between input languages"
7. Click "Change Key Sequence..."
You can now select "Ctrl+Shift" to directly do the switching. If you dismiss
that dialog and select a concrete language then you can also assign
Ctrl+Shift+[0..9]
Will be done during a key binding clean up session. *** Bug 46856 has been marked as a duplicate of this bug. *** *** Bug 28270 has been marked as a duplicate of this bug. *** Platform UI has provided a new key configuration in today's integration build
(I20031202). The key configuration is called "Standard (3.0) - NEW!". In this
key binding, the comment keyboard shortcuts are:
Ctrl+K Ctrl+B Add Block Comment
Ctrl+K Ctrl+C Comment
Ctrl+K Ctrl+R Remove Block Comment
Ctrl+K Ctrl+U Uncomment
We'd appreciate your feedback on this key configuration. Please provide
feedback to Bug 37934.
*** Bug 49340 has been marked as a duplicate of this bug. *** *** Bug 36130 has been marked as a duplicate of this bug. *** We now added a Toggle Comment action bound to Ctrl+Shift+C. This action replaces Comment/Uncomment in the menus. Those who want to continue Comment/Uncomment can assign their favorite key sequence via Window > Preferences > Workbench > Keys (Source category). Available in builds > 20040123 *** Bug 35002 has been marked as a duplicate of this bug. *** Have you cross-tested this key binding on GTK? My impression is that it will not work.... No it will not. We plan to fix the Ctrl+Shift+* problem on GTK in a separate pass including other affected commands like format. The idea (only for GKT) is to use Ctr+P wherever we use Ctr+Shift which would result in toggle comment: Ctrl+P, Ctrl+C print: Ctrl+P, Ctrl+P format: Ctrl+P, Ctrl+F ... May I recommend using "Ctrl+K". This is consistent with the new key binding set, as well as with Microsoft Visual Studio. "Ctrl+P" is typically reserved for "Print". I can do so, but it might upset "old" Eclipse users which got used to Ctrl+K to find the next word (quite useful and often used command). Regarding Ctrl+P: who prints anyway and AFAIK printing on GTK isn't working ;-). Doug, we revisited the decision using Ctrl+P for Ctrl+Shift on GTK again and changed our mind to use Esc which would result in toggle comment: Esc Ctrl+C format: Esc Ctrl+F ... Commands which use Ctrl+Shift and work on GTK will not be changed. Are there any objections or limitations you see on GTK? I don't know of any limitations on GTK. |