Improve UI

[Zalastax]

@chuckdries let's iterate on ideas for the UI. We could do that here or on gitter. I'd like shortcuts to move in the tree even if the tree window is not focused. I'd also like the window to be less in the way, possibly by doing a window-split. Mouse interaction would be nice as well.

[chuckdries]

Hey sorry I haven't responded, I've been swamped with homework.

I like the idea of doing a window split, I'm not immediately familiar with how VSCode handles creating windows, but I've seen extensions create and open new tabs in a split, I've also seen what appear to be custom windows displayed in the current active tab. I'm thinking like whatever https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory is doing. It's clear, interactive, easy to read, and allows you (though it takes a few clips) to view older states of the file.

Based on knowing that vscode is javascript and absolutely nothing else, I'm going to assume that we can draw HTML in a panel, which will allow us to enable mouse support and such.

I'm going to sit down and pore over what you have written and vscode's dev documentation this weekend, sorry again for my ignorance!

[Zalastax]

Hey, school is always more important! I'm in the same situation for two more weeks.

This is how gitHistory does their split: https://github.com/DonJayamanne/gitHistoryVSCode/blob/9039041523aa371a55360e316869b6af6a765e9a/src/commands/fileHistory.ts#L162-L172. The VSCode API is not unrestricted so it's possible that splitting the window has limitations. We can use HTML, but do we want to? Can you draw nice lines in any way? Perhaps SVG gives us both control and free mouse + tabIndex. Implementing interactivity in the canvas should be easy too.

[Zalastax]

Ah, it's fairly easy to create a custom preview! Combining a custom URI with a custom content provider lets us render our canvas in a preview pane, replacing the call to addOverlayWidget in historyTree.ts.

BTW how should we handle keeping the fork up to date? I like doing rebase to keep the changes clean, but that won't work well when we both make commits. Or maybe it's fine if I just alert you on gitter?

[Zalastax]

I looked into it a bit more and it's not as easy as I thought. registerTextDocumentContentProvider comes from the workbench which you're not allowed to access from vs/editor/contrib. There is also no communication channel into previewHTML so you need to set up your own websocket. The best solution in my opinion is to migrate the rendering into an internal extension using the vscode API.

Then the problem of providing an API that extensions can use. If we don't do this step then we need to have the renderer live in vs/workbench and VSCodeVim won't get an API they can use. Adding to the API is not too difficult, but there's several steps. This is my plan: First edit vscode.d.ts and modify the interface for TextEditor. I think we should expose at least moveTo, getHistory, and onHistoryChanged. onHistoryChanged might already be covered by the events in onDidChangeTextEditorSelection, but onHistoryChanged is easier for me to think about so I'd rather expose a duplicate for now. Modifying vscode.d.ts will cause errors, especially for ExtHostTextEditor in extHostTextEditor.ts. Add the missing methods to the class but implement them as dummy functions. ExtHostTextEditor has a property _proxy that is used to send messages. We need to add properties to the MainThreadEditorsShape to communicate with the backend model,allowing us to implement the functions we added to ExtHostTextEditor. After adding the properties we can again follow the errors, leading us to MainThreadEditors where we add the functions that communicate. From MainThreadEditors we can get hold of the editor model and reach the history API by following my snippet.

const editor = this._documentsAndEditors.getEditor(id);

if (!editor) {
    return TPromise.wrapError<ILineChange[]>(new Error('No such TextEditor'));
}
editor.getModel().getHistory();

@chuckdries do you want to work on the API or on making an internal extension (like extensions/git)? I started making the extension and then realized getHistory etc are not exposed and wrote this report up. Both tasks should be fairly straight forward and fun. If you want to work on the internal extension I'll send you the code I have so far, and for implementing the API I hope my plan makes the task clear.