Text expander word condition removed

[AZADAYAZ]

My test code for it to work better, Please check

[LeanBitLab]

ah i didn't checked and pushed an update, there are some fixes i done earlier create other issues, so had to revert some changes like google translate web suggestions fix, lets fix the bugs better way, will add this pr in next release

[AZADAYAZ]

I'm not sure if it works, I wish I had a computer so I could test it by making beta versions myself

[LeanBitLab]

I'm not sure if it works, I wish I had a computer so I could test it by making beta versions myself

ill check , lets do incremental changes

[LeanBitLab]

I'm not sure if it works, I wish I had a computer so I could test it by making beta versions myself

i checked it, the issues are
For a regex shortcut (e.g., key = "@@[0-9]+" where cleanKey = "[0-9]+"):
expectedSuffix is set to prefix + cleanKey
→
→ "[0-9]+" (the literal regex pattern string!).
regex.matches(expectedSuffix) tests Regex("[0-9]+").matches("[0-9]+") instead of testing whether the user's typed word (e.g., 123) matches the regex.

-n TextExpanderUtils, non-regex shortcut keys stored in the settings JSON already include the user-configured prefix if saved with one. Prepending prefix + cleanKey duplicates the prefix for shortcuts stored with prefixes (e.g., prefix ! and key !omw results in expectedSuffix = "!!omw").

-In isPrefixOfNonRegexShortcut (called on every single keypress during active typing), cleanKey is created via .substring() before evaluating if (key.startsWith(REGEX_PREFIX)). If key is a regex, cleanKey is allocated only to immediately evaluate the if condition to false and return.

i got the goal, ill try to implement it in a different way