Conversation
This reverts commit 69a16cc.
Contributor
|
I upgraded the package as part of other dependency updates. If downgrading restores full functionality with Unicode characters, I see no reason not to. |
seanbudd
reviewed
Feb 13, 2024
user_docs/en/changes.t2t
Outdated
Comment on lines
+195
to
+196
| - Updated Comtypes to version 1.2.0. (#15513) | ||
| - Added extension point: ``treeInterceptorHandler.post_browseModeStateChange``. (#14969) |
Member
There was a problem hiding this comment.
I'm not sure why these items are in the diff
Member
There was a problem hiding this comment.
Suggested change
| - Updated Comtypes to version 1.2.0. (#15513) | |
| - Added extension point: ``treeInterceptorHandler.post_browseModeStateChange``. (#14969) |
Member
Author
|
I think I got the merge conflict wrong for this file.
I have fixed it up now by taking what is currently on beta and just
deleting the diff_match_patch 2.1.0 line.
I think it was confusing as some of those entries moved after the
original pr was merged.
Message ID: ***@***.***>
|
seanbudd
approved these changes
Feb 13, 2024
Contributor
|
Hello @codeofdusk |
Adriani90
pushed a commit
to Adriani90/nvda
that referenced
this pull request
Mar 13, 2024
Fixes nvaccess#16027 Reverts nvaccess#15514 This reverts commit 69a16cc. Summary of the issue: PR nvaccess#15514 upgraded diff_match_patch from 1.0.2 to fast_diff_match_patch 2.0.1. However, the newer version cannot handle particular unicode characters such as 🍰. The diff_match_patch process dies, NvDA can no longer report text changes, and NvDA hangs on exit. Description of user facing changes Printing unicode characters such as 🍰 in a terminal withn using diff_match_patch for speaking changes no longer causes NvDA to no longer report text changes and lock up on exit. Description of development approach Downgrade back to diff_match_patch 1.0.2.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Link to issue number:
Fixes #16027
Reverts #15514
This reverts commit 69a16cc.
Summary of the issue:
PR #15514 upgraded diff_match_patch from 1.0.2 to fast_diff_match_patch 2.0.1.
However, the newer version cannot handle particular unicode characters such as
🍰. The diff_match_patch process dies, NvDA can no longer report text changes, and NvDA hangs on exit.Description of user facing changes
Printing unicode characters such as
🍰in a terminal withn using diff_match_patch for speaking changes no longer causes NvDA to no longer report text changes and lock up on exit.Description of development approach
Downgrade back to diff_match_patch 1.0.2.
Testing strategy:
Followed steps in #16027 and ensured that NVDA spoke the
🍰character when printed, that it continued to speak further text changes, and that NvDA did not lock up when exiting / restarting.Known issues with pull request:
An alternative approach was shown in #16027 where NVDA could filter bad characters from diff_match_patch. this may be necessary in future if we do need to upgrade again eventually. But as this broke in the current (2024.1) cycle, there was no critical reason for the upgrade originally that I could see, and downgrading was clean, then this is the most appropriate solution at this late stage in the 2024.1 cycle.
@codeofdusk was there any other motivation to upgrade other than just keeping up to date with the latest version?
Code Review Checklist: