A trigger ":em" re-triggers when disable_x11_fast_inject is true -- possibly by prepending or leaving a colon about espanso HOT 6 OPEN

I'd very much appreciate knowing whether anyone else succeeds or fails in reproducing this. I wonder if I missed some relevant system state in the report, as being reproduced by this very specific trigger is pretty strange.

from espanso.

Possibly related:

• #1623
• #1692

from espanso.

Here's another example of the infinite loop (if you try it, set a timer to kill espanso before you use the trigger):

  - trigger: ":-"
    replace: "--- $|$ ---"

from espanso.

Now that I look at the nested matches doc, it seems the first case is actually intentional, though I don't understand why. Shouldn't a nested match be specified with its full trigger, rather than its trigger but-without-a-potential-leading-colon?

The second case still must be unintentional, and may still be related to the implementation enabling the first.

from espanso.

Well for my own usage, I think this would be resolved if I could disable nested matches altogether, and have opened a request for that at #1733.

I don't understand why something matches :something when it comes to nested matches, but I'd be very happy to just ensure recursive replacement is never a possibility in my setup.

from espanso.

I don't think what you're seeing is intentional.

I've tried all your examples (Linux Mint 21.2 x86_6, Xfce 4.18) and can't reproduce your outputs. I can only produce the nested match effect with the configuration specified in the docs, where the nested match is triggered by:

    vars:
        params:
          trigger: :something

as shown in the example, so I don't get any accidental triggering.

I think what you're seeing is a bug.

from espanso.