Stopping speech at a precise point

[andrew-l-d]

This is a feature request. Would it be possible to stop speech at a precise point in order to - say - make an edit? Something like the pause speech feature via the shift key but WITHOUT THE RESUME. Whether in Word, Notepad or a webpage, stopping speech with the control key leaves one at the beginning of the sentence or thereabouts. I have tried all combinations of routing, but it seems that the only way to get to a precise point is to move word by word. Submitted by Mr Impetuosity

[Adriani90]

there are lots of ways to geht back to your point, you could for example turn off the setting "navigator follows the system focus". IN that way the navigator will stay at the point where you have switched it off. (i.e. read the text until word number 350, turn off navigator follows system focus, go to your edit field and edit something, then use the numlock to read the text at the navigator. You will notice that the navigator did not change its position. Thus, given this workaround, I am closing this issue as works for me. If you have another strong argument for this feature, please post your arguments here and we can reopen.

[andrew-l-d]

I fear I did not explain the situation I am thinking of clearly. I am reading through a document having used NVDA-a (laptop mode). I press the control key at a point I want to read more carefully. Instead of placing the cursor at that point, it is placed at the beginning of the line. It is then necessary to move along the line word at a time to get to the point of interest. Compare that behaviour to pressing the shift key, where speech stops and restarts at that exact point. What I am requesting may well not be possible, but it is not the scenario you described. Andrew

[Adriani90]

I think I understand now what you mean. I think the feature requested here is to stop speech and resume it while navigating through the document, i.e. something like an advanced function of the shift key. There could be two options for this:

1. Via speech refactor, to create a separate speech function which can stop and resume the speech while allowing for navigation (i.e. press ctrl+shift stops the speech, you can navigate, then ctrl+shift resumes the speech from the point it was stopped) or
2. Add the possibility to stop and resume speech at review cursor (i.e. you can turn off review cursor follows system cursor,you can navigate with the system cursor while applying a say all on review cursor which allows you to stop and resume speech at any time). For this option there are two scripts needed, one for applying say all on review cursor, and the other one to stop and resume speech.

I think the second option would be much easier to implement and would have less impact on performance than the first option. cc: @JulienCochuyt, @michaelDCurran what do you think?

[feerrenrut]

Was the original request about say-all? I don't see it mentioned. Supporting pause-resume of say-all is one thing, but supporting this with speech in any situation is likely to encounter many more edge cases.

[andrew-l-d]

Say-all is one situation where the feature would be useful. But to raise the volume of alarm bells that Reef was hearing, it could also be useful when reading by line or sentence.

Andrew

[CyrilleB79]

Would this issue be fixed or at least linked with PR #9937?

[Adriani90]

Unfortunately not completely, the main request is here that you can for example interact with edit fields and so on while stopping speech and resuming it on another point regardless of where the system focus is. That's why I thought a say all on the review cursor while not following the system focus would solve this issue. Because then the review cursor can scroll independently. Then you could stop and resume the speech at the review cursor as you like while doing other things with the system focus.

However, if the speech refactor allows for a parallel speech sequence which does not depend on system focus or review cursor, then this would be a better solution. But I assume this would mean a higher impact on performance since you would have to define a buffer which should contain tings like the length of the text you include in the speech sequence, i.e. only what's visible on screen etc.

[CyrilleB79]

@Adriani90, I think @andrew-l-d's request was misunderstood. He did not speak about edit field, nor about resuming text reading. Here is what I have understood:

STR:

• User exectute a text reading command, e.g SayAll (NVDA+DownArrow), read current line (NVDA+UpArrow) or Read next sentance in MS Word (Alt+DownArrow)
• While text is reading the user hears a word of interest (e.g. because there is a spelling mistake)
• The user press an existing gesture (control, shift) or a dedicated gesture to stop reading

Expected result: The cursor is located at the position where speech was stopped and the user can immediately modify the word of interest, e.g. the misspellt word.

Actual result: The cursor is located at the beginning of the line or at the beginning of the sentence. And the user need to perform extra commands (e.g. word navigation commands) to go to the word of interest.

@andrew-l-d, can you confirm I hav understood your need?

I have mentionned PR #9937 because from its description, it seems to fix this issue, at least for SayAll mode. I do not know if it also fixes the issue for other speech commands (say current line, go to next sentence, etc.). @leonardder any thought?

[andrew-l-d]

My initial suggestion did not involve edit fields etc. The say-all moving the cursor by word would go a long way to achieving what I envisage. Situation: reading through a document and coming to a word I want to correct or check. Hit control and the cursor is at that point rather than at the beginning of the line. Andrew

[andrew-l-d]

Sorry, I wrote the above before reading Cyrille's comments. You have described exactly what I envisage. Andrew

[bhavyashah]

For reference, https://github.com/nvaccess/nvda/issues/8955#issuecomment-624110782 gives the clearest explanation of this request. A couple thoughts below:

1. I agree that, in case of a say all, this would be quite useful. This would only be an incremental change here because the focus already moves to the beginning of each new line that say all reaches, and this would now change to keeping up with say all word by word as opposed to line by line.
2. If we justify doing this for Alt+down arrow, then line navigation (up/down arrow) and paragraph navigation must also be included for consistency. However, I am struggling to express why this change would be helpful during a say all but constant focus changes when I am just navigating a document would not. I think it is important to note what a radical change this would be, meaning that users would take time to adapt. This is because all users perform text navigation and text editing, and this change would fundamentally affect where the focus is and what is being reviewed or selected at any given point in time. Perhaps this is an inherently good change - I am not convinced of it - but the learning curve it would introduce should be weighed against any potential benefits.
3. I would view and treat keystrokes like the read current line command similar to commands mentioned in point 2.

[Adriani90]

It seems there was a superseeding PR, #11658, which has been abandoned by the sumiting author.