Open jugglinmike opened 3 years ago
josephsl
commented
3 years ago Hi, is this the case with this particular input for tmux, or have you found a consistent pattern? Also, have you tested what Narrator says after you perform these steps? If Narrator announces “01:00”, chances are that this is specific to WSL+API in use. Thanks.
jugglinmike
commented
3 years ago Hi, is this the case with this particular input for tmux, or have you found a consistent pattern?
Good question; researching the answer gives a clearer picture of what's going wrong.
NVDA only seems to announce changes "on the hour," and it announces the hours from 01:00 to 10:00 accurately. As for the rest, it's a mixed bag:
The behavior at midnight is more telling, but there's a little more to know about tmux to understand it. By default, the complete tmux status line includes a list of the open tmux "windows", the current time, and the current date, so the full string looks something like this:
[0] 0:vim 1:vim 2:bash "DESKTOP-QOPRRSQ" 00:00 29-Jun-21
When the time rolls over to a new date on midnight, then NVDA also announces the day of the month. For example:
NVDA appears to be only announcing the parts of the line which have changed. Perhaps a change-detection algorithm is at fault.
Also, have you tested what Narrator says after you perform these steps? If Narrator announces “01:00”, chances are that this is specific to WSL+API in use. Thanks.
Narrator reads the complete status line, including the list of tmux windows.
It seems likely that the true conditions aren't specific to TMUX but are instead related to in-place terminal updating. Maybe I can make a simpler reproduction with a Bash script that writes terminal control characters to standard output.
josephsl
commented
3 years ago Hi, ah, I think this is due to live text changes in terminal. CC @CodeOfDusk who has worked on something like this for a while.
codeofdusk
commented
3 years ago This is expected behaviour, as NVDA only speaks the characters that have been inserted:
>>> nav._calculateNewText(newText="2021-06-29 11:00:00", oldText="2021-06-29 10:59:59")
['1:00:00']Here is the latest algorithm for determining what text is actually new.
codeofdusk
commented
3 years ago This is not a DMP regression:
>>> diffHandler.get_difflib_algo().diff(newText="2021-06-29 11:00:00", oldText="2021-06-29 10:59:59")
['1:00:00']
>>> diffHandler.get_dmp_algo().diff(newText="2021-06-29 11:00:00", oldText="2021-06-29 10:59:59")
['1:00:00']
feerrenrut
commented
3 years ago @codeofdusk this seems like a good opportunity to consider expanding the diff to the word boundary (unless some upper limit of characters is reached). Have you considered this kind of approach?
codeofdusk
commented
3 years ago We could do this at the risk of running into #3200 again...
Brian1Gaff
commented
3 years ago Sounds a bit like thesize of the grabbed field is set once and then longer numbers do not fit. Maybe it needs to assume a leading 0 on single digit hours? Brian
XLTechie
commented
3 years ago On a totally unrelated point: are you aware of the screen program as an alternative to tmux?
It has no permanent status bar.
Steps to reproduce:
sudo apt-get install tmuxtmuxsudo date -s "2021-06-29 10:59:59"Actual behavior:
NVDA announces "one o'clock"
Expected behavior:
NVDA announces "eleven o'clock"
System configuration
NVDA installed/portable/running from source:
NVDA installed
NVDA version:
2020.4
Windows version:
Windows 10 Home
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?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
No
If add-ons are disabled, is your problem still occurring?
No add-ons present
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Yes