Community
Participate
Working Groups
We have several different "modes" in the editor that want to grab bindings until they are done. (Content assist, incremental search, etc.) Then we also have "modes" such as keyassist panel or search popup that the user can invoke from the editor, which need to be cancellable from the editor. In this case, it's a little different. It's not that we want to grab all keys from the editor, just that we need to know about certain keys (such as Esc or Enter) which the editor or other modes would also care about. For 0.2 release, I originally implemented a "keyModes" array in the editor which kept track of which mode was active and forwarded the relevant shared keys. This worked for content assist, incremental search and other modes. But then, we needed to let external parties, outside of the keybinding factories, etc. also participate in some keys like Esc. (bug 348792). I did the minimal fix needed for 0.2 RC1, which was to hook into the existing keyModes and then track another level of external Esc handlers. We need to bring all this together into "real" API where callers register themselves as a mode with the editor, say what the triggering key is (if any), what keys they are interested in, etc. rather than what we have today, which is that the factories know about the keymode stack in the editor, and we have multiple levels of Esc handling.
we should decide if we want to continue to layer this support in editor or if TextView should have some underlying support. What it needs to look like is something like this (using pseudo code and keybinding shorthand) editorOrTextView.registerMode("modename", triggeringBinding, keysImInterestedInWhileAlive, endingbinding) So we'd have editorOrTextView.registerMode("keyAssist", Shift+Ctrl+/, [], Esc) editorOrTextView.registerMode("incrementalSearch", Ctrl+J, [lineup, linedown, ctrl-k, etc. etc.], Esc) editorOrTextView.registerMode("contentAssist", Ctrl+Space, [lineup, linedown, enter], Esc) Or maybe the endingBinding is added to "keysImInterestedInWhileAlive" and there is an explicit call to end a mode. Depending on whether you want the modes and transfer of control to be completely managed on the inside or not. While a mode is alive, keys that the mode is not interested in continue to be passed onto the editor or registered actions. The ones the mode is interested in are handled by the mode.
There are also modes that end by keybinding (esc, enter), but should also end when other things happen in the editor. For example, content assist closes when it receives onVerify or onSelection.
Hi Susan, One thing that I have in my mind is to add support for multi-stroke keybinding in the text view (VIM style shortcuts). Silenio and I never had the time to mature this idea into a API proposal, but we thought that maybe this multi-stroke keybinding API could be used by the editor to implement modes. Not sure yet if it makes sense to mix the two concepts (models and multi-stroke keybinding).
Ran into this issue again while fixing bug 361678. We had some "esc modes" that were eating esc keys, causing other modes not to get them. I made a minimal fix in the editor, but there are still oddities with these modes. For example, in the editor: Ctrl+Shift+L (key assist pops up) Ctrl+Space (content assist pops up) Esc (both content assist and key assist are dismissed) I could see how a user might expect only content assist to dismiss. For this to work, the editor would really have to know about modes, and in this example, there is an outer an inner mode. I'm not suggesting we have layers of modes, but perhaps if we had real modes in the editor, key assist would dismiss before content assist was activated. (not sure that is user expectation either, but less weird than what happens now).
(In reply to comment #3) > Hi Susan, > > One thing that I have in my mind is to add support for multi-stroke keybinding > in the text view (VIM style shortcuts). > Silenio and I never had the time to mature this idea into a API proposal, but > we thought that maybe this multi-stroke keybinding API could be used by the > editor to implement modes. Not sure yet if it makes sense to mix the two > concepts (models and multi-stroke keybinding). I think multi stroke binding is a separate thing. It's going to be more important for avoiding keybinding conflicts with browser shortcuts, etc. and many web bindings (such as gmail) are using them. Opened bug 364998 so we can track this separately from the modes issue.
This is fixed in 3.0. All key bindings, content assist, linked mode, incremental find use the same underlining support (orion.editor.KeyMode). The key modes stack was pushed down to the TextView level. The top of the stack is the active mode which handles bindings first and can decide whether to fall through to previous modes in the stack. The key assist and search file panels are not really key modes. And they do not need to handle ESC in the editor specially anymore (since the editor is no longer embedded in a IFRAME). JSDoc is still not up to date (see bug#406597 for that).
