Brian1Gaff
commented
4 years ago I ran into a variation of this when attempting to catch the wake word of a certain assistant under specific circumstances. Thanks for explaining why things don't work as predicted. I had never realised that this was what this actually did before. Brian
bglists@blueyonder.co.uk Sent via blueyonder. Please address personal E-mail to:- briang1@blueyonder.co.uk, putting 'Brian Gaff' in the display name field. Newsgroup monitored: alt.comp.blind-users ----- Original Message ----- From: "Brian Vogel" notifications@github.com To: "nvaccess/nvda" nvda@noreply.github.com Cc: "Subscribed" subscribed@noreply.github.com Sent: Monday, November 09, 2020 6:40 PM Subject: [nvaccess/nvda] Dictionary processing, as currently implemented, does not stop once the first match has been made and iterative processing produces wildly unexpected results (#11823)
Steps to reproduce: This is not exactly applicable, but after
discussions with @Qchristensen about dictionary processing, he produced this example: Dictionary entries are processed in order, and do continue, but based on the current, not original, text. So I just tried setting up the following entries:
change "dog" to "cat" change "12345" to "54321" change "432" to "dog"
Encountering the text 12345 now, the first rule is skipped, since there is no "dog" in this text. The text includes 12345 so it becomes 54321. The third rule is then evaluated and the 432 in the current text is changed to dog.
So NVDA reads:
5dog1
If the text read "dog 12345", it would be read as: cat 5dog1.
I'm not sure if that's documented anywhere, and given that rule order is meaningful, there is no current way to reorder rules (I wrote the 12345 to 54321 and 432 to dog rules, and then thought to try adding dog to cat first, but had to delete the other two and write all three from scratch in the order I wanted them).
Actual behavior:
Expected behavior:
I would expect the outcome, with original input text of "dog 12345" to be NVDA speaking, "cat 54321," and if the original text is just 12345, the expected result would be NVDA speaking 54321. Iterative processing where substituted text from a rule above gets passed through all following rules goes against any pattern matching processing of this sort I have dealt with in over 40 years. When an initial match is made, the typical behavior is that match is acted upon and the matching stops, not that the substitution text for the first match is then passed along for processing by all further patterns. The outcome of that, in many practical situations, is madness. This is currently creating an issue when attempting to use regular expressions to have Roman Numerals read out as their component letters, as repeat substitution on substituted text for numerals IIII down to I, and VIII down to V, and IX all get parts of their substitution texts passed through additional patterns no matter how one tries to configure the pattern matching rule order. Once the match is made, the substitution should be passed to the synthesizer and that's that.
System configuration
NVDA installed/portable/running from source:
NVDA version: 2020.3, but I believe this has been the case "forever"
Windows version: Windows 10, Version 2004, Build 19041.572
Name and version of other software in use when reproducing the issue:
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Have you tried any other versions of NVDA? If so, please report their
behaviors.
If addons are disabled, is your problem still occuring?
Did you try to run the COM registry fixing tool in NVDA menu / tools?
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/11823
britechguy
Qchristensen
Steps to reproduce: This is not exactly applicable, but after discussions with @Qchristensen about dictionary processing, he produced this example:
Dictionary entries are processed in order, and do continue, but based on the current, not original, text. So I just tried setting up the following entries:
change "dog" to "cat" change "12345" to "54321" change "432" to "dog"
Encountering the text 12345 now, the first rule is skipped, since there is no "dog" in this text. The text includes 12345 so it becomes 54321. The third rule is then evaluated and the 432 in the current text is changed to dog.
So NVDA reads:
5dog1
If the text read "dog 12345", it would be read as: cat 5dog1.
I'm not sure if that's documented anywhere, and given that rule order is meaningful, there is no current way to reorder rules (I wrote the 12345 to 54321 and 432 to dog rules, and then thought to try adding dog to cat first, but had to delete the other two and write all three from scratch in the order I wanted them).
Actual behavior:
Expected behavior:
I would expect the outcome, with original input text of "dog 12345" to be NVDA speaking, "cat 54321," and if the original text is just 12345, the expected result would be NVDA speaking 54321. Iterative processing where substituted text from a rule above gets passed through all following rules goes against any pattern matching processing of this sort I have dealt with in over 40 years. When an initial match is made, the typical behavior is that match is acted upon and the matching stops, not that the substitution text for the first match is then passed along for processing by all further patterns. The outcome of that, in many practical situations, is madness. This is currently creating an issue when attempting to use regular expressions to have Roman Numerals read out as their component letters, as repeat substitution on substituted text for numerals IIII down to I, and VIII down to V, and IX all get parts of their substitution texts passed through additional patterns no matter how one tries to configure the pattern matching rule order. Once the match is made, the substitution should be passed to the synthesizer and that's that.
System configuration
NVDA installed/portable/running from source:
NVDA version: 2020.3, but I believe this has been the case "forever"
Windows version: Windows 10, Version 2004, Build 19041.572
Name and version of other software in use when reproducing the issue:
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Have you tried any other versions of NVDA? If so, please report their behaviors.
If addons are disabled, is your problem still occuring?
Did you try to run the COM registry fixing tool in NVDA menu / tools?