With Kanata running, some characters do not resolve in espanso

[rpnfan]

Requirements

• I've searched platform-specific issues, issues and discussions to see if this has been reported before.

Describe the bug

I am using the latest Kanta pre-release 1.7 and the espanso 1.02 version from jtroo on Windows 11.

In general this works, but there are some triggers which do not work when Kanata is running.

P.S.: Too bad the standard espanso does not play well with Kanata. :-) Would be great when that can be fixed -- or alternatively Kanata would allow (basic) text expansions.

Relevant kanata config

This is the relevant part of the yml file

matches:

  # Simple text replacement
  - trigger: ".espanso"
    replace: "Hi there →!"

  - trigger: ".rgt"
    replace: "→"

  - trigger: "->" # trigger does not lead to resolve (regularly), when Kanata is running, while ok, when AHK script runs
    replace: "→"

  - trigger: ".>" # trigger does not lead to resolve as well
    replace: "⇒"  

  - trigger: ">>" # trigger does not lead to resolve as well
    replace: "⇒"  

  - trigger: "-<" # trigger does not lead to resolve as well
    replace: "⇒"  

  - trigger: ".tst" # trigger does not lead to resolve as well
    replace: "⇒"  

  - trigger: "@@" # trigger does not work!
    replace: "⇒"  




  - trigger: "==" # trigger does work!
    replace: "⇒"  

  - trigger: ".::" # this works !
    replace: "⇒"  

To Reproduce

1. define the matches (see above)
2. typing -> will not ouput the arrow character as expected →, but not resolve

.->does not resolve as well.

Expected behavior

All matches should resolve correctly, regardless which character is chosen. At the moment not all characters seem to work as a trigger (no <>@). I have not tested more chars, but possibly there are more which can not be used in a trigger (with Kanata running)?

Kanata version

1.7 pre-release

Debug logs

No response

Operating system

Windows 11

Additional context

No response

[jtroo]

In your locale is : typed with or without shift? If it's without shift, then I suspect the issue might be around handling of modifiers. But if : is typed with shift then that is some weirdly inconsistent behaviour.

[rpnfan]

Thanks for the reply. Sorry, I was travelling and did not had the chance to respond quicker. I use the US international locale set in Windows. But I map the : character to a shifted position on my .-key. Would that potentially point in the direction where the problem lies?

(defoverrides
  (lsft ,) (;)  ;; output ; on shifted ,-key 
  (lsft .) (lsft ;) ;; output : on shifted .-key 
)

[jtroo]

I'm guessing that might have something to do with it. IIRC on Windows Espanso uses rawinput so it might be reading the . and not the ; at all.

[rpnfan]

Thanks! Your ideas brought me on the right track and I found the cause where it goes wrong. There are at least two configurations which will break the functionality of espanso.

1. When an espanso trigger contains a character which is composed of a unicode character.
   I have

(defalias
  at (unicode @)
)

defined and use that in my layer keymap. Then the @-character in an espanso trigger will not resolve. When I define the at-character by S-2 in my layer (for US International on Windows) the espanso trigger will resolve correctly!

2. When I use defoverrides (see post above) the >-character can not be used in an espanso trigger, because unicode-definition does not work and when I try to use S-. (shifted .-key) in the layer definition that will output :, because of the devoverrides telling to do so, while instead I would only do the replacement for the shifted .-key and not for the .-character as such!

I guess from my side there is no workaround I can use now and espanso is also not to blame here? Or where would that need to be fixed?

[rpnfan]

Just an update. The problems reported where with kanata_gui. I now also tested the wintercept-version. The problems are the same there.

Are there any ideas to solve or workaround the problem 1 and 2, described in my post above?

[jtroo]

There is not any known fix to 1. because Unicode outputs are never seen by espanso's input. I don't actually know if there is any way to intercept windows Unicode output.

It's odd that 2. still reproduces with interception. Maybe espanso is interpreting "what turns into >" incorrectly somehow? But it works without Kanata right? Might be that there's some difference in the shift key events.