New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Text is corrupted when using AutoHotKey abbreviation-expansion with NVDA #4499
Comments
Comment 1 by jteh on 2014-09-30 02:04 I'd like to fix this, but I'm not really sure how we could. |
Comment 2 by jteh on 2014-09-30 02:12 |
Comment 3 by Palacee_hun (in reply to comment description) on 2014-09-30 15:53
|
Comment 4 by andrewd (in reply to comment 3) on 2014-09-30 22:08
|
Comment 5 by jteh on 2015-06-22 05:15 |
Comment 7 by andrewd (in reply to comment 5) on 2015-06-22 22:12 Testing with the snapshot produces the same results as previously. With "Handle keys" unchecked it still works fine and when checked characters still get corrupted. Replying to jteh:
|
Comment 8 by jteh (in reply to comment 7) on 2015-06-22 23:39
Err, my bad. I meant enabled, not disabled. So I wanted you test with it checked, not unchecked. Sorry for the confusion.
Hmm. Just to confirm, which exact snapshot was this? Was it next-12152,46d0a2e? |
Comment 9 by andrewd (in reply to comment 8) on 2015-06-23 00:23 Replying to jteh:
|
Comment 10 by gmhtml (in reply to comment 8) on 2015-06-23 00:25
I'll add my two cents in just to be sure. |
Comment 11 by jteh (in reply to comment 10) on 2015-06-23 00:37
Interesting. So you're seeing different results to comment:9, where the correct snapshot (next-12152,46d0a2e) works as expected even with the box checked.
Hmm. I don't understand this. Even without the fix, a restart shouldn't be necessary to make a change to this setting take effect. That suggests there is another problem here. |
Comment 12 by James Teh <jamie@... on 2015-07-10 04:26
Changes:
|
Comment 13 by jteh on 2015-07-10 05:29 |
Comment 14 by gmhtml (in reply to comment 13) on 2015-07-11 03:42 |
Comment 15 by andrewd (in reply to comment 14) on 2015-07-13 00:42 Replying to gmhtml:
|
Comment 16 by jteh on 2015-07-13 02:17 Technical: The problem is that NVDA can't tell the difference between keys injected by NVDA and keys injected by other applications. This solution queues keys to ensure correct order, but that means we have to inject them, and while we're doing that, we must ignore injected keys to prevent loops. Unfortunately, that may also cause us to ignore keys that happen to arrive from other apps at the same time. Unless there's some way of detecting who injected a key, I don't know if/how we can fix this. |
Comment 17 by James Teh <jamie@... on 2015-07-15 08:59
Changes:
|
Comment 18 by jteh on 2015-07-15 09:01 |
Comment 19 by andrewd (in reply to comment 18) on 2015-07-15 22:46 Replying to jteh:
|
Comment 20 by jteh on 2015-07-15 23:00 |
Comment 21 by andrewd (in reply to comment 20) on 2015-07-15 23:52 Replying to jteh:b
|
Comment 22 by James Teh <jamie@... on 2015-07-16 03:42
|
Comment 23 by jteh on 2015-07-16 03:42 |
Comment 24 by dkager on 2015-07-31 10:43 |
Comment 25 by jteh on 2015-07-31 11:06 |
Comment 26 by dkager (in reply to comment 25) on 2015-07-31 16:55
Yeah, turns out my pretty HTML userdocs weren't in sync for some reason. Oops. |
… text expansion functionality (e.g. in AutoHotkey). InputGesture.execute: if an intercepted command script (script that sends the gesture it intercepts) is queued and or has not yet completed its execution, queue any further gestures that do not have a script via a fake script that just sends the gesture. this ensures that input stays in order even if it was delayed by NVDA. Fixes #2953, #4499.
) doesn't fix garble keys with text expansion functionality (#4499) after all. :(
@michaelDCurran's #4499 (reference) and @jcsteh's #4499 (reference) include commits. Are they indicators of further progress on this ticket, or has all of Jamie's earlier work been reverted due to problems? Also, should we give up in case of this ticket and close as cantfix, or do @LeonarddeR, @derekriemer, @josephsl, @dkager and others have further thoughts/inputs? If implementation cost is too high for what this ticket's worth, we may wish to mark as a P4. |
I think this is fixed, but we need @jcsteh or @michaelDCurran to confirm. |
No. The fix for this was reverted in 171a430, since it didn't actually work. Setting as p4, since this affects few users, has a work around (disable Handle keys from other applications) and appears to be very difficult to even diagnose. |
just to be sure, @AndrewD are you still having this issue with the last NVDA version? |
I use the latest NVDA version in 22.4, which prevents any of text expansion apps. I tried espanso, text-expander, when triggering the text replacement under the NVDA, it just replaces the abbreviation into space rather than the correct replaced text. |
Reported by andrewd on 2014-09-29 04:12
If abbreviation-expansion is coded as follows:
::ad::My name is Andrew
the expanded text is usually missing character(s). If coding:
:b0:ad::My name is Andrew
is used the abbreviation characters, are not deleted and the presence of NVDA does not result in lost characters. It is then necessary to delete the characters manually, which somewhat defeats the purpose of the facility.
I use an AutoHotKey script to put HTML tags into a file. This involves opening and closing tags with an intervening blank line and this exacerbates the problem. The following works on my machine:
:b0:pg::
Send, {home}
Sleep 200
Send,
n
nSleep, 300
Send,
n Sleep, 300 Send, {del 3} Send, {up 2} Return If selecting from a menu or hotkey instead of using the abbreviation, the following works well: Send, <p>
nn</p>
n{up 2}Return
Other screen readers don't have this issue. Turning off speech or turning on sleep mode does not help.
Unless this has wider implications, it is a very minor issue.
Blocked by #2953
Blocking #5144
The text was updated successfully, but these errors were encountered: