laubstein / workspacemechanic

Automatically exported from code.google.com/p/workspacemechanic
0 stars 0 forks source link

Import of multi-key shortcuts (emacs-like) does not work #105

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a emacs-like keyboard shortcut
e.g. Ctrl+R, R for "refactor, rename"

2. dump key bindings with Workspacemechanic
The result should be something like:
{
  "metadata" : {
    "description" : "Keyboard multi-stroke bindings failing"
  },
  "changeSets" : [    
    {
    "scheme" : "org.eclipse.ui.defaultAcceleratorConfiguration",
    "context" : "org.eclipse.jdt.ui.javaEditorScope",
    "action" : "add",
    "bindings" : [
      {"keys" : "Ctrl+R, R", "cmd" : "org.eclipse.jdt.ui.edit.text.java.rename.element"},
      ]
    },   
  ]
}

3. Try to import the bindings into another workspace

What is the expected output? What do you see instead?
Expected: Import window with key-strokes listed

Actual result: 
Eclipse error Message:
"An error has occurred. See error log for more details.
org.eclipse.jface.bindings.keys.ParseException: Could not construct key 
sequence with these key strokes: []"

What version of the product are you using? On what operating system?
Eclipse 3.4 with Workspacemechanic 3.4 on Windows 7

Please provide any additional information below.

Original issue reported on code.google.com by uhdre...@googlemail.com on 21 Jan 2013 at 1:41

GoogleCodeExporter commented 9 years ago

Original comment by konigsb...@gmail.com on 21 Jan 2013 at 2:57

GoogleCodeExporter commented 9 years ago
I think I found the bug: EclBinding uses TriggerSequence.format() to get the 
Key-Sequence-String but the result is modified by operating system and locale:
On my machine the separator for a 2 key stroke command is separated by ", " not 
by " " as expected by the parser.

added a possible fix and 2 unit-tests (1 ignored as its only meaningful on a 
win32 machine (possibly with german locale)
and one where i forced a formatter that has the same behaviour in all cases.

Please review.

Original comment by uhdre...@googlemail.com on 3 Mar 2013 at 7:53

Attachments: