4 replies to this topic

[zarz]

I'm running AutoHotkey v1.0.48.05 under Windows 7, 64-bit.

I have encountered a situation where a hotstring expands where I do not want it to and where I do not expect it to.

At the top of my .ahk file, where there are no directives in force, I have the following assignment:

:*:atr::alternate

This works fine. When I type atr, I get an immediate expansion to alternate with the cursor sitting right at the end of the word so that I may type s to get alternates or ly to get alternately.

However, suppose I add the following assignment:

::ly::lycanthropy

Since the ? option is not in force, you would not expect the keystrokes ly to trigger an expansion when they are typed immediately following alphanumeric text.

And indeed, if I type disgustingly followed by a space, no expansion occurs.

And if I type out alternately manually, followed by a space, no expansion occurs.

But if I type the string atr and get the expansion to alternate, and then immediately type ly followed by a space, ly unexpectedly expands and I get this:

alternatelycanthropy

instead of alternately.

I have not made any further tests, but this behavior may suggest that AutoHotkey does not recognize preceding text as alphanumeric when the text has been entered as the expansion of a hotstring.

Have I misunderstood the way the hotstring process works? Is there some option that would prevent this? Or is this a bug in AutoHotkey?

Can anyone duplicate this behavior on their own system?

If this is a bug, the easiest workaround is simply to avoid the use of trigger strings like ly that might be used as suffixes.

But can anyone suggest any other workaround?

Thanks.

[HotKeyIt]

The only workaround I found is to run these hotstrings in separate script.
You can use DynaRun() to run a script dynamically.

#Persistent
DetectHiddenWindows,On
PID:=2
PID1:=DynaRun("#NoTrayIcon`n:*:atr::alternate")
PID2:=DynaRun("#NoTrayIcon`n::ly::lycanthropy")
OnExit,ExitApp
Return
ExitApp:
Loop % PID
	WinClose,% "ahk_class AutoHotkey ahk_pid " PID%A_Index%
ExitApp

[Lexikos]

I suggest you edit your post and remove the font size tags. If you find it difficult to read smaller text, you'll need to zoom in (no-one else is using that font size). Others may find it more difficult to read the large text. My initial reaction was disgust, which was almost enough for me to ignore your thread entirely.


Anyway, auto-replace hotstrings always cause the hotstring buffer to be reset:

[color=green]// Since the buffer no longer reflects what is actually on screen to the left
// of the caret position (since a replacement is about to be done), reset the
// buffer, except for any end-char (since that might legitimately form part
// of another hot string adjacent to the one just typed).  The end-char
// sent by DoReplace() won't be captured (since it's "ignored input", which
// is why it's put into the buffer manually here)[/color]

If backspacing is enabled for a non-auto-replace hotstring, the hotstring trigger text is removed from the hotstring buffer (and therefore excluded from further consideration) when the hotstring is triggered:

[color=green]// It's *not* a replacement, but we're doing backspaces, so adjust buf for backspaces
// and the fact that the final char of the HS (if no end char) or the end char
// (if end char required) will have been suppressed and never made it to the
// active window.  A simpler way to understand is to realize that the buffer now
// contains (for recognition purposes, in its right side) the hotstring and its
// end char (if applicable), so remove both[/color]

Another workaround is to use a non-auto-replace hotstring and do the backspacing yourself:

:B0*:atr::
    SendInput {BS 3}alternate
return

... this behavior may suggest that AutoHotkey does not recognize preceding text as alphanumeric when the text has been entered as the expansion of a hotstring.

AutoHotkey does not intentionally recognize any text entered artificially as part of a hotstring trigger. That includes the replacement text of an auto-replace hotstring.

[zarz]

I suggest you edit your post and remove the font size tags. If you find it difficult to read smaller text, you'll need to zoom in (no-one else is using that font size). Others may find it more difficult to read the large text. My initial reaction was disgust, which was almost enough for me to ignore your thread entirely.

Thank you, Lexikos, for your detailed reply. I am particularly impressed that you managed to overcome your initial reaction of font-induced disgust sufficiently to take the time to help me out with your expert explanation of the behavior of the program. I have, of course, restored the normal font size as you suggested. It is rare to encounter a person who combines such a high degree of emotional vulnerability with such a sturdy spirit of generosity.