Dead keys don't work in Windows Terminal (German keyboard)

[Alpengreis]

For a physical swiss german keyboard:

AltGr + ' → ´ (Dead Key)
AltGr + ^ → ~ (Dead Key)
^ → ^ (Dead Key)
Shift + ^ → ` (Dead Key)
¨ → ¨ (Dead Key)

maybe there are more but I'm currently in bed with Smartphone only ...

 

[vefatica]

Rex might mean ... what (exactly) do you press to get these?

Test input: áà-äâ-ȧā-ạα

 

[Alpengreis]

On my Swiss German keyboard, these are produced as follows:


á = AltGr + ´, then a
à = Shift + ^, then a
ä = ä key
â = ^, then a


The remaining characters ȧ, ā, ạ and α are not produced by the standard Swiss German keyboard layout with a normal dead-key combination.

Hope I'm right with those ... Also there are more combos yet AFAIK ... but I haven't an exact table for it ...

 

[Marty]

That unfortunately doesn't mean anything to me. What key(s) are you pressing for the grave accent, and what do you get versus what you expect>

On a German keyboard, the acute and the grave accent are located on a separate, common key. To produce the grave accent, you need to press Shift together with this key. Here is the keyboard layout:

When pressing this key (with or without Shift), nothing happens but a second keystroke is expected which then produces a character. That works with your latest build. However, the grave key combination (Shift + the accent key marked above) only creates the character of the second keystroke without the accent.

But wait, I just noticed something strange. On my desktop PC, none of the dead keys work with TCC 36.52.83. All of them still create a space after the second keystroke (including the circumflex accent on the leftmost key in the top row). On my laptop, though, the non-Shift accents work and only the grave accent does not (as described above). With TCC 36.01.55 everything works correctly on both machines. I have no idea what's going on there.

Unfortunately, I can't upload screen recordings here to show the behavior.

 

[mfarah]

I have read your message 5 times, and I still don't have the slightest idea what you are saying.

You refer to your "test input" with no hint how you generated that test input.

Assume that I know absolutely nothing about dead keys, AltGr keys, layers of dead keys, etc. Because I don't.

What I need is a detailed description of the keyboard layout you're using, the environment you're testing in (basic console, WT, or TCMD), and exactly what keys you're pressing, in order, and what you get versus what you expected to get.

Say you want to type a semicolon (';') on a computer keyboard. When you press this key:

in a computer keyboard, even in one that doesn't say ";" in its printed legend, what the keyboard actually sends is the scan code that corresponds to that physical key: 0x27 in this example.

(in this diagram, the black legends refer to the ISO9995 names; the blue legends are the actual scan codes)

The operating System (Windows, Linux, etc.) receives that scan code, looks it up in a conversion table and determines the character to produce, based on its input. Said conversion table is, essentially, the "keyboard layout" or "national layout". So the operating system produces, from 0x27...

• ... if you're using the English (USA) ("en-US") layout, the character ';'.
• ... if you're using the English (UK) ("en-UK") layout, the character ';'.
• ... if you're using the German ("de") layout, the character 'ö'.
• ... if you're using any of the Spanish layouts ("es-ES", "es-LA", "es-IB", plus one we don't talk about in polite company), the character 'ñ'.
• ... if you're using either of the Portuguese layouts ("pt-PT" and "pt-BR"), the character 'ç'.
• (etc.; there are dozens of national layouts, plus countless variations)

A "dead key" is a special assignment in the layout where, upon pressing, the operating system knows it needs to wait for the next scan code to come in, to determine what to actually produce. So, for example, in the Spanish (Spain) ("es-ES" layout), if you press the C11 key and then the D03 key, the scan codes sent will be 0x28 and 0x12, which the operating system will interpret as "Dead key for the acute accent", "lowercase e" ⇒ 'é' will be produced.

To get the same 'é' in the German layout, you'll instead have to press E12 and then D03, as the dead key for the acute accent is placed in the number row.

(to be continued)

 

[mfarah]

Actually, when you press any key, two distinct events are recorded and sent to the computer: a MAKE code (the user pressed the key) and a BREAK code (the user released the key). You can see this in action in the "DOWN" and "UP" messages in the Switch Hitter screenshot. This is how the operating system "knows" that, say, Shift is pressed, so 0x27 should produce a ':' instead of a ';'.

So, two characters per key? More like "up to four" (up to six, if you're Canadian; you don't want to know). A keyboard layout recognizes four distinct layers ("levels", in ISO9995 parlance), that alter the meaning of the unique scan code of an alphanumeric key:

• Base ("regular", for ISO9995): no modifier keys are pressed while the alphanumeric key is pressed and released.
• Shift: either Shift key (B99 or B12) is pressed while the alphanumeric key is pressed and released.
• AltGr: the AltGr key (A08) is pressed while the alphanumeric key is pressed and released.
• AltGr-Shift: both the AltGr and either Shift key is pressed while the alphanumeric key is pressed and released.

In this example from the Danish layout, the B07 ("VK_M", in Microsoft's parlance) key is made to be capable of producing three characters: 'm' in the base layer, 'M' in the Shift layer and 'µ' in the AltGr layer; the AltGr-Shift layer is unassigned and does not produce anything.

The E12 ("VK_OEM_4" for MS) key produces the acute accent dead key in the base layer, the grave accent dead key in the Shift layer and the (not quite dead) character '|' in the AltGr layer.

Those two screenshots correspond to MSKLC, Microsoft's program that allows a user to create his or her own adapted or entirely custom layouts. I used it first to both extend both es-ES and es-LA, to cover their omissions, and then I created a third Spanish layout, es-IB, with the ultimate (if rather Quixotic) intention of replacing both... and this is what I daily drive:

Every red symbol here is a dead key — fourteen dead keys for diacritical signs ("áàāȧǎ..."), five more for "alternate letters" ("əǷß..."), miscellaneous ("⇒¦♠⋮☑ⁿ...") and currency ("₩€¥£₱₤₣₧...") symbols and even one to type Greek letters ("αβγδε...").

 

[mfarah]

I have read your message 5 times, and I still don't have the slightest idea what you are saying.

You refer to your "test input" with no hint how you generated that test input.

Assume that I know absolutely nothing about dead keys, AltGr keys, layers of dead keys, etc. Because I don't.

What I need is a detailed description of the keyboard layout you're using, the environment you're testing in (basic console, WT, or TCMD), and exactly what keys you're pressing, in order, and what you get versus what you expected to get.

With both previous posts in mind, what I meant by:

Test input: áà-äâ-ȧā-ạα

Was simply to open a TCC instance, and then type on the keyboard each of those characters one by one, first dead key and then the "letter a", with hyphens in between each pair "for clarity". I am using the es-IB layout, pictured in the previous post (this because it gives me quick access to dead key assignments in all four layers).

• press and release C11 (0x28; acute accent dead key), press and release C01 (0x1E; letter a) ⇒ á
• press and release D11 (0x1A; grave accent dead key), press and release C01 (0x1E; letter a) ⇒ à
• press and release B10 (0x35; hyphen) ⇒ -
• press B99 (0x2A; left Shift), press and release C11 (0x28; diaeresis dead key), release B99, press and release C01 (0x1E; letter a) ⇒ ä
• [...]
• press A08 (0xE038; AltGr or right Alt), press B99 (0x2A; left Shift), press and release C11 (0x33; Greek letters dead key), release B99 and A08, press and release C01 (0x1E; letter a) ⇒ α

For said test input:

TCC 36.52.80 (installed within TCMD 36.50.80):

• TCC 36.52.80 running by itself in a Windows Console Host produces: aa-aa-ȧā-ạα (the dead keys in the base and Shift layers were ignored; the ones in the AltGr and AltGr-Shift layers were honored).
• TCC 36.52.80 running by itself in a Windows Terminal produces: aa-aa-ȧā-ạα (same as above).

• TCC 36.52.80 running over TCMD 36.52.80 (first tab; loaded by default) produces: áà-äâ-aa-aa (now the dead keys in the base and Shift layers are honored, while the latter two are ignored).
• TCC 36.52.80 running over TCMD 36.52.80 (explicitly run from Tabs ⇒ Run... ⇒ Start in ConPTY, App TCC) produces: áà-äâ-aa-aa (same as above).
• TCC 36.52.80 running over TCMD 36.52.80 (explicitly run from Tabs ⇒ Run... ⇒ Start in ConPTY, App Custom pointing explicitly to TCC.EXE) produces: áà-äâ-aa-aa (same as above).
• TCC 36.52.80 running over TCMD 36.52.80 (explicitly run from Tabs ⇒ Run... ⇒ Start in a New Tab, App TCC) produces: aa-aa-ȧā-ạα (same as TCC by itself).
• TCC 36.52.80 running over TCMD 36.52.80 (explicitly run from Tabs ⇒ Run... ⇒ Start in a New Tab, App Custom pointing explicitly to TCC.EXE) produces: aa-aa-ȧā-ạα (same as TCC by itself).

TCC 36.52.83 (the test build, installed as a stand-alone):

• TCC 36.52.83 running by itself in a Windows Console Host produces: aa-aa-ȧā-ạα (the dead keys in the base and Shift layers were ignored; the ones in the AltGr and AltGr-Shift layers were honored).
• TCC 36.52.83 running by itself in a Windows Terminal produces: aa-aa-ȧā-ạα (same as above).

• TCC 36.52.83 running over TCMD 36.52.80 (explicitly run from Tabs ⇒ Run... ⇒ Start in ConPTY, App Custom pointing explicitly to TCC.EXE) produces: aa-äâ-aa-aa (now only those two in the Shift layer work?? Or may it be because whatever fix was made in that build was done with those two specific diacritics in mind?).
• TCC 36.52.83 running over TCMD 36.52.80 (explicitly run from Tabs ⇒ Run... ⇒ Start in a New Tab, App Custom pointing explicitly to TCC.EXE) produces: aa-aa-ȧā-ạα (same as TCC by itself).

TCC 35.00.21 (reinstalled as a stand-alone):

• TCC 35.00.21 running by itself in a Windows Console Host produces: áà-äâ-ȧā-ạα (all dead keys work).
• TCC 35.00.21 running by itself in a Windows Terminal produces: áà-äâ-ȧā-ạα (all dead keys work).
• TCC 35.00.21 running over TCMD 36.52.80 (explicitly run from Tabs ⇒ Run... ⇒ Start in a New Tab, App Custom pointing explicitly to TCC.EXE) produces: áà-äâ-ȧā-ạα (all dead keys work).
• TCC 35.00.21 running over TCMD 36.52.80 (explicitly run from Tabs ⇒ Run... ⇒ Start in ConPTY, App Custom pointing explicitly to TCC.EXE) produces: aa-aa-aa-aa (NONE of the dead keys work).

I renamed away TCMD.INI and TCSTART.BTM and repeated every test. No different result was obtained.


All application windows with text input I've typed in, even CMD.EXE running by itself, work without issue in this regard. This seems to have started with TCMD 36.50; I don't have the 36.0 installer around, so I can't install it again and look at what happens.

This is happening in two different computers running in Windows 11; I'm installing 36.50.80 now in a computer running Windows 10. I'll report that in a new posting.

 

[Alpengreis]

And here a link to a swiss german keyboard layout yet:

QWERTZ - Wikipedia

en.wikipedia.org

 

[mfarah]

Turns out that that Windows 10 computer already had TCMD 36.50.71, which has distinct results.



TCC 36.50.71 (installed within TCMD 36.50.71):

• TCC 36.50.71 running by itself in a Windows Console Host produces: aa-aa-ȧā-ạα (the dead keys in the base and Shift layers were ignored; the ones in the AltGr and AltGr-Shift layers were honored).
• (no Windows Terminal available)

• TCC 36.50.71 running over TCMD 36.50.71 (first tab; loaded by default) produces: áà-äâ-ȧā-ạα (all the dead keys work).
• TCC 36.50.71 running over TCMD 36.50.71 (explicitly run from Tabs ⇒ Run... ⇒ Start in ConPTY, App TCC) produces: áà-äâ-ȧā-ạα (same as above).
• TCC 36.50.71 running over TCMD 36.50.71 (explicitly run from Tabs ⇒ Run... ⇒ Start in ConPTY, App Custom pointing explicitly to TCC.EXE) produces: áà-äâ-ȧā-ạα (same as above).
• TCC 36.50.71 running over TCMD 36.50.71 (explicitly run from Tabs ⇒ Run... ⇒ Start in a New Tab, App TCC) produces: aa-aa-ȧā-ạα (same as TCC by itself).
• TCC 36.50.71 running over TCMD 36.50.71 (explicitly run from Tabs ⇒ Run... ⇒ Start in a New Tab, App Custom pointing explicitly to TCC.EXE) produces: aa-aa-ȧā-ạα (same as TCC by itself).

Can I get the installer for 36.0, so I can install it on another computer? (I just reinstalled Windows from scratch on a laptop I has handed over for repairs and recovery)

 

[rconn]

I have uploaded beta builds of TCMD & TCC 36.52.84 to:

https://jpsoft.com/downloads/beta/tcmd.exe

https://jpsoft.com/downloads/beta/tcc.exe

These builds should fix the issues with the dead keys & AltGr keys that you have reported. Since I'm pretty sure that there are likely to be more special keys that you haven't told me about, please try these builds and let me know what's still missing or not working.

 

[Marty]

All dead keys of a (Germany) German keyboard are working now as expected. Thank you very much for fixing these. Unfortunately, I can't comment on different keyboard layouts.

 

[CityguyUSA]

Just wondering if any of these keyboards are Bluetooth connected?

 

[Heiko]

Just wondering if any of these keyboards are Bluetooth connected?

My Logitech wireless keyboard is connected using their Unify adapter. I had this problem and with 36.52.84 it is gone!

 

[Marty]

Just wondering if any of these keyboards are Bluetooth connected?

I tested it with both a wired and Bluetooth keyboard. The issue occurred independently of the connection variant and the latest beta fixes it (at least for the German keyboard layout).

 

[mfarah]

Just wondering if any of these keyboards are Bluetooth connected?

All my keyboards are wired; no Bluetooth whatsoever. This doesn't (ok, shouldn't) have anything to do with it... although I can imagine keyboards with poor firmware having problems with the AltGr layers, but in that case, all applications would be affected, not just TCMD/TCC from 36.50 onwards.


(meanwhile, I'm testing out thoroughly build .84; no issues so far)

 

[richieadler]

I can report the same problem for the Spanish-Spain keyboard keyboard. The dead keys are, at the right of the P: [ ^ / ` ], and at the right of the Ñ: [ ¨ / ´ ] (the pairs mean Shifted / Unshifted)

