Arrow down in a wrapped line gets read in its entirety by NVDA

[alexdima]

Extracted from @Neurrone 's comment in #26730 (comment)

I've installed the add-on and the global plugin that bumps the wait time up to 200ms.

A possibly related problem: if a long line of text is wrapped across multiple lines, NVDA incorrectly reads the entire line when arrowing through. For example, this section is right at the top of the default settings.json file

// Controls auto save of dirty files. Accepted values:  'off', 'afterDelay', 'onFocusChange' (editor loses focus), 'onWindowChange' (window loses focus). If set to 'afterDelay', you can configure the delay in 'files.autoSaveDelay'.

NVDA reads the entire 3-line block when arrowing through each line.

[isidorn]

@alexandrudima now when screen reader is detected word wrap is always automatically disabled. I guess that makes sense but just to double check if that is the expected behavior

[alexdima]

Yes, the problem is that I have no <textarea> APIs at my disposal to explain to the <textarea> where we introduce wrapping points. I also cannot simply use \n for wrapping points, as the \n will be read out as line feed at wrapping points, which is incorrect. I also cannot guarantee that the <textarea> will wrap natively at the same wrapping points the editor does (even if I carefully try to size it, since we use different wrapping algorithms, etc.).. so my only recourse is to disable wrapping in the editor to get a 1:1 mapping of <textarea> lines and editor lines, such that cursor down goes one line down in the editor and one line down in the <textarea>.

[isidorn]

@alexandrudima thanks for the explanation. That makes sense to me