Arabic diacritics make the letters after them triggerable in Auto-Replace Topic is solved

[barkoosh]

Hello

Arabic language has diacritics which are some sort of short vowels. When used, they appear above or under the letters. On keyboards, they are typed with SHIFT. (Their unicode character codes are: 064B, 064C, 064D, 064E, 064F, 0650, 0651, 0652) The problem is that if a word has a diacritic, AHK considers the letters after it as if they are a new word and triggers an Auto-Replace.

Here's an example. If I have the following hotstring in my AHK script:
::اح::مع جزيل الاحترام
(which replaces اح with مع جزيل الاحترام)
AHK won't trigger an Auto-Replace if I type an ending character after the word سياح which has no diacritics, but it will after سيّاح. (That's because there's a diacritic above the second letter to the right, followed by اح).

Is there a way to avoid this?
PS: Breevy has the same problem.

Thanks

[lexikos]

I think that I would need to modify the hotstring recogniser to check for non-spacing marks. I suppose that if a hotstring trigger is directly preceded by a non-spacing mark, that effectively modifies the (appearance of the) trigger's first character, so it should be treated as a different word.

If there is a hotstring trigger starting with a non-spacing mark, and an alphanumeric character is typed before it, it should already be correctly recognised as within another word. (The hotstring recogniser only checks the preceding character, not the first character of the hotstring trigger. Rather than "inside a word", it's "touching a word".)

I'm not really sure whether this change would be correct for all non-spacing marks, or all non-spacing diacritic marks, or neither, as I know very little about the use of non-spacing marks in any language.

This should produce the same result as the check internal to the hotstring recogniser (requires Unicode):

Code: Select all

; c := chr(0x62d)
c := chr(0x651)
StringCaseSense Locale
if c is alnum
    MsgBox alnum
else
    MsgBox not alnum

StringCaseSense Locale causes if var is type to use the "locale-friendly" IsCharAlphaNumeric function, which is actually independent of locale; i.e. I believe it produces the same results on every system, regardless of locale settings.

This shows how we can classify the character (Ctype 3 shows 0x0003, a combination of C3_NONSPACING and C3_DIACRITIC- see MSDN):

Code: Select all

c := 0x651
o := chr(c)
Loop 3
    if DllCall("GetStringTypeW", "uint", 1<<(A_Index-1), "int*", c, "int", 1, "int*", t)
        o .= format("`nCtype {}: 0x{:04x}", A_Index, t)
MsgBox % o

(This code is for information only; I do not think you can use it to solve your problem.)

[Guest]

Could this be solved with Dynamic Hotstrings?
https://autohotkey.com/boards/viewtopic.php?t=3329

[lexikos]

Please try this test build and let me know whether it solves the problem.

[barkoosh]

The test build works perfectly. All the Arabic diacritics have no effect on Auto-Replace. They are now recognized as within the word.

Thanks a lot lexikos.