ADS to support custom key bindings in query analyzer / all our text editors. Key bindings such as "Cut to end of line", etc. ADS could then offer a "Default" and "Emacs" key binding options along w/ being able to override any specific key binding.

We can discuss this next week as well

Attached please find the proposed list of "Emacs" key mappings. This list only shows key binding differences between "Default" and "Emacs", and is a result of comparisons done on Eclipse editor (TeraData Studio Express is based on the Eclipse Rich Client Platform), Netbeans editor and ADS editor. For other actions not on the list, the "Emacs" key mappings should be identical to the "Default" key mappings (unless there is conflict).

Here are the high-level tasks breakdown:

1. Move the "Edit:XXXXX" options from current File->Options->Key Mappings->General category to a new "Text Editor" category. New actions will be added to this new category.

2. Create/map Emacs key bindings on existing actions

3. Design and implement Multi-keystroke key mapping mechanism (e.g. "Esc, W")

4. Implement new actions. Add Emacs key bindings accordingly

Do note in SQLEditorKeyBindings that there is a mechanism for Multi-keystrokes with MultiKeyBinding.  I am assuming we just need to build the UI and storage mechanism for this, but no editor enhancements would be required.

This looks good. How about migration impact? Scenarios to consider:

1) By moving the Edit:XXXX options, do we have to do any migration of existing key bindings?

2) Since we're introducing a new keymap, Emacs, and not changing the key mappings in default, I assume we don't have to worry about any potential conflicts?

1) By moving the Edit:XXXX options, do we have to do any migration of existing key bindings?

Yes, we will have to migrate exiting key bindings. If we don't want to deal with migration, then we can just add more "Edit:XXXXX" options - currently the "General" category already contains 120 key bindings.

2) Since we're introducing a new keymap, Emacs, and not changing the key mappings in default, I assume we don't have to worry about any potential conflicts?

If you mean conflict within the same profile, then no, we shouldn't have any conflicts. But key mappings among profiles could conflict (i.e. Ctrl+W in Emacs could perform different action than Ctrl+W in Default)

I do the prefer the new Edit category but want to better the understand its impact. Once you get to migration, can you describe how it will work so that QA can test it appropriately. e.g. Will ADS v14 detect old and new formats and if an old format is detected, it will convert to new format and write this new format back to disk immediately or ...

What happens if an older version of ADS tries to read the new format....

In the past, have we had to deal with such migrations?

Migration behavior:

A few notes on the design and implementation of MultiKeymap key bindings.

1. There is a new "Text Editor" category. This category and the "General" category share the same key binding space. This means that bindings in these categories are checked for conflicts together

2. Not all key bindings support "alternatives" (i.e. ability to map multiple key bindings to the same action). Specifically, only selective key bindings in the Text Editor category supports "alternatives" (because NetBeans EditorKit supports multiple key bindings)

3. Not all key bindings support multi-keystroke sequence (e.g. "Ctrl-X" followed by "0"). Specifically, an action that correspond to a menu item (i.e. menu item accelerator) cannot have its default binding be multi-keystroke because currently our menu processing code does not support multi-keystroke accelerators

I've posted the current ( as of june 13, 2012 3pm ) keymap for defaults to v14 documentation here.

Let me know if there is anything I need to do to alter this 

https://www.aquaclusters.com/app/home/project/public/aquadatastudio/wikibook/Documentation14/page/65/Key-Mapping-Options-and-Key-Assist-Tool

Verified in 14.0.0-rc-4. I will close after going through with Jonathan 6 Emacs keys which were not working for me and migration scenarios

Verified entire key bindings in Win 7, Mac OS and Ubuntu (VMware on a Mac machine with mac keyboard)