Tests that depend on supported features such as menu completions, list
view, inline predictions, continuation prompt, and colors are skipped.
The "helper" module for running tests from the command-line and in
AppVeyor is minimally updated to not skip the new fixture.
A `BlankRestOfBuffer()` function implements the semantics of the `0J`
control sequence in the mock console.
This adds the `EnableScreenReaderMode` command-line switch which
defaults to true if an active screen reader is detected.
In screen reader mode, the existing `ForceRender()` function is replaced
by `RenderForScreenReader()` which uses a differential rendering
approach to minimize extraneous output to the terminal, allowing the use
of screen readers better than ever before.
The differential rendering relies on calculating the common prefix of
the `buffer` and `previousRender` strings. Nearly all necessary changes
are consolidated in the new rendering function.
Features known not to be supported:
* Colors: as this necessitates redrawing to insert color sequences after
the input is received and the AST parsed.
* Inline predictions: as this by definition changes the suffix and thus
requires endless redrawing.
* List view predictions: since the render implementation never calls
into the prediction engine, this is not available either.
* Menu completion: well, it "works" since it's not disabled and does its
own rendering, but no effort has been made to improve `DrawMenu()`, so
it's not accessible (and I'm not sure it could be given our current
constraints).
Features known to be partially supported:
* Text selection: mark and select commands work as intended, but provide
no visual indication.
* Multiple lines: as in newlines work fine, but there is no continuation
prompt.
* Visually wrapped lines: editing above a wrapped line redraws all
subsequent lines and hence is noisy.
* Status prompt based commands: what-is-key, digit-argument, and most
notably, forward/backward incremental history search all render a
"status prompt" on the line below the user's input buffer. This _is_
supported; however, it can be noisy since it necessarily has to render
the whole buffer when the input buffer changes, including the status
prompt (and search text). But what it's reading is almost always going
to be relevant.
Everything else should generally work, even Vi mode, and the tests pass.
That said, this isn't perfect, and moreover the approach specifically
doesn't attempt to enable things from the ground up. There may be
features that are available but turn out not to be accessible (like
`MenuComplete`) and I believe they should be left as-is.
Specifically tested with NVDA on Windows and VoiceOver on macOS within
VS Code's integrated terminal, with shell integration loaded, and Code's
screen reader optimizations enabled.
These tests were using a hard-coded continuation prompt (and its length)
which blocks tests for the upcoming screen reader mode.
This is also simply a reasonable refactor, thanks Claude (for trying).
This supports checking for the built-in screen readers VoiceOver on
macOS and Windows Narrator, as well as the popular open-source option,
NVDA.
The VoiceOver check spawns a quick `defaults` process since in .NET
using the macOS events is difficult, but this is quick and easy.
The Windows Narrator check inspects a system mutex. Notably though this
screen reader handles re-rendering better than others.
The check for NVDA et. al. inspects the system parameter information.
While this approach is known to be buggy, the preferable and commonly
used algorithm (as implemented by Electron) which checks for loaded
libraries was tested and found to be unsupported for a non-windowed
program like PowerShell.
It's unknown if the SPI check will detect JAWS, Window-Eyes, or
ZoomText, so a command-line option for the upcoming screen reader mode
should also be provided.
Linux is not yet supported.
This character was always meant to be an ellipsis. I'm unsure exactly
why Visual Studio interprets it so, but VS Code and GitHub do not. This
commit replaces it with the actual Unicode character which ensures the
tests continue to pass when these files are edited and saved in VS Code.
By retargeting PSReadLine to `netstandard2.0`, we can simplify the build a lot and produce the same assembly no matter building on Windows or non-Windows.
- Update PSReadLine build to target `netstandard2.0`, including the CI and release pipeline YAML files.
- Update the test to target `net472` and `net6.0`, so that we can run tests with both .NET Framework and .NET
- Rename `Microsoft.PowerShell.PSReadLine2.dll` to `Microsoft.PowerShell.PSReadLine.dll`
- Update and clean up the `README.md` with the up-to-date information
Dongbo Wang