kimat
commented
1 year ago Expansion works fine on my setup using espanso defaults:
$ wezterm --version
wezterm 20230408-112425-69ae8472
$ espanso --version
espanso 2.1.8Closed dodalovicgran closed 9 months ago
kimat
commented
1 year ago Expansion works fine on my setup using espanso defaults:
$ wezterm --version
wezterm 20230408-112425-69ae8472
$ espanso --version
espanso 2.1.8
wez
commented
1 year ago Please run through https://wezfurlong.org/wezterm/troubleshooting.html#debugging-keyboard-related-issues and provide more information.
dodalovicgran
commented
1 year ago Espanso seem to lowercase what actually needs to be expanded. My use-case, i have a root password in espanso
- trigger: ":rp"
replace: "aAbB"when I do this in wezterm, it gets expanded as aabb. In other terminals it works fine. I'm not sure if this is an issue of wezterm or espanso, tbh
➜ ~ espanso --version
espanso 2.1.8
➜ ~ wezterm --version
zsh: command not found: weztermwezterm installed as flatpack @ Pop!_OS 22.04 LTS
kimat
commented
1 year ago I could reproduce this issue, espanso matches do indeed get expanded in lowercase only, when expanding them in wezterm.
wez
commented
1 year ago I'm not going to install espanso; I simply don't have the time. I would love to see some actual information from wezterm here; there's no version information and no debug output. Could someone please add that here?
dodalovicgran
commented
1 year ago Nothing got printed out that I could understand. Bunch of DEBUG statements, no ERROR or whatsoever. I understand that you're busy. I'll switch back to alacritty. Feel free to close, if you feel like.
Thanks
wez
commented
1 year ago The debug is for me to understand, rather than you. Without it, I have nothing to act upon. If you don't wish to bother, then let's close this. Otherwise, please add that information and re-open it.
dodalovicgran
commented
1 year ago 
stravid
commented
1 year ago I'm using Windows and have the same problem and narrowed down the circumstances. It only happens if I open WezTerm as administrator. But I'm uncertain if this is a problem with WezTerm. The same problem occurs if I'm using cmd.exe. Espanso correctly works in a normal cmd.exe instance. Once I open it as administrator it also stops working.
wezterm --version
wezterm 20230408-112425-69ae8472
espansod --version
espanso 2.1.8Here's another debug log: wezterm.log
This log was generated by doing:
WEZTERM_LOG=debug wezterm 1>wezterm.log 2>&1:espanso in wezterm (which is configured to expand to Hi there! in espanso):espanso string in wezterm by hi there! instead of Hi there!$ wezterm --version
wezterm 20230408-112425-69ae8472
$ espanso --version
espanso 2.1.8espanso's config is the default one with the following match:
matches:
# Simple text replacement
- trigger: ":espanso"
replace: "Hi there!"
AndydeCleyre
commented
1 year ago 3. wezterm was closed after espanso replaced the `:espanso` string in wezterm by `hi there!` instead of `Hi there!`
Can you confirm that it's producing hi there!? Just because in my case it would be hi there1.
kimat
commented
1 year ago Can you confirm that it's producing
hi there!? Just because in my case it would behi there1.
@AndydeCleyre yes:
AndydeCleyre
commented
1 year ago $ wezterm -e zsh -f &>wez.log # in wezterm, type: :wez3840use_ime set to false.OK, after more fiddling with espanso options, I found that it all seems to work ok if I set disable_x11_fast_inject: true in espanso's config. The docs say for that option:
NOTE: This is only relevant on Linux under X11 environments. Switch to a slower (but sometimes more supported) way of injecting key events based on XTestFakeKeyEvent instead of XSendEvent. From my experiements, disabling fast inject becomes particularly slow when using the Gnome desktop environment.
dodalovicgran
commented
1 year ago disable_x11_fast_inject: true
didn't help in my case :disappointed:
AndydeCleyre
commented
1 year ago Even with my config, I have now found issues with inputting Ŧ and Ł into wezterm (only) with espanso.
$ tail -n 4 ~/.config/espanso/match/chars.yml - trigger: ":ten"
replace: Ŧ
- trigger: ":lem"
replace: Ł:ten:
:lem:
While pasting the characters manually via ctrl+v does work.
wez
commented
1 year ago @AndydeCleyre try starting wezterm like this:
$ WEZTERM_LOG=window::os::x11::keyboard=trace,info wezterm --config debug_key_events=truethat will log more information about the X11 events being received; then retry your :ten scenario and share the output
AndydeCleyre
commented
1 year ago Thanks!
wez
commented
1 year ago Do you know why it is sending CTRL-v at the end? Is it trying to paste? Can you tell espanso to use ctrl-shift-v for pasting?
Alternatively, you could try adding a keybinding:
config.keys = {
{ key = 'v', mods = 'CTRL', action = wezterm.action.PasteFrom 'Clipboard' },
}but note that some terminal programs want CTRL-v to do things, and that key assignment would prevent them from seeing it.
AndydeCleyre
commented
1 year ago Do you know why it is sending CTRL-v at the end? Is it trying to paste?
Yeah, when it uses the Clipboard backend (and often when it uses the default Auto backend it's effectively Clipboard) that's how it's doing the snippet expansion, with an automated paste.
Can you tell espanso to use ctrl-shift-v for pasting?
Ahh lemme see . . . yes!
paste_shortcutCustomize the keyboard shortcut used to paste an expansion. This should follow this format: CTRL+SHIFT+V
Trying it . . . yes it works! Thanks very much.
wez
commented
1 year ago So does that mean that the other folks having problems here in this issue probably also need to change that same config? Could you share a summary of what espanso config working for you in wezterm @AndydeCleyre ?
AndydeCleyre
commented
1 year ago So here's my working (AFAICT) espanso config:
disable_x11_fast_inject: true
paste_shortcut: "CTRL+SHIFT+V"I'll note that the paste_shortcut option can be set on a per-app basis.
dodalovicgran
commented
1 year ago Unfortunately, it didn't help.
bew
commented
1 year ago Hello @wez :wave:
Trying out Espanso now, and trying to get it to work under wezterm..
My wezterm config uses Ctrl-shift-v to paste, it works when I do it manually, and I get this key event log (I close the window before up events): wz-standalone-ctrl-shift-v.log
With Espanso I made a trigger !wez, which for some reason ONLY sends v to the pane instead of triggering PasteFrom action :thinking: :
wz-espanso-trigger-then-ctrl-shift-v.log (with comments)
Wezterm version: 20230712-072601-f4abf8fd
Install method: Flatpak (works well for Signal also installed via Flatpak, so shouldn't be a factor?)
Espanso version: v2.1.8
Install method: Nix
OS: Linux X11
File ~/.config/espanso/config/wezterm.yml:
filter_class: org.wezfurlong.wezterm
backend: Clipboard
paste_shortcut: "CTRL+SHIFT+V"
extra_includes:
- "../match/_wezterm.yml"File ~/.config/espanso/match/_wezterm.yml:
matches:
- trigger: "!wez"
replace: Yes!123Run Espanso in foreground using: espanso daemon
Run wezterm: WEZTERM_LOG=window::os::x11::keyboard=trace,info wezterm -n --config debug_key_events=true
Type !wez
wez
commented
1 year ago @bew: Hi! The v key press event has no modifiers set; neither Shift nor Control.
Others reported that they also needed disable_x11_fast_inject: true to be set in espanso config; is that missing from your config?
bew
commented
1 year ago And that works with disable_x11_fast_inject: true, forgot to test it again after some change of espanso version :grimacing:
Good catch on the missing modifiers, but that's weird isn't it? Who/What is supposed to tell you which modifiers are pressed?
ctrl, shift) to deduce which modifiers are active when a non-modifier key (like v) is pressed?wez
commented
1 year ago wezterm uses the standard libxkbcommon-x11.so.0 under the covers; X events are fed into an internal state machine in that library, which produces decoded events and modifiers that respect both the keyboard layout and modifier mapping that may be configured by the user. wezterm doesn't have direct knowledge of that mapping; it leaves all of that to xkbdcommon and consumes its results.
espanso is simulating input for wezterm. It's espanso's responsibility to send appropriate input events in order for xkbdcommon to produce the normal output.
I don't know exactly what effect disable_x11_fast_inject: false has, but from the name I'd assume that it is taking some shortcuts that aren't guaranteed to work with every application.
bew
commented
1 year ago I think I've found something:
Looking at the xcb event with this diff:
diff --git a/window/src/os/x11/keyboard.rs b/window/src/os/x11/keyboard.rs
index 11c37b5dd..cce83ac35 100644
--- a/window/src/os/x11/keyboard.rs
+++ b/window/src/os/x11/keyboard.rs
@@ -174,6 +174,7 @@ impl KeyboardWithFallback {
xcb_ev: &xcb::x::KeyPressEvent,
events: &mut WindowEventSender,
) {
+ dbg!(xcb_ev);
let xcode = xkb::Keycode::from(xcb_ev.detail());
self.process_key_event_impl(xcode, true, events, false);
}The Ctrl-Shift-v sent by Espanso does have the modifers:
(albeit shifted: ctrl has ctrl modifier even though ctrl wasn't pressed yet, I made a PR to fix that)
wz-debug-xcb-event.log (commented)
I'm digging
bew
commented
1 year ago Ok so the main issue is that key press events sent by Espanso through XSendEvent are rather direct, and doesn't seem to pass through XKB' state handling, and thus don't send XkbStateNotify events that would tell Wezterm to update its knowledge of the modifiers.
XSendEvent directly) and use the event's modifiers instead of the Xkb state known modifiersXkbLockModifiers xlib function (?)XkbStateNotify event sent to Wezterm via XSendEventWhat do you think would be the best option to solve this?
dodalovicgran
commented
1 year ago The one that works. I would assume Wezterm.
Pistahh
commented
9 months ago Hi, I have a very similar issue, triggered on a QMK keyboard. In my case it looked related to ibus and as I can "fix" it by 1. not using ibus 2. using ibus but killing the ibus daemon, I assumed it is an ibus issue so filed a bug report for ibus: https://github.com/ibus/ibus/issues/2600
Do you think it could be a wezterm issue? Happy to re-file the issue here if needed.
My issue also happens on wezterm-nightly 20240121-180215-76028ca1
wez
commented
9 months ago I don't think it is a wezterm bug per-se, but rather a weird interaction between ibus, the X server and xkbdcommon that wezterm is sensitive to
wez
commented
9 months ago This should be resolved now in main.
It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.
Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.
If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.
If you are eager and can build from source then you may be able to try this out more quickly.
AndydeCleyre
commented
9 months ago Excellent! As far as I can tell, I no longer need to set disable_x11_fast_inject: true in the Espanso config, which in turn helps me avoid some Espanso bugs. Thank you!
Pistahh
commented
9 months ago This should be resolved now in
main.
Can confirm, I don't see the issue anymore with the latest nightly.
HaleTom
commented
9 months ago For a temporary work-around for those not yet using the latest main commit:
~/.config/espanso/config/wezterm-TEMP.yml:
filter_class: org.wezfurlong.wezterm
disable_x11_fast_inject: truenote that these changes have also been in the most recent couple of releases
github-actions[bot]
commented
8 months ago I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
What Operating System(s) are you seeing this problem on?
Linux X11
Which Wayland compositor or X11 Window manager(s) are you using?
No response
WezTerm version
➜ ~ wezterm -V zsh: command not found: wezterm
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
No, and I'll explain why below
Describe the bug
When using https://espanso.org/ nothing happens, the expansions don't take place. On alacritty, for instance, it works fine.
To Reproduce
When using https://espanso.org/ nothing happens, the expansions don't take place. On alacrity, for instance, it works fine.
Configuration
not important, didn't work even with no config file initially
Expected Behavior
No response
Logs
No response
Anything else?
No response