What new F8 could look like - Client side handling

[TylerLeonhardt]

PR Summary

A little experiment of what F8 could look like if it were handled client side instead of server side.

Why?

• Totally external to PSES so it doesn’t contribute to “grabbing the pipeline thread” at all. This still means that F8 won’t work while something is already running, but that’s a given.
• Takes advantage of PSReadLine’s multiline support
• Actually gives us syntax highlighting because of PSReadLine as well (big win!)

Cons

• Because of the UNIX terminal oddities we have today, the characters are “typed” one at a time. This is much slower than the instant F8 before. We may be able to fix this.

Goals

Support for replacing $PSScriptRoot with:

path.resolve(vscode.window.activeTextEditor.document.uri.fsPath, "..");

PR Checklist

Note: Tick the boxes below that apply to this pull request by putting an x between the square brackets.
Please mark anything not applicable to this PR NA.

• PR has a meaningful title
• Summarized changes
• PR has tests
• This PR is ready to merge and is not work in progress
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready

[SeeminglyScience]

• Because of the UNIX terminal oddities we have today, the characters are “typed” one at a time. This is much slower than the instant F8 before. We may be able to fix this.

That's a bigger problem than it may appear:

1. New lines act the same as pressing Enter, causing input to be ran line by line (assuming no lines cause IncompleteParseException)

2. Syntax that doesn't work the same when typed character by character will work differently, e.g.

   if ($true)
   {
   }
   else
   {
   }

3. Input will trigger PSRL keybinds that do not necessarily map directly to what their trigger character implies, see Pasting multiline code conflicts with parentheses/brackets/brace-matching key handler PSReadLine#735

Also there was talk about supporting breakpoints when using F8. Currently this wouldn't be too difficult to do, you'd just use the Parser.ParseInput overload that takes a file name, and maybe pad out text so that the sequence points match. If it's just raw input then we close the door on that as well.

[TylerLeonhardt]

In response to 1 and 3, wrapping the script in a dot-sourced script block will address that, and give us the syntax highlighting.

. {
    if ($true)
    {
    }
    else
    {
    }
}

Number 3 is a valid concern.

As for this:

Also there was talk about supporting breakpoints when using F8. Currently this wouldn't be too difficult to do, you'd just use the Parser.ParseInput overload that takes a file name, and maybe pad out text so that the sequence points match. If it's just raw input then we close the door on that as well.

I don’t really think we’ll have the time to work on this, unfortunately. The reason this PR was sent in the first place was to help make PSES do less since today it does so much.

With all that said, this PR is less important given the resolution of PowerShell/PowerShellEditorServices#980 .

[SeeminglyScience]

In response to 1 and 3, wrapping the script in a dot-sourced script block will address that, and give us the syntax highlighting.

. {
    if ($true)
    {
    }
    else
    {
    }
}

Yeah, the fun part of number 3 though is that a not so uncommon key bind is "smart" { that closes brackets for you like an editor would. I use that, and if I try to right click paste (which works the same as this PR basically) the first line becomes . {} and then the rest fails.

I don’t really think we’ll have the time to work on this, unfortunately.

Well yeah, I know. It's not that much effort I don't think, I'll probably take it up after 2.0 is released.

[TylerLeonhardt]

Yeah, the fun part of number 3 though is that a not so uncommon key bind is "smart" { that closes brackets for you like an editor would. I use that, and if I try to right click paste (which works the same as this PR basically) the first line becomes . {} and then the rest fails.

Unfortunately, I think this is one of those things that will turn into an anti-pattern going forward considering xtermjs and non-Windows does not allow PSRL to handle the Paste action.

That means there would be no "safe way" to paste if a keybinding like that is set.

That special paste could be remapped to something obviously not Ctrl+V

[SeeminglyScience]

Unfortunately, I think this is one of those things that will turn into an anti-pattern going forward considering xtermjs and non-Windows does not allow PSRL to handle the Paste action.

I disagree that it's an anti-pattern, either way you don't really need paste as long as F8 works 🤷‍♂

That means there would be no "safe way" to paste if a keybinding like that is set.

That special paste could be remapped to something obviously not Ctrl+V

FWIW you can with terminal-input:

// keybindings.json
{
    "key": "ctrl+v",
    "command": "terminalInput.sendCustomInput",
    "args": [ "checkMark" ],
    "when": "terminalFocus"
}

// settings.json
"terminal.integrated.commandsToSkipShell": [ "terminalInput.sendCustomInput" ],
"terminalInput.customInputs": { "checkMark": "\u2714" },

# profile.ps1
if ($env:TERM_PROGRAM -eq 'vscode') {
    Set-PSReadLineKeyHandler -Chord "$([char]0x2714)" -Function Paste
}