PR#13483 caused NVDA to report unexpected Blank

[cary-rowen]

Steps to reproduce:

1. nvda+Ctrl+Z Type the following, then press enter:

• print("hello")
• print(['hello'])

Actual behavior:

NVDA speaks "" "blank" after each output:

• 'hello' blank
• ['hello'] blank

Expected behavior:

No redundant "" "blank" should be reported.

NVDA logs, crash dumps and other attachments:

nvda_log.txt

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

NVDA-2023.1

Windows version:

Windows 10 22H2 (AMD64) build 19045.3086

Name and version of other software in use when reproducing the issue:

None

Other information about your system:

None

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 NVDA add-ons are disabled, is your problem still occurring?

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

yes

[seanbudd]

Is this only occurring in the NVDA python console?

[cary-rowen]

I currently only observe this change in behavior in the NVDA python console.

[seanbudd]

This might be intended behaviour - and representative of the python console UX. When pressing enter, the results are announced, and then NVDA announces the now empty input prompt ">>>" which is replaced with blank due to symbol processing.

I don't think this is an issue with #13483 - perhaps behaviour could be improved suppress the announcement of ">>>" in the NVDA python console.

[cary-rowen]

I also found a behavior change that could be misleading:

If a line contains only one underscore "_" then NVDA will only speak "blank".
Is this actually expected as well? Is there any way for me to know if the line is blank or contains an underscore without raising the underscore punctuation level.
In the past, nvda would be silent, and while it's not optimal, I can indeed distinguish between truly blank lines and lines containing unpronounced symbols.

[cary-rowen]

@seanbudd
There is also a more serious use case:

Steps to reproduce:

1. Enter the following in a rich text editor (such as MSWord): "word_count";
2. Move the caret to the front of 'w';
3. Press Ctrl+RightArrow to try navigating by word

Actual behavior:

When navigating to underscore "_" NVDA reports "blank".

[SamKacer]

@cary-rowen thanks for alerting me to this. Actually all of these different cases, including the last one are intended behavior and were explained in my initial comment for the PR.

Essentially, any situation where all the text is removed due to symbol processing or dictionary substitution would before just be silent. Now instead in any of those situations it is spoken as "blank".

To check why something is blank that you didn't expect to be, I think is no different than checking why something is silent under the old behavior:

• If a line is blank that you didn't expect to be (like in the NVDA python console), you can double tap numpad 8 to have it spelled out
• if moving by word (like in your last example) you can double tap numpad 5 to have it spelled out

The argument I made in the PR is that although some people might prefer even different behavior still, like a different phrase spoken, an earcon played, and others, silence is pretty much the worst possible behavior, since it can give the appearance that NVDA froze and is especially confusing to new users that haven't gotten used to the silence bug

I think, that in the python console case, it is more honest now. You have symbol level set at such a level that you don't wish greater than signs to be read. Or perhaps you created a dictionary substitution like I did. With old behavior, you didn't even realize that the prompt is being read. If the prompt let's say was actually just a blank line or spaces, I would expect you would have heard "blank" as well with old behavior. But the silence bug was masking this.

Besides, it is actually a useful thing to have something read when the prompt comes back up in the console. Imagine you execute a long running command. With old behavior and your settings, you would just hear silence while both 1) the command was still running and 2) the command finished running and the prompt came back up. But with new behavior you would still get silence during 1 but then hear "blank" to indicate you entered 2.

If you want something better than blank in that situation you can either change the prompt. Or do what I did long ago and create a dictionary substitution from >>> to "ding"

[LeonarddeR]

To be honest, I consider this change to be causing very undesirable output. Consider the lines below, for example:

{
}

Lines containing only brackets really shouldn't be pronounced as blank, as they simply are not blank. I agree that there could be debate on whether no speech should be output for lines where text processing strips out all the punctuation and results in no speech, but the construct of blank is too misleading.

@seanbudd Please consider reverting this change and bring it back to the drawing board.

[seanbudd]

I've drafted an approach here in #15027, feedback on the new behaviour is welcome

[XLTechie]

To be honest, I consider this change to be causing very undesirable output.

Very much agreed with @LeonarddeR. I don't concur that settling for "blank" because it is supposedly better than silence, is reasonable. Blank is always a lie in these situations. It would make me question every "blank"--is there really something there being obscured? So I have to stop and spell the line to know. Yes, silence isn't ideal either, as was pointed out. Though just hearing a silent line wouldn't make me think there was a crash. There are so many ways for anyone to learn that the screen reader is still running, that this can't be a real concern. However, I said this, approximately, in the original PR. I and also @lukaszgo1, proposed the alternative of raising punctuation level to speak lines that would otherwise be silent, in order to solve this issue, but I suppose that proposal was not preferred by NV Access at the time. Edit: posted by email before getting the batch containing @seanbudd's proposal.

[CyrilleB79]

I must confess that I was feeling quite unconfortable with #13483 but had not been able to take the time to think why.

