-
-
Notifications
You must be signed in to change notification settings - Fork 634
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
better support for editing characters in the middle of lines in command prompt/terminal #3200
Comments
Comment 1 by jteh on 2014-09-12 04:38
This chunk of code can't handle insertions or removals, only changes. We'll probably need to do a character diff or similar to handle this properly. |
Comment 2 by nvdakor on 2015-04-06 12:05
|
Comment 3 by jteh on 2015-04-07 00:10 Also, it's not really so much that we intentionally announce the rest of the line. The problem is that we can't find where the difference ends. This is why I'm wondering whether a proper character diff would be best here. |
Comment 4 by nvdakor (in reply to comment 3) on 2015-04-07 03:29
Gotcha. In the end, I abandoned start marker idea, as there was really no need for it.
Longest common subsequence... But that'll take a while to compute that. An in-place character diff would be ideal. But I can see that a bit of memoization might be involved, to remember the last entry in the input field. This will require some careful thought. For testing purposes, I'm using regular version of cmd.exe on Windows 8.1 (since I'm testing from source). I found that Cygwin will not work properly for debugging purposes. |
Comment 5 by camlorn on 2015-04-12 23:56 |
Comment 6 by jteh (in reply to comment 5) on 2015-04-13 00:16
If I understand correctly, Joseph meant the marker would be where the caret was last positioned. That way, you only have to do this for characters added after the cursor. The problem is that relying on the cursor is, well, unreliable at best, largely due to network lag, etc.
We're only dealing with the text on the screen. We use Python difflib to determine new and modified lines and then our own crappy, broken algorithm to determine new characters on modified lines. I'm proposing we also use difflib for characters on modified lines. I guess we thought diflib would be too slow for characters when we wrote this (or we for some incorrect reason didn't think you could use it for characters), but premature optimisation is the root of all evil and all that...
For reference, it's in NVDAObjects.behaviors.LiveText._calculateNewText. |
Comment 7 by jteh on 2015-04-13 02:57 One option I briefly looked into some time ago is Google DIFF Match and Patch. It's available in Python, but it's pure Python. This Python extension module might be better, though again, if the pure Python version is fast enough (it could well be faster than difflib), we should just use that. Note that if we're using another library, we need to take into account the joining of individual lines into a single string and then splitting the output text into separate lines. I wouldn't imagine this is overly expensive, but it's worth noting when doing performance tests. |
Comment 8 by camlorn on 2015-04-13 20:46 |
Comment 9 by jteh (in reply to comment 8) on 2015-04-14 02:15 Replying to camlorn:
We already do.
I meant the screen utility (or anything that completely replaces a screenful of text; even moving to a new page would do this).
Note that we're basically dealing with a rolling diff; i.e. if n lines are appended to a full screen of text, the top n lines will disappear and all remaining lines will be index - n.
It does, but I'm not sure whether we can hook these; Windows consoels aren't entirely normal processes. In any case, I'd prefer to avoid this solution; in-proc API hooking is tedious and it'd also be good if this code could apply to applications which use screen scraping (e.g. PuTTY). |
Comment 10 by jteh on 2015-04-24 01:07 |
@derekriemer are you thinking to extend your console timer add-on? Or is the add-on not further developed? Maybe a function for solving this issue could be added. |
Diff Match Patch (DMP) was included but disabled by default in 2021.1. It fixes #3200 and allows for drastically fewer cross-process calls in UIA console, improving performance in busy applications. This PR enables DMP by default to allow for wider user testing in master snapshots. If user feedback is positive, use by default in 2021.2.
Reported by camlorn on 2013-05-04 20:49
Currently, when editing any text in the middle of the line, both in terms of deleting with backspace and typing new characters, NVDA will read everything to the right of the cursor position. It would be helpful if it didn't, as I wish to use VI and am frequently using ssh for website administration.
The text was updated successfully, but these errors were encountered: