Adds editor options overloads to showTextDocument & vscode.diff#23641
Adds editor options overloads to showTextDocument & vscode.diff#23641jrieken merged 6 commits intomicrosoft:masterfrom
Conversation
|
@eamodio, thanks for your PR! By analyzing the history of the files in this pull request, we identified @alexandrudima and @jrieken to be potential reviewers. |
|
@eamodio, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request. |
|
Check, in the middle of endgame this week. We have resources to jump on this starting next week |
|
OK, thanks. I'll dig into the broken tests soon as well |
f789b62 to
9dd64f7
Compare
|
@jrieken I resynced this with master and ran the test locally and I don't get any failures. Hopefully the builds will succeed now. |
|
I see the failures now (in the integration tests), but I'm having trouble figuring out how to debug them. Any help would be appreciated. |
src/vs/vscode.d.ts
Outdated
There was a problem hiding this comment.
Sooo, if we add this new overload it should include column and also make it a type which we can document nicer
There was a problem hiding this comment.
OK - Will do. Should I also allow any other editor options come through? I have it explicitly locked to just that set right now
There was a problem hiding this comment.
In the protocol/shape there should only be one signature and the calling side should do the argument construction
|
Please also rebase this on master to see if those tests still fail, they shouldn't. Then I wonder if we actually tackle #10568 here. There is also an ask to (1) know if an editor is pinned or not pinned and (2) an ask to change that after the fact. We should think about exposing this information on the editor, similar to |
|
For a name instead of As for exposing the information -- totally agree, I look into adding that. But for changing after the fact -- that feels less clear. Should you be able to go from something pinned to not pinned? Maybe so, but the UI currently doesn't provide a way for that direction (though an extension might have a good reason for it). What do you think? Also can you elaborate on the last point about certain editors can't be pinned -- where would I find that, and would/should that be handled explicitly here? |
|
Look here (#10568 (comment)) which is about making the transition. Basically turning an existing editor into a pinned (from a preview editor)
This is only an issue when the pinned-state is exposed as property. Similar to |
|
Ah got it -- going from unpinned --> pinned make perfect sense (was thinking that could just be handled by another call to |
9dd64f7 to
1c92003
Compare
|
I made the first set of changes -- didn't rename pinned yet until there is agreement on a new name. |
src/vs/vscode.d.ts
Outdated
There was a problem hiding this comment.
@jrieken I don't love this name, let me know what you think
There was a problem hiding this comment.
Maybe turning it around TextDocumentShowOptions or TextDocumentViewOptions?
There was a problem hiding this comment.
TextDocumentDisplayOptions?
There was a problem hiding this comment.
@jrieken I moved some of the data massaging into here, so that it could take the same ShowTextDocumentOptions (since I think you can technically call the proxy methods from inside an extension).
There was a problem hiding this comment.
Don't use the TypeConverter here but send proper data. Do all the massaging before calling a main-side method. Rule of thumb is that mainXYZ files shouldn't depend on extHostXZY files
There was a problem hiding this comment.
The main issue with that, is then we would need 2 "versions" of the TextDocument[Show|View|Display]Options -- one for the extensions with a column and one for the main-side with a position. Which is certainly doable, I was just trying to not have 2 types with almost the same fields. Are you fine with adding 2 types? And if so, where should the main-side one live and how should it be named to not cause confusion?
There was a problem hiding this comment.
Two - one is API the other the DTO
|
@eamodio Can you go ahead and resolve the merge conflicts? |
src/vs/vscode.d.ts
Outdated
There was a problem hiding this comment.
Maybe turning it around TextDocumentShowOptions or TextDocumentViewOptions?
There was a problem hiding this comment.
Don't use the TypeConverter here but send proper data. Do all the massaging before calling a main-side method. Rule of thumb is that mainXYZ files shouldn't depend on extHostXZY files
|
@jrieken is a rebase/force push fine to resolve the conflicts or should I do it in a follow-on commit? |
That's OK for me |
|
@jrieken Are you good with Also see comments above |
|
Yeah, let go with |
Moves column into the options Removes overloads from the proxy
Changes pinned property to preview Adds ITextDocumentShowOptions as main-side DTO
1c92003 to
ca163e0
Compare
|
@jrieken I've resolved the conflicts and made all the code review changes above |
| export interface TextDocumentShowOptions { | ||
| /** | ||
| * An optional view column in which the [editor](#TextEditor) should be shown. The default is the [one](#ViewColumn.One), other values are adjusted to be __Min(column, columnCount + 1)__. | ||
| */ |
There was a problem hiding this comment.
Wow - your commit should have been blocked because that's a formatting issue...
| }); | ||
|
|
||
| CommandsRegistry.registerCommand('_workbench.diff', function (accessor: ServicesAccessor, args: [URI, URI, string, string]) { | ||
| CommandsRegistry.registerCommand('_workbench.diff', function (accessor: ServicesAccessor, args: [URI, URI, string, string, vscode.TextDocumentShowOptions]) { |
There was a problem hiding this comment.
it's dangerous to use the vscode-module here (actually everywhere outside the extension host) because these type actually don't exist. for interfaces it's OK because they disappear but using IEditorOption would have been better
There was a problem hiding this comment.
I don't see an IEditorOption -- there is IEditorOptions, but that interface doesn't have any of the fields. Are you suggesting adding them there? Or am I missing something?
|
Trying to understand why the test have failed... |
| pinned: true | ||
| }; | ||
| } else { | ||
| options = { |
There was a problem hiding this comment.
The else cannot be unconditional because it will be hit when no second parameter is given. Add a check like typeof columnOrOptions === 'object'
|
I think the fall-through case was causing the test failures -- they all passed now! :) |
|
Merging now. Thanks for this PR, for reacting to feedback. |
|
@jrieken thank you! |
|
Look great -- just had that 1 comment on a possible behavior change. |
This PR hopefully addresses #10568
Also addresses a need I have with
vscode.diffto have the same control (for GitLens)@jrieken This is a first shot at this -- please let me know what you think. I added it as options so that it could be expanded later to allow for other editor options (but didn't want to go there at this stage).