I think that some people have taken advantage of NVDA reporting either nothing or blank to help discriminate different situations. And #13483 removes this capacity.

The original postulate of #13483 considers that NVDA freezes. If it is the case, the root cause should be addressed, not a consequence.

I would agree with reverting #13483 and think better to it. Sorry @SamKacer for not having taken time to think to it and react to it on time.

At the time it was discuss, I think that the following case was considered problematic with the approach of the PR #15027:
A row containing 40 or 80 dashes or equal sign used as a separator

For reference, Narrator says blank when the line contains only spaces or tabs, and says nothing for a line containing only an unpronounced symbol such as underscore.

[SamKacer]

As I elaborated in #15027, I think #13483 should be reverted. I think the main mistake I made is that even this new behavior should have been off by default and require opt in through a config option

Also this has further persuaded me that there is no one behavior that is always better or always worse.

No single behavior is truly universally good, so users have to be able to choose based on their preference and current situation/workflow. Also thanks to this I learned that conversely no behavior here is universally bad, like I thought about the current silence behavior

Once #13483 is reverted, I could offer another PR offering the same behavior, but make it configurable, so by default users still get the silence behavior, but could opt in to the "blank" behavior.

[cary-rowen]

@SamKacer wrote:

Essentially, any situation where all the text is removed due to symbol processing or dictionary substitution would before just be silent. Now instead in any of those situations it is spoken as "blank".

I don't think any of these cases should be considered blank, in my first example it was an underscore "_".

@SamKacer wrote:

To check why something is blank that you didn't expect to be, I think is no different than checking why something is silent under the old behavior.

Silence is not a perfect solution, but I have a hard time agreeing that a misleading solution like 13483 is the best.

@SamKacer wrote:

if moving by word (like in your last example) you can double tap numpad 5 to have it spelled out.

On the contrary, mute is more likely to prompt me to press numpad 5 twice to confirm.
NVDA is reporting 'B' when it's 'A'. Isn't it completely wrong behavior?

BTW, I don't think giving the user more configurable options is the best interaction solution.

[seanbudd]

Closed by #15032

[XLTechie]

I didn't notice before that @SamKacer wrote:

To check why something is blank that you didn't expect to be, I think is no different than checking why something is silent under the old behavior.

I disagree with this. Currently, something is only silent if (1) its content was suppressed for some reason, or (2) NVDA has crashed or is frozen. On the contrary, something is only blank, because it's blank. Blank is not ambiguous. There are lots of blanks, all the time--between paragraphs in some programs, at the end of text editing sessions, empty documents, etc. They all signify that the line/buffer is empty. You only must check if the rest of the lines are empty, not worry about whether the current one that was just spoken as blank, actually is. maybe it's different for you, but for me, silence is almost never. Blank can be several times per minute, depending on what I'm doing. By the logic in the quote above, by compressing real blanks into false blanks, the latter of which were previously rare silences: now all blanks are suspect. And since there are always far, far more blanks than silences, the amount of time consuming checking of whether blanks are blank, will grow exponentially. So it is not "six of one and half a dozen of the other" as we say in the U.S., meaning that it's not the same amount of work in one direction as it is in the other, just maybe a slightly different kind. Alternate but equal. The blanks to silences ratio is extraordinarily skewed on the side of the blanks, so making everything blanks means that the number of times the work to verify must be done, is very significantly higher.

[SamKacer]

@XLTechie My assumption is if you have your symbol level on a particular setting, it means you want NVDA to skip reading certain symbols because at that current time you don't care whether they are there or not. So a line containing only characters that you don't care about if they are there, should be read same as a line that has no characters at all.

You might disagree, but ultimately it just comes down to personal preference. I might prefer brevity and responsiveness and you might prefer speech sequences that is as accurate as possible at all times. And that's totally fine. As far as I am concerned, my only mistake was not making this configurable. That way you can have your vanilla and I can have my chocolate and we don't have to spend days arguing over which icecream flavor is better

[LeonarddeR]

This is not a difference between vanilla and chocolate. This is a difference between presenting either correct or incorrect information to the user.
Also your assumption might be correct, but it is not complete. Restated, I would write it down like this:

if you have your symbol level on a particular setting, it means you want NVDA to skip reading certain symbols because at that current time you don't want them announced by speech.

In other words, symbol levels aren't there to aid people who don't care about symbols. They are there to aid people who don't want these symbols to be announced. That might be a small difference but in this case, I think it is pretty important, as it has consequences for the most desirable outcome.
Furthermore, users who have speech symbols on a low level might have braille to support them. Announcing blank for lines with suppressed symbols while they are shown on the braille makes information ambiguous.

[CyrilleB79]

Please let's not discuss further in a closed issue. Else the arguments might be lost.

Let's rather discuss in #13431 or in a new issue if needed.

One thing is sure, a consensus should be reached before opening a new PR on this topic to avoid reverting it again.

[LeonarddeR]

Note that #13431 doesn't cover all symbols, just tabs.