espanso / espanso

Cross-platform Text Expander written in Rust

Home Page:https://espanso.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Using trigger with regex conditioned replacement text

philipsdean opened this issue · comments

Description

It would be nice if the triggering text and then subsequently the text to be replaced was not always the regex itself when regex is used, but rather that the regex was a conditional check to decide what the replacement text should be.

Motivation

I'm using two trailing spaces to close any string of text that is open bracketed or open quoted. Not that the regex option doesn't work for this now, it just seems unnecessary that I always check for the regex and replace all of the characters in the regex. Realistically my trigger is really only the two trailing spaces and the only portion I want to replace is the two trailing spaces.

I'm thinking a switch/case like structure could be used where if the preceding line before a replace has a regex condition and it is true, it replaces only the trigger with the replace text. If the regex fails, it falls to the next regex case, or if no next regex case, the last replace.

- trigger: "  "
  - regex: ...
    replace: ...
  - regex: ...
    replace: ...
  replace: ...

It seems like this would be useful beyond just my use case since it enables context aware text expansion only after a trigger, rather than continuously.

Mmmm it's interesting, but I don't fully comprehend what you are looking for. How do you know which case to take with the same trigger? does the regex looks "behind the trigger" so to speak?
Can it be resolved with choice extension?

Idk if this is something similar you want to achieve (just a guess)
#1611

Yes the regex would look behind the trigger. It's a convenience over the choice extension for sure, similarly it is a convenience, and probably a performance improvement over just writing separate top level regex rules. To show further if we have...

{text here__  

or

(text here__

I'd expect __ to replace just __ with either } or ) automatically without having to choose. It would use the regex pattern to determine which bracket type was open.

So are you looking for something which does the same as:

  - regex: '(?P<string>\(.+)  '
    replace: "{{string}})"

  - regex: '(?P<string>\{.+)  '
    replace: "{{string}}}"

  - regex: '(?P<string>".+)  '
    replace: "{{string}}\""

etc. (or a single - regex: '(?P<string>[\(\{"].+) ' plus a script to determine the replacement for double-space (" ") depending on the first character found), but with neater code?

You'll run into Espanso's thirty-character limit on regex matches if your lines of text are long enough.

Yes, smeech gave a good example, and I also remember reading a package from the hub that the trigger was ( and the replace was ($|$), so it put you both parenthesis and the cursor in the middle.
I think this feature is not necessary, or it can be done multiple ways. For the time being we are going to close this issue

Autocompletion of brackets etc. is a feature of many editors anyway, and works more intelligently too.

For your interest, here is an Espanso regex trigger which generates a replacement using an inline Python script, which does most of what you want with [, (, {, <, & ".

  - regex: '(?P<delim>[\[\(\{<"])(?P<string>.+)  '
    replace: "{{output}}"
    vars:
      - name: output
        type: script
        params:
          args:
            - python
            - -c
            - |
              closing_chars = { '[': ']',
                                '{': '}',
                                '(': ')',
                                '<': '>',
                                '"': '"' }
              input_delim = '{{delim}}'
              input_string = r'{{string}}'
              closing_char = closing_chars.get(input_delim)
              print(input_delim + input_string + closing_char)

I am sure this could be done with PowerShell etc.. The use of single-quote delimeters means it'll fall over if there is one or more within the string, however.