vscode-powershell icon indicating copy to clipboard operation
vscode-powershell copied to clipboard

Please support programmatic open-file at custom line number/position (for programmatic go-to-definition scenario)

Open NickVH-MS opened this issue 3 years ago • 3 comments

Prerequisites

  • [X] I have written a descriptive issue title.
  • [X] I have searched all issues to ensure it has not already been reported.

Summary

I am migrating from the old powershell_ISE to powershell 7. One thing I used to do a LOT in the ps ISE world is a non-IDE-initiated Go-To-Definition. This was implemented as a command (i.e. Def MyFunction, if inside ISE, then it just opens there and sets the cursor to the position; if outside the ISE then it would open the ISE and set the cursor position there)

In the VSCode plugin, there is F12/Go-to-Definition in the UI, but I seem to be blocked from implementing it in command form (or I can’t find it). I did find “Open-EditorFile” which is close, but it does not allow me to point to a specific line, the way I could with the powershell_ise. In particular, $psise.CurrentFile.Editor.SetCaretPosition could be used to fine-tune where the cursor is pointing, but the $psEditor object seems to be highly restricted.

Would it be possible to get a feature to $psEditor.Workspace to have a function to open / jump to a given file+line? E.g. OpenFile(string filePath, uint32 lineNumber, uint32 columnNumber)? Allowing the user to 'pop' any file and line number they want is always going to be the most capable option, allowing people to jump to code that may be too obscurely done for the mainstream ISE to ever track.

(optionally, also add a psEditor.WorkSpace.GoToDefinition which more directly mirrors the existing UI option)

Proposed Design

Please add a new overload for $psEditor.Workspace.OpenFile, such as OpenFile(string filePath, uint32 **lineNumber**, uint32 columnNumber) (Also expose this overload in the CmdletInterface.ps1 file.)

Optionally, also add psEditor.WorkSpace.GoToDefinition(string identifier) and expose that in the CmdletInterface.ps1 as well.

NickVH-MS avatar Jul 11 '22 23:07 NickVH-MS

I think most of the stuff you're looking for in $psEditor is probably under $psEditor.GetEditorContext()

e.g. to set the cursor location to line 30 column 10 you can do

$psEditor.GetEditorContext().SetSelection(30, 10, 30, 10)

You can also send it to the VSCode CLI tool:

code --goto "${file}:${lineNumber}:${columnNumber}"

(Note that I haven't given the API proposal much thought yet, wanted to drop in to give you these options first!)

SeeminglyScience avatar Jul 12 '22 19:07 SeeminglyScience

Thanks for the pointer to $psEditor.GetEditorContext().SetSelection! Yes, that is basically good enough for my scenario. A few notes:

I am opening the file, then assuming the current file is correct, then jumping to the spot I want. Making these two steps into a single atomic "goto" call would be best. In practice the number of problems with atomicity would be small but it would still seem less hacky to use a single call with a "goto" semantic. So it would still be nice to have the "OpenFile" overload I proposed, or perhaps under a different name like "GotoFilePosition" or something.

psEditor.WorkSpace.GoToDefinition would still be handy but I can basically implement it myself now so it's not important.

So yeah I am happy enough with SetSelection to unblock this for now.

NickVH-MS avatar Jul 13 '22 01:07 NickVH-MS

One complaint with $psEditor.GetEditorContext().SetSelection, It doesn't actually scroll to the position in the file being selected. If the file is large, I have to scroll up and down looking for what was selected. Can that be fixed, or maybe add another "goto" position api that's more about scrolling to the correct place in the file?

NickVH-MS avatar Jul 13 '22 03:07 NickVH-MS