Unable to expand closing parentheses ")"

[Romain Guerin]

Describe the bug

I want to replace a trigger with a value containing both parentheses (opening and closing), but the closing parentheses is removed from the final value.

To Reproduce
Steps to reproduce the behavior:

1. create a config file with following value:

matches:
  - trigger: "::example1"
    replace: "hello (from) parentheses"

  - trigger: "::example2"
    replace: "_ex1()__ _ex2{{echosymbol}}__ _ex3{{shellsymbol}}__ _end"
    vars:
      - name: echosymbol
        type: echo
        params:
          echo: "one(two)three"
      - name: shellsymbol
        type: shell
        params:
          cmd: echo "xx(yy)zz"

2. save config file

3. trigger both triggers ::example1 and ::example2

Expected behavior

• ::example1 should be replaced with value hello (from) parentheses
• ::example2 should be replaced with value _ex1()__ _ex2one(two)three__ _ex3xx(yy)zz__ _end

Actual behavior

• ::example1 is replaced with value hello (from parentheses
• ::example2 is replaced with value _ex1(__ _ex2one(twothree__ _ex3xx(yyzz__ _end

Logs

No logs were printed when I triggered both triggers. Last log lines are relative to previous configuration reload:

10:40:36 [daemon(5651)] [INFO] configuration change detected, restarting worker process...
10:40:36 [worker(2476516)] [INFO] engine eventloop has terminated, propagating exit event...
10:40:36 [worker(2476516)] [INFO] waiting for engine exit mode...
10:40:36 [worker(2476516)] [INFO] exiting worker process...
10:40:36 [daemon(5651)] [INFO] spawning the worker process...
10:40:36 [worker(2477604)] [INFO] reading configs from: "/home/me/.config/espanso"
10:40:36 [worker(2477604)] [INFO] reading packages from: "/home/me/.config/espanso/match/packages"
10:40:36 [worker(2477604)] [INFO] using runtime dir: "/home/me/.cache/espanso"
10:40:36 [worker(2477604)] [INFO] system info: Ubuntu v20.04 - kernel: 5.15.0-101-generic
10:40:36 [worker(2477604)] [INFO] binded to IPC unix socket: /home/me/.cache/espanso/espansoworkerv2.sock
10:40:36 [worker(2477604)] [INFO] using X11AppInfoProvider
10:40:36 [worker(2477604)] [INFO] using X11Source
10:40:36 [worker(2477604)] [INFO] monitoring the status of the daemon process
10:40:36 [worker(2477604)] [INFO] using X11ProxyInjector
10:40:37 [worker(2477604)] [INFO] using X11Clipboard

Setup information

• OS: Ubuntu 20.04
• Version: espanso 2.2.1

[Stephen Meech]

Your code is correct and works fine here (Linux Mint Xfce).

It may be worth trying changing the injection mechanism. I generally find clipboard works best in my editors and inject/keys/auto in a terminal.

[Romain Guerin]

Hello, thanks for your reply :)

I try both force_mode: keys and force_mode: clipboard and here are my results:

1. clipboard mode:

   1. inside VS Code editor: hello (from) parentheses and _ex1()__ _ex2one(two)three__ _ex3xx(yy)zz__ _end (both OK)
   2. inside VS Code integrated terminal: hello (from) parentheses and _ex1()__ _ex2one(two)three__ _ex3xx(yy)zz__ _end (both OK)

2. keys mode:

   1. inside VS Code editor: hello (from parentheses) and _ex1(__ _ex2one(twothree__ _ex3xx(yyzz__ _end))) => it's not OK, but it's because of VS Code adding the closing sign when the opening sign is typed, so the closing ) is pushed at the end of the string. I guess nothing can be done in espanso against this behavior
   2. inside VS Code integrated terminal: hello (from parentheses and _ex1(__ _ex2one(twothree__ _ex3xx(yyzz__ _end => it's not OK either, the closing parentheses is totally absent in both cases

3. using no force_mode at all, I get the same behavior as keys mode (so this is default in my cases)

So, clipboard mode works for my use case, but still I think there's a bug with force_mode: keys, because espanso never write the ")" sign itself (as we can see with the VS Code terminal test). For the test inside VS Code editor, it really looks like the ")" comes from VS Code itself, and not from espanso.

Also, since punctations signs like ()[]{}<> may be completed by the editor you type them in (VS Code, Markdown editor or whatever), maybe espanso could detect if the value to insert contains a such sign, and when mode Auto is used, espanso could choose clipboard backend instead of keys backend for these text.

Finally, I find a bit confusing to have a global parameter backend with allowed values clipboard / inject / auto, but a force_mode custom parameter, with different allowed value clipboard / keys / auto. The two looks similar and used for the same thing, but a a different level of configuration:

• why not rename to backend (global) and force_backend (local/match conf) ? Or mode (global) and force_mode (local) ?
• why using inject on global conf, but keys on local conf ? If it's the same inherent behavior, the same value should be used. If behavior are different, then I don't find in the documentation what are the differences.

[Stephen Meech]

I agree - it is very unhelpful that a setting in default.yml etc. is backend: inject, and in a match file trigger, force_mode: keys! I'm not aware of any reason for the difference in the words, and I added that section of the docs recently

Unless you've changed it, your default.yml backend: setting will be auto. That causes Espanso to use the inject/keys method for small expansions, and the clipboard method for longer ones which exceed the clipboard_threshold setting (default 100 characters).

If I've understood the above correctly, it appears you would benefit from an app-specific configuration for VS Code that specifies backend: clipboard. Then you wouldn't need any force_mode: parameter in your triggers.

Depending on your balance of programs, you may even find it useful to set clipboard globally, in default.yml and use app-specific configs for the exceptions. For example, I just use them for xfce4_terminal (auto) and LO Calc (inject with inject_delay: 100).