For instance, pressing ´ is a dead key, after that, pressing any of "aeiouAEIOU" should produce "áéíóúÁÉÍÓÚ". It doesn't.
Same for ^ then [aeiou] should produce [âêîôû]
Same for ` then [aeiou] should produce [àèìòù]
Same for ¨ then [aeiouy] should produce [äëïöüÿ]

 

[rconn]

I can report the same problem for the Spanish-Spain keyboard keyboard. The dead keys are, at the right of the P: [ ^ / ` ], and at the right of the Ñ: [ ¨ / ´ ] (the pairs mean Shifted / Unshifted)

For instance, pressing ´ is a dead key, after that, pressing any of "aeiouAEIOU" should produce "áéíóúÁÉÍÓÚ". It doesn't.
Same for ^ then [aeiou] should produce [âêîôû]
Same for ` then [aeiou] should produce [àèìòù]
Same for ¨ then [aeiouy] should produce [äëïöüÿ]

Is that with 36.52.84, or with an earlier build?

 

[mfarah]

I can report the same problem for the Spanish-Spain keyboard keyboard. The dead keys are, at the right of the P: [ ^ / ` ], and at the right of the Ñ: [ ¨ / ´ ] (the pairs mean Shifted / Unshifted)

For instance, pressing ´ is a dead key, after that, pressing any of "aeiouAEIOU" should produce "áéíóúÁÉÍÓÚ". It doesn't.
Same for ^ then [aeiou] should produce [âêîôû]
Same for ` then [aeiou] should produce [àèìòù]
Same for ¨ then [aeiouy] should produce [äëïöüÿ]

Did you test the AltGr-4 dead key (ã, ñ, õ) as well?

 

[Alpengreis]

Good news, tested with beta build 84 and also with swiss german keyboard it seems all good now!

Thank you very much!

 

[rconn]

I can report the same problem for the Spanish-Spain keyboard keyboard. The dead keys are, at the right of the P: [ ^ / ` ], and at the right of the Ñ: [ ¨ / ´ ] (the pairs mean Shifted / Unshifted)

For instance, pressing ´ is a dead key, after that, pressing any of "aeiouAEIOU" should produce "áéíóúÁÉÍÓÚ". It doesn't.

Works here with 36.52.84.

Same for ^ then [aeiou] should produce [âêîôû]

Works here with 36.52.84.

Same for ` then [aeiou] should produce [àèìòù]

Works here with 36.52.84.

Same for ¨ then [aeiouy] should produce [äëïöüÿ]

Works here with 36.52.84.

Please confirm that you´re using build 36.52.84 or later, and tell us exactly what you're seeing (not just "it doesn't").

 

[Alpengreis]

And bad news ...

It does work overall now, EXCEPT in TCMD ConPTY tab! Ther I have no success!

Tested with .85

PS: Swiss German pysical Keyboard, and Win 11 with SG (Swiss German) layout (also called as de_CH or DEU SG) ...

 

[rconn]

And bad news ...

It does work overall now, EXCEPT in TCMD ConPTY tab! Ther I have no success!

Tested with .85

PS: Swiss German pysical Keyboard, and Win 11 with SG (Swiss German) layout (also called as de_CH or DEU SG) ...

What doesn't work? Anything? Some things? One thing?

Everything is working here in a ConPTY tab window with a German keyboard and 36.52.86.

 

[Alpengreis]

Anything doesnt work related to dead keys with my swiss german keyboard in a TCMD ConPTY tab.

Note that a swiss german keyboard ist NOT the same as a german keyboard.

 

[Alpengreis]

Ahh, updated to .86 and there it works, Rex!

Thank you!