Espanso: Triggers that share common prefix cannot co-exist

[jrop]

I have two triggers that I want to set up: I want each to expand to a different email:

  - trigger: ":email"
    replace: "[email protected]"
  - trigger: ":email2"
    replace: "[email protected]"

However, when I type :email, espanso does not wait to see if there is a 2 coming: it eagerly expands :email to [email protected].

I propose the following solution:

• Introduce a new "timeout" config value (a decent default may be 500ms)
• Change analysis of triggers in a file to build up a "match" state machine.
• At any terminal node in the state machine that has the potential to eat more characters, start the stopwatch (configurable): if the timer finished before there is more input, then insert the match corresponding to the current node of the state machine. Otherwise, continue state transitions.

[federico-terzi]

Hey @jrop,
Thank you for the suggestion, this feature could be useful indeed.
I'll try to make a few experiments and get back to you when I got something!

Thanks for your help :)

[AryToNeX]

imho since the time-based approach inevitably makes you wait to write the rest of the phrase (and it can be frustrating to some) I would propose

• Key combination approach: pressing a certain key (combination) will make espanso "expand" the longest match it could find right before the key (combination) was pressed. I think of it as a short-term passive mode where espanso would store the phrase starting from the last typed pattern, then it would process it in RAM, it would go all the way back and then it would paste the new processed sentence.
• Spacebar approach: if two matches are the same and they don't contain spaces in them, then pressing space will make espanso do its job on the longest match it could find right before the spacebar was pressed

[jrop]

Waiting for future states only needs to happen, though, if there is a possibility of future input. One can prune out that branch of the state machine if the node you are currently on is a terminal node. This is how vim does its key bindings. Anytime a key binding is used that has no possibility of more future keys, it takes effect immediately.

[federico-terzi]

Hey guys,
Both your suggestions are equally valid. I would personally go with the first one proposed by @jrop as it is the most seamless one. That said, I'm a bit worried about the potential delays of that approach. For that reason, I would probabily disable it by default, and allow the users to enable it manually.

Also because personally, rather than having :email and :email2, I would have something like:

• :email1 and :email2
• :email and :2email

But I can understand why users would prefer the timeout approach, so I'm definitely planning to add the feature.

Cheers

[stheid]

I guess with the "word" flag enabled this is not that severe, right, as than, the trigger is only executed after a next whitespace has been hit.

[federico-terzi]

I guess with the "word" flag enabled this is not that severe, right, as than, the trigger is only executed after a next whitespace has been hit.

@stheid I agree with you. Using the word property solves many of these problems, therefore making this issue less critical.