~ (tilde) Key requires a double keypress to be displayed

[scottmc]

At first I just thought I have a bad key on my keyboard, but now I've noticed it happens only when I'm in Haiku and happens on any keyboard I've used in Haiku so it seems it's a haiku bug. Not sure if this is related to an already reported bug or not though.

[axeld]

Isn't that just the default for the US-International keymap? IOW it's just a deadkey and should be like that?

[bonefish]

Replying to axeld:

Isn't that just the default for the US-International keymap? IOW it's just a deadkey and should be like that?

Maybe, but then we should change the default keymap to American, which seems to work as expected.

[umccullough]

Yes, it's always been this way in the default image AFAICR.

Interestingly, if you execute "cd ~" and the ~ doesn't appear in the shell (because you didn't press it twice) it still changes to your home directory anyway :)

[koki]

Isn't that just the default for the US-International keymap? IOW it's just a deadkey and should be like that?

Yes, this is in fact the expected behavior for the US-International keymap.

[stippi]

But there is definitely something fishy with the ~ key. It works differently in Haiku than what I am used to. For example, if you press it and then move the cursor, it should dump the character. I think in Haiku you have to press it twice for that to happen.

[koki]

The behavior described in this bug is the expected behavior of a deadkey; for example, pressing "~" followed by "n" will display "ñ".

There is some strange behavior when you want to cancel input before you press the second keystroke, but it looks to me like that would probably require a different bug report.

[aldeck]

I've got this annoying problem here too since forever (fr keymap, not sure its relevant, see below)

Interestingly i just noticed that the bug appears only when you type rapidly '~' then 'space'. Waiting a bit after typing '~' shows the expected behavior. In terminal, it seems there is a change in the cursor blinking when its ok to type the second key. Tested in Terminal and StyledEdit.

HTH

[bga]

Yes, the bahaviour is very weird. You actually have to delay typing the following key after a dead key for it to work as expected and this kills my typing speed. A timing issue in input_server maybe?

[scottmc]

This has changed recently (i'm guessing in builds after hrev30700 or so?), now you only need to press the ~ key once to have it register, but it doesn't get displayed until another key is pressed. Pressing it twice will give you .

[bonefish]

Tilde is a dead key in the US-International layout, so this should be the expected behavior. Unless I miss something, the ticket can be closed.

[jscipione]

I am reopening this bug as I am working on adding AltGr (Shift Level 3) maps to the keymaps which will fix this bug more properly by assigning the deadkey to option+n instead of ~. To type ñ you type either left-option+N followed by N or right-option+N. This will free up the ~ key for use in the terminal and other places. Setting deadkeys in the normal map of the default keymap is not acceptable for American users. International users use a different keymap, or, use the special keys provided via the Shift Level 2 and 3 maps in US-International.

[jscipione]

Assigning this ticket to myself

[korli]

You're talking about the American keymap, right? If not, I don't get it.

[jscipione]

Replying to korli:

You're talking about the American keymap, right? If not, I don't get it.

I am talking about US-International. Elucidate on what you don't get.

The American keymap (which I believe should be renamed "US" or "US-ASCII" since "American" is ambiguous) has no special characters in the option tables nor the altGr tables nor any dead keys. It produces only ASCII/single-bit UTF-8 characters.

[korli]

I think US-International is meant for international users, not american users as you seem to imply.

[jscipione]

Replying to korli:

I think US-International is meant for international users, not american users as you seem to imply.

Yes, that is mostly correct, although it is also used by English-speaking Canadian users.

But the US-International keymap is also used by American users with International needs. It is useful for any English-speaking country other than the UK and Ireland, (which use their own slightly different keymap) as well the Netherlands, (a Dutch speaking country that uses US-International).

If you fit the above description and regularly need to type multibyte UTF-8 characters, US-International is for you.

Now, getting back to the bug described by this ticket... the American and US-International keymaps should have identical normal, control, and shift maps. They are different only in regards to the option map. But, the dead keys specified in the normal maps breaks this causing this bug. Yes, you could use the American keymap to disable the deadkeys, but, then you also lose the international characters produced by the option key as well.

It is my intention to alter the US-International keymap so that it will produce dead keys only in combination with the option key, and to also to add additional support for special characters needed by international users making US-International suitable for all users specified above and most American and English speaking Canadian users as well.

[jscipione]

As of hrev43956 the dead keys have been moved to the option map for US-International. Therefore ~ is accessible via a single key press.