Userscript to make sure editor tab gets swtiched on CTRL+TAB


trying to do something like this:


but that does not work out as expected.
It works as cmd_focusEditor would be ignored, basically go to any bottom pane, run it, the bottom pane gets switched and the editor also, then the editor gets the focus.

What’s wrong?

Morning @agroszer,

This actually does exactly what you describe as the desired behavior, for me.

  • I click on any of the tabs in the bottom pane
  • I either double click the Userscript or trigger the keybinding I added
  • Bottom pane tab selection remains the same, editor tab swaps to most next in tab history

How are you executing the Userscript?

  • Carey


I added a key binding of CTRL+TAB to the userscript after I removed CTRL+TAB from “General: Most Recently Viewed File”.
If add a different hotkey, like… F8, then the userscript works as expected.
I got a feeling that CTRL+TAB is caught first by the pane’s tab control…

@agroszer, supporting ctrl+tab would require overriding a Mozilla binding which we’re not going to do in the Komodo core. And yes, this would cause the execution you’re seeing.

  • Carey

@agroszer I saw you’re issue passing by about this problem.
I must admit, I also sometimes get lost in the tabs.

I build a small addon to handle the ctrl + tab behavior before komodo kicks in.
But I couldn’t get rid of the “default” behavior (first the tab get switched before the editor gets focused).
But after all, the solution doesn’t require a addon at all, but can be handled with a small userscript on start-up.

var leftPane = document.getElementById('workspace_left_area'),
    rightPane = document.getElementById('workspace_right_area'),
    bottomPane = document.getElementById('workspace_bottom_area');
leftPane.handleCtrlTab = false;
rightPane.handleCtrlTab = false;
bottomPane.handleCtrlTab = false;

A pane has a handleCtrlTab property and I have to agree with @agroszer, that it should be disabled by default for all panes. As you don’t want to have a keybinding with different behaviors, it should do what you expected it to do.

Reference to related gitub issue:

But will continue conversation here.

I don’t agree with this. When I’m focused on something that has tabs I want to be able to “tab” through them. I’ve actually wanted this to occur in the sides/bottom pane for ages but just accepted the state of things long before I actually start coding and was just testing Komodo (so never thought to fix it).

IF it functioned as I mentioned above, would you two prefer that? There are key bindings to focus on each pane and the editor. I’d be more interested in being able to focus on an area of Komodo and tab through the panes there rather than just disabling tabbing.

  • Carey


Apparently we’re different. The solution is probably to make it configurable. But I guess if it’s just the 2 of us, some userscripts are fine.

@careyh there is also a other issue related:

At first I was thinking the same thing.
But when I was thinking of it, when I interact with the panels, I only use the “toggle” panel keybinding.
But when I interact with the tabs, for me it’s a mouse interaction and I think for most users it is.
I could not think of a use-case where I want to use my keyboard to toggle trough the tabs in the panels.
Only when you want to do everything with you’re keyboard.

Also my color schemes only show a active state and not a focused state, so I can not see if I’m able to toggle trough the tabs. I don’t know how it is in the default?

I would prefer the keybinding doing what it should do, than having two different kind of behaviors under one keybinding. As for me the second behavior is always unexpected, I just wanted to switch views.

I think you should disable it by default and maybe create a new keybinding for the behavior you’re describing for the diehards who only want to use the keyboard.