Twitcher summoned on CTRL+I

[humdinger]

This is hrev50749.

I suspect this has been true for a long time, but I never noticed:
For me CTRL+I does the same as CTRL+TAB, i.e. it switches between applications and summons the Twitcher window when held.

That can't be right. Some app may use that key combo. Like vim does for... already forgot it, like most of vim shortcuts. :)

[humdinger]

Just in case, here's the code calling the Twitcher/Switcher:
​http://xref.plausible.coop/source/xref/haiku/src/kits/interface/Window.cpp#3752

[pulkomandy]

Ctrl+I emits a TAB character. It is used in vim to... insert a TAB character.

How to tell:

• Take the ASCII table: ​http://www.asciitable.com/
• Control+letter are mapped to the ASCII codes 1 to 26.

So in the same way, control+H is backspace, control+J is a newline, etc.

If you dislike these, you can remove them from your keymap.

A few of them don't have direct access key (for example control+L = page break) and are sometimes used (in old C sources or manpages, finding a page break is not completely uncommon).

[bipolar]

Replying to pulkomandy:

Ctrl+I emits a TAB character. It is used in vim to... insert a TAB character. [...] So in the same way, control+H is backspace, control+J is a newline, etc.

If you dislike these, you can remove them from your keymap.

Jeez, this one was driving me nuts. I would have never have expected to have to modify the keymap to avoid this weird/unexpected behaviour (I don't recall seeing it even on Linux).

Specially confusing because I use "Windows/Linux" shortcuts mode, so ALT+I (what I see on the physical keyboard) was really making no sense at all.

Good thing that it can be modified from the Keymap preflet.

I still think these are bad defaults, but oh well... at least I can stop grepping the source code trying to find where CTRL+I was invoking the Twitcher :-D

One day will have a system wide KeyBindings preflet, and a working AltGr key... one can dream :-P

Edit: forgot to add... Thanks Pulkomandy for pointing out the workaround!

[pulkomandy]

I would have never have expected to have to modify the keymap to avoid this weird/unexpected behaviour (I don't recall seeing it even on Linux).

It works just the same in Linux for example in the Terminal. But not in all applications, since they use control for keyboard shortcuts usually. I think it's how this works in DOS too?

If we removed them from the keymap we would have to special-case them in Terminal so that it continues to work there.

[bipolar]

Replying to pulkomandy:

It works just the same in Linux for example in the Terminal. But not in all applications, since they use control for keyboard shortcuts usually. I think it's how this works in DOS too?

I should have expressed myself better: I guess I only ever expected those to work on a console shell, and was really not expecting them outside one (and don't recall encountering them, even on Linux GUI environments, that was what I failed to express).

DOS has, at the very least, ^Z as "EOF" marker for things like "copy con", for sure.

If we removed them from the keymap we would have to special-case them in Terminal so that it continues to work there.

That sounds like a good compromise solution, more close to where they are more likely to be needed/used/expected.

I any case... happy to have found a workaround in the meantime! Thanks again!

[nephele]

If we removed them from the keymap we would have to special-case them in Terminal so that it continues to work there.

sounds like the better option to me, terminal really is a special case here