Hotstrings breaks chained deadkey

[Geobomatic]

Hi,

Using an alternative layout called Ergo-L (ergol.org), I’m facing an issue when using hotstrings.
When AHK is running with hotstrings, the deadkey at qwerty position "O" gives me

Code: Select all

"’

instead of acting like a deadkey.

When running AHK without any hotstrings, the layout works as expected.

What am I missing?

[Geobomatic]

Worse, if I set Ergo-L as the default input, the very same script doesn’t run anymore, without any error. Trying to compile it only gives a popup "Error: The script contains syntax errors."

But if I switch the keyboard layout to something else (bépo, another alternative french layout), the script can be run again and can be compiled as well.

It is very very odd

[lexikos]

When Ahk2Exe gives you the message "The script contains syntax errors.", it also shows the actual syntax error. So what is it?

I don't think it's possible that a syntax error could be detected or not depending on which keyboard layout is active.

The hotstring recognizer in current versions is designed to support dead keys. There have historically been issues, which were fixed and tested with several of the standard Windows layouts including dead keys. Does the key ordinarily behave the same as a typical dead key from one of the standard layouts, or has it some other special behaviour?

It is generally good form to post example code that reproduces your issue when asking for help (or reporting a bug). Does the problem occur regardless of what the hotstrings are?

[Geobomatic]

Thanks for your answer. The thing is that I don’t have anything else than this message. No details whatsoever on what the error is. (I’m a dev so I’m used to deal with error message on script and source file)

I’ve worked on my script in order to isolate the issues and end with this:
- any hotstrings break the dead key on position "O" with the Ergo-L layout
- the script doesn’t run/compile if there’s a key rebind that contains an accent, like "è::r" if Ergo-L is active. If I change the layout, the script runs.

[Geobomatic]

Sorry I forgot to answer to the special behaviour for the dead key on qwerty "O": it is a bit special because if you press it a second time, it trigger another dead key (chained dead key). On ergol.org you can test it without installing to see what I mean. Note that the emulation doesn’t have issue with AHK though, only the MSKLC driver which is not yet distributed as we are working out this issue. But I can provide it if you want it

[Geobomatic]

The bug with script that doens’t run with "è::r" rebind is reprocuced using qwerty layout

[Geobomatic]

I think I understand the issue with "è::r": in Ergo-L or Qwerty, "è" is not directly accessible, so no Scan code is attached to it. In Bépo layout, "è" is directly accessible so a scan code is attached to it.
I’ve workaround this issue by using scan code instead of character.

The hotstrings breaking the dead key is still an ongoing issue though

[lexikos]

When è does not exist on the current keyboard layout, the issue with è::r occurs because a remapping (unlike the single hotkey è::Send r) causes the program to silently exit with exit code 2 instead of displaying a warning. This is a bug. v1 would display two warnings - one for *è and one for *è up - because every remapping is implemented as a pair of hotkeys such as this.

Note that AutoHotkey is not reporting a syntax error; Ahk2Exe is interpreting the exit code (2) to mean that there is a syntax error. This is why there is no additional detail.

Of couse, if you want the remapping to actually work regardless of the keyboard layout, you still need to use the scancode.

The current level of dead key support was difficult to achieve, because of the unfortunate way that some Windows APIs used to query information also affect the current keyboard state (especially with respect to dead keys). If there is an official Windows keyboard layout which exhibits this issue, I might be more inclined to debug it. Supporting third-party layouts which use unconventional features is not a priority for me. In any case, I have moved the topic to Bug Reports.

[Geobomatic]

Thank you for your answer

I’m willing to tackle this issue as the layout is from French enthusiasts on keyboard ergonomics so I understand it is not a priority for you.

I’ve cloned the repo and reading the code. If you have any pointers on where you think this issue happens, let me know

Also, this issue affect other french third party layout called bépo and optimot in their "full" version which also exhibits chained dead key.

[Geobomatic]

Ok, I’ve explored the code a bit and I have some questions.

I put breakpoints on all calls to ToUnicodeOrAsciiEx().

I tested a dead key that works perfectly in the bépo layout and I hit the call in hook.cpp, l. 2334, just after "if (transcribe_key)". What I don’t understand is that char_count is 1 after the call, but the key is supposed to be a dead key so -1 was the value I expected.

On the problematic dead key in ErgoL, when I press it, I hit the same call first, but I got char_count to -1, and then I hit the call at l. 2446 which is about dead key workaround.

Something’s wrong with the dead keys in Win API but not getting -1 when I expect it makes it really weird to debug

[Geobomatic]

After more investigation, it looks like we have an extra press of dead keys but I can’t see where.

With non chained dead key case, we hit only one ToUnicodeOrAsciiEx() call but it acts likes it’s the 2nd time we press the key (char_count is 1) but the behaviour is correct (and I don’t understand how it can work)
With chained dead key case, we hit 2 ToUnicodeOrAsciiEx(), and we get -1 in the first call, and 2 in the second call. The behaviour is that I get with one press what I’m supposed to get after 3 presses.

I’m very confused that non chained dead key works as the char_count is not correct…

[Geobomatic]

Ok, breakpoints are a bad idea as it change the active window leading to these readings. Using OutputDebugString gives expected readings so I can think on a solution now

[Geobomatic]

I have the beginning of a solution! Need to test it furthermore, but I have a code that manage the case that was broken

[Geobomatic]

PR available https://github.com/AutoHotkey/AutoHotkey/pull/331