Espanso: Wrong replacement after session startup on non-US keyboard

[GustaveCoste]

I just installed espanso 0.7.0 on Ubuntu 20.04 with a french _azerty_ keyboard.

I have set some custom replacements such as :

- trigger: ":pd"
  replace: "import pandas as pd"

After editing the configuration file with espanso edit, the replacement works fine. However, when I close and restart my session the replacement becomes: i,port pqndqs qs pd instead of import pandas as pd, as if it has been typed on a _qwerty_ keyboard.

Restarting espanso with espanso restart fixes the problem.

[federico-terzi]

Hey,
Thanks for reporting this issue! Indeed, on Linux the situation is a bit more complex with non-US keyboard layouts. You generally have 2 options:

1. You can disable fast injection by adding fast_inject: false in your configuration. This might slow down the injection, especially on Ubuntu Gnome systems.
2. You can use the clipboard backend, by adding backend: Clipboard in your configuration. The only downside is that after an expansion, you might lose your previous clipboard content if it was an image.

That said, I will investigate on possible ways to mitigate this problem.

However, when I close and restart my session the replacement becomes:

I have a few questions for you:

1. Do you use multiple keyboard layouts? (switching between the two)
2. When you restart the session, the keyboard layout is still french?

Cheers :)

[GustaveCoste]

Thank you for the workarounds.

Do you use multiple keyboard layouts? (switching between the two)

No, I only use my french _azerty_ keyboard with a single layout.

When you restart the session, the keyboard layout is still french?

Yes

[federico-terzi]

All right, thank you, I'll make sure to investigate

[luca-ing]

Just to confirm, this issue also hits me. I also confirm that the workaround (restarting Espanso) does in fact work around :-)

System:
Manjaro Linux, i3 window manager, _qwertz_ (German) keyboard layout.

[federico-terzi]

@luca-ing Thank you. Could you please try setting fast_inject: false in your default.yml file and see if the problem still occurs? That would be a great help :)

[jcassee]

For me, setting fast_inject: false does not solve the problem. (Restarting Espanso does.)

[federico-terzi]

@jcassee Thank you for the help! I'll investigate :)

[federico-terzi]

Guys I might have found the problem (but I'm not sure as I didn't have the chance to get my hands on a Linux machine at the moment). If any of you could test this out, that would be a great help:

So it turns out that there is a Systemd service to setup the keyboard called keyboard-setup.service. Maybe if we force espanso to start after that service the keyboard will work as expected. Could you please try to edit your ~/.config/systemd/user/espanso.service, adding the After clause as follows:

[Unit]
Description=espanso daemon
After=keyboard-setup.service

[Service]
ExecStart={{{espanso_path}}} daemon
Restart=on-failure
RestartSec=3

[Install]
WantedBy=default.target

Then you can restart your PC and check. If this fixes the problem, I'll make sure to include a patch in the next release :)

[jcassee]

Alas, using After=keyboard-setup.service in the systemd unit file did not fix the problem on my system. (Ubuntu 20.04, Dvorak keyboard layout)

[GustaveCoste]

I edited ~/.config/systemd/user/espanso.service as you suggest but it didn't solve the problem.
However, using backend: Clipboard works.

[federico-terzi]

@jcassee @GustaveCoste Thank you both! That's unfortunate, I'll keep digging then

[federico-terzi]

However, using backend: Clipboard works.

@GustaveCoste That's because even if your keyboard layout is misplaced (interpreting a french layout as a US one), the location of the CTRL+V keys is the same, therefore the paste operation works anyway :)

Not a solution, but it could be a workaround in the meanwhile :)

[jcassee]

On my Ubuntu installation, it appears the user keyboard setup target is called "gsd-keyboard". On a whim I tried After=gsd-keyboard.target, and that fixed the problem.

(I now see a notification "espanso is running" after the desktop appears, which I am not really interested in, but I'm very happy I don't have to restart Espanso manually after every login.)

[federico-terzi]

@jcassee Thank you for the investigation! I'm wondering whether we can bundle this patch in espanso itself. Are you running Gnome on Ubuntu?

[jcassee]

Yes, I'm running Gnome on Ubuntu 20.04.

[federico-terzi]

@jcassee Great, thanks. I'll make sure to add this patch automatically if Gnome is detected

I'm wondering how other desktop environments handle this process. There will be an equivalent service I suppose... @Scrumplex do you have any idea of what Systemd service Arch-based systems are using to configure the keyboard?

[luca-ing]

Just as a data point, I'm using i3 on Manjaro, and observe the same problem; so it's not limited to Gnome.

Looking at the list of services, the only one that seemingly makes sense to use as a trigger for loading Espanso appears to be session-1.scope, but I'm not sure that's generic enough.

I could restart the espanso sevice during i3 start, but while that probably fixes the issue for me, it's certainly not a generic solution.

Hm.

[MuhammedZakir]

The easiest way is to add a delay before service start.

1. ExecStartPre option - affects service restart
2. .timer file

[federico-terzi]

@luca-ing Thank you for the insight. Indeed it's not easy to determine a general solution on Linux due to the great fragmentation...

@MuhammedZakir Thanks for the info, that might be a workaround, even though I'd prefer a cleaner solution if possible

I'll investigate further. Please feel free to comment if you discover other useful information

[shw00p]

I ran into the same issue using norman keyboard layout (US). I found the best solution was as @MuhammedZakir recommended - adding the following line to ~/.config/systemd/user/espanso.service.

[Service]
ExecStartPre=/bin/sleep 20 

The backend: Clipboard solution worked as well, but the string replacement wasn't as smooth so I tried this as well and found it worked much better :)

None of the After=... solutions worked for me and I tried quite a few different systemd targets.

Thanks for building such a helpful tool with great documentation!

[federico-terzi]

@shw00p Thanks for the insights! As soon as I figure out a decent way to handle this automatically, I'll add a fix :)