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.
Upcoming versions of the Windows Console will be able to differentiate
a color set by the Win32 API from a color set by VT. This code
transforms a Win32 color into a VT color, and then uses that VT color
during rendering. When an enlightened console host receives this VT, it
may handle it differently (translate it differently, reverse it
differently, store it differently). Use `39;49` for the default foreground/background.
We'll also teach the various console implementations how to
handle it.
Correct cursor positioning in cases where newline appears 1 character before
last column, or a CJK character ends the line but wraps to next display
line, and in cases where continuation prompt contains either CJK characters,
or VT color sequences.
Fixes#1216, #1217, #1188.
- Update `ReallyRender` to avoid writing everything every time when editing the text. Instead, we find the first different logical line, and starting writing from there.
- Refactor `ReallyRender` by moving some logic to separate methods.
- Support editing text even if the top of the text has been scrolled up-off the buffer.
- Disallow cursor to be set to a position that is off the buffer.
- Fix a bug in `ConvertLineAndColumnToOffset` so that a point can be translated to the offset correctly.
There are likely issues introduced by this PR,
but I'm merging for a new Beta so this code gets more testing.
* Introduce PSKeyInfo type alias
* Explicit conversions b/w ConsoleKeyInfo and PSKeyInfo
* Change tests to use actual ConsoleKeyInfo data
* Add fr-FR keyboard layout tests
* Add KeyInfo-ru-RU-windows.json (#839)
All impossible without Shift shortcuts labeled as "Investigate: true"
Alt+Spacebar tracked by windows itself
* Add KeyInfo for Polish (Programmers) layout on Windows and Linux (#870)
On Windows *Alt+Spacebar* is hijacked by Windows
On Linux any *Alt+F1-12* combination was not detected
This fixes some weird issues in WSL and some Linux terminals.
This also works around a Windows 1809 Console bug for the Ctrl+l binding
to clear the screen by using the same escape sequence that bash uses.
Fix#724
When the prompt is drawn with a different color than the default text,
after displaying the error prompt, the prompt is not restored correctly.
The option -PromptText will now recognize the use of escape sequences
for color so the prompt can be restored correctly after the error prompt
is removed.
Rewrote the custom key binding code to be more portable.
Some runtime checks are necessary because of impossible to reconcile
differences.
Some Win32 P/Invoke calls are still needed due to lack of information in
the ConsoleKeyInfo.
Some keys are currently not available on Linux due to a CLR bug, others
aren't available ever because terminals don't unique character sequences
for a given key press that might differ in just the Shift or Ctrl state.
Andy Jordan