API Access to "Open Editors"
ChuckJonas opened this issue · comments
I have a use case where I would like to be able to get a list of all the open editors (basically exactly what is shown here).
I understand that Editors are disposed but I just need a list of filenames.
Something like: workspace.openDocuments:Array<TextDocument> or even just workspace.openFiles:Array<string>.
Long term, it might be nice to have API access to operate on this list (EG: sort open editors pane by last opened, name, etc).
Also, just wanted to add that this is blocking our vscode Salesforce IDE extension (mavensmate) from reaching feature parity with Sublime and Atom (and thus increasing the risk of it being abandoned by users).
Background: Salesforce requires that classes be compiled on their servers. In order to refactor multiple classes, you must send a single compilation request with all classes. Because compilation is slow, you typically only want to compile a subset of your project (IE only files related to a refactor).
The way existing salesforce IDE's handle this, is by allowing users to compile all open tabs.
@ChuckJonas I don't know if this is still blocking you, but I've used a hack here that might work for your depending on your use-case. You can see it in action in the Restore Editors extension.
@eamodio ahhh very nice! Never would have thought to use the workbench.action.nextEditor cmd to loop through all the editors.
Still seems like sort of a ridiculous hack for something that should obviously be accessible in the API.
@ChuckJonas totally agree, but it was the best I could figure out with the tools available ;)
fyi @dbaeumer
Cheers @eamodio, using your work around for something I'm working on too!
Also noticed I had to copy the way you wait in between executing commands because sometimes the activeEditor wont be set yet? Is that a separate issue worth reporting do you think?
@lukebatchelor getting an active editor of undefined is to be expected at this point. It gets set to undefined if there are really no editors, but also if the focus switches to a non-editor window
@eamodio, Im not getting undefined in these cases, but sometimes the same editor.
I assumed that was why have the 500ms pauses in your code?
@lukebatchelor sort of -- the timeout is because while the workbench.action.nextEditor will move to the next tab, if you have 2 non-text editors next to each other, the active editor becomes undefined when it switches to the first (and the active editor changed event will fire), but now when it switches to the next, it will still be undefined, but no event will fire, because it went from undefined to undefined -- so the timeout is a safety net for the event not firing
Oh okay. Thats different to what i was getting.
I'll try again but i was executing closeActiveEditor then logging the active editors document uri and would sometimes be the same still, until i added the pause. Same with nexrEditor.
Weird.
This would be really nice to have!
I am working on an extension that takes encrypted files and decrypts them. The problem is I need the encrypted file path so that I can decrypt the file.
vscode doesn't let you access the file uri of a binary file because the active editor is undefined.
Alternatively it would be cool to allow the user to choose what encoding to display binary files. I would think the default would be UTF-8.
#11247 is about making the tab-model not only readable but also writeable, e.g. open a background-tab which we must consider when implementing this
FYI there is some further conversion about this here: #26568 (comment)
@jrieken any thoughts on that? It doesn't address the need of an API for a lot of other use-cases, but it could provide a nice shortcut for a (decent?) set of scenarios.
Is there any progress or plan for this functionality? It feels really odd that there is still no way for an extension to be able to simply get a list of the currently opened files (even if they are not loaded).
I'm hitting this too. I need to provide my language service with a list of "priority files" and I was sending what I believed to be:
- Visible documents
- Other open (non-visible) documents
However I've discovered that my means for getting open (non-visible) documents (workspace.textDocuments) is flawed and contains documents that had their editors closed, but the documents are still "open" according to Code.
This means I'm unable to write tests to ensure that my priority files are working correctly, as I have no way of telling which files a user actually has open (but not visible).
We need this for VSCodeVim as well. Our use case is explained here: #51001 (comment)
Is this planned any time soon? The vim issue is pretty annoying.
@c10b10 Hopefully thumbs up attract more attention to this issue. For non-vim users, we cannot effectively edit the same file opened in two different editor groups (e.g. split one file vertically and view/edit different parts in each pane)
+many. The API feels needlessly restrictive. What's the downside for MS to make this available for extension developers? I can't think of one.
Much as I like vscode the API could really use some love. Not to sound unappreciative, but the quality of extensions has so much potential if only the API would open up a bit more.
+1 ! Needed for a personal extension that keeps me from opening too many files :0
@jrieken Is there any update on this? The tab model issue (that I was pinning my hopes on) has been closed...
This issue has been open for over 2 years?
As the fifth highest voted open issue for the API, I hope to see this in the VS Code Roadmap 2019 as the final release of 2018 wraps up in the few weeks.
I've encountered a bunch of extensions that are broken or work poorly due to this specific issue.
Haha. Funny you linked that, my comments above were for when I was making that add-on :P
You'll be pleased to know that "close all saved" is actually built into VSCode now (thanks to @soneymathew)
it'd be cool to be able to switch between tabs in your workspace on a branch switch.
it'd be cool to be able to switch between tabs in your workspace on a branch switch.
This workflow any many others will be supported in the extension that I'm building for VS and VS Code - http://contextkeeper.io
I want to cover all aspects of "dev context" that is created when working at specific PR/task/feature/bug. There is often a need to switch to something else and there is no easy way to turn back and restore lost context. Moreover there will be a way to save and share your contexts with entire team because they will be saved as diffable files (aka mental snapshots). Ready to commit in git. Stay tuned!
extension that I'm building for VS and VS Code
But how? How do you get the open editors when there's no API for it (hence this issue)?
extension that I'm building for VS and VS Code
But how? How do you get the open editors when there's no API for it (hence this issue)?
@noppa good question. When there is no official API it will be harder to implement but I believe possible. In the second comment @eamodio mentioned hack that his Restore Editors is using. When you will dig long enough sometimes you find a way.
Visual Studio also doesn't have any explicit API for its internal engine that restores last opened windows and tabs. It has .suo file when it stores them but it's like black box. You could save or restore certain windows state but you have no control how it will be done at window/tab level. Because VS's last opened files engine has many flaws I wrote independent engine that ContextKeeper is using to position VS's windows and restore tabs. It works very well and allows a whole range of possibilities like opening the same mental snapshot when you switch from your desktop box to laptop without manual windows repositioning - it's detects current resolutions of connected monitors and prepare appropriate layout where all windows fit nicely to new environment. The ContextKeeper's engine allows to save mental snapshots to human-friendly diffable files so you could not only switch between different contexts easily but also track what was changed in them via git. Sharing contexts with a team opens another range of possibilities.
Nothing above would be possible when I would give up and tried to use broken and limited ".suo" API. It took a lot of time but I found a way and created "alternative" API.
For vscode, it sounds like you'll end up hacking the application code rather than building an extension then, which is a shame. On your website it says you have a commit ready for git - I assume that's for Visual Studio and not vscode?
For vscode, it ounds like you'll end up hacking the application code rather than building an extension then, which is a shame. On your website it says you have a commit ready for git - I assume that's for Visual Studio and not vscode?
@Gruntfuggly ContextKeeper will be pure extension for both VS Code and VS. I know that are limitations. Some of them discussed in this thread but also others like no support for floating windows in VS Code #10121 which were always supported in VS. Workaround will be to use grid layout #14909 when you will try to open context from VS in VS Code to simulate the same windows and tabs layout (yes, opening the same context in both VS and VS Code will be possible!). I want to deliver similar experience for both VS and VS Code but knowing the limitations.
Well if you find a way to access open editors, please share! 😁
Would like to call out here that this kind of hobbles VSCodeVim, and it sure would be nice to have.
I'm starting to wonder if an extension which manually tracks opened editors might be useful...
I know that this issue is primarily concerned with exposing a tab/editor API, but since it's somewhat related, is there an existing way to target and close the "Welcome" page in code, or would this be tied to the features requested here?
@coltonoscopy "workbench.startupEditor": "none",
@Yzrsah I have that in the extension already, but what if we want to close it for them to provide a different starting point upon installation?
@coltonoscopy check pull request #60061 and issue #38778
As the fifth highest voted open issue for the API
Now 4th... not even a comment on this thread from the devs for nearly 2 years. 😞
hope never dies
cmon
So it appears that all this information is readily available, but it's not exported to the extension-visible API (https://code.visualstudio.com/api/references/vscode-api#window ). Which would mean that we'd need to send a PR that expands that API surface.
I'm not familiar enough with how the VS Code codebase works to make a PR myself, but I was able to find some starting points, which might help if anyone interested in implementing this wants to dive in. You'll have my undying gratitude if you do!
The "Open Editors" view is able to access all this data from the Groups Service, and it does so here:
Taking a step back, what we do see in the extension API seems to pass through here:
And that extension API seems to be populated from the Main Thread via a state machine here (see the class's usage):
That state machine seems to interact with the Groups Service only here (which makes sense since it's not really getting that much from the Groups Service, only a notion of what viewColumn it's in):
It seems like the notion of moveable Groups is relatively recently tacked-on to the codebase, and that technical debt may be the only reason nobody's tried to implement this yet. I doubt that performance considerations have anything to do with it - I haven't seen much mention of performance in the above areas. It might be as simple as allowing more information from that service to percolate through the state machine, perhaps sending along a bookkeeping data structure mapping editor IDs to information about where/what tab-order they currently have in the Group system.
https://github.com/microsoft/vscode/wiki/Feedback-Channels is also something I found for those who may just be getting exposed here (like me!).
Looks like at least 200 people really want to see this work, and it's blocking parity with other editors on important functionality! (For my part, I really want to be able to context-switch between Git branches with confidence that I can restore tabs that only make sense on a different branch... but as other commenters indicate, tab restoration is very limited right now.)
Hopefully someone can jump in here! :)
In my case, would be enough to provide an event when a text document has been hidden, that is, when its tab has been closed. Even the document is still there waiting to be disposed. I just need a notification.
Finally found this issue after banging my head on the API for hours - this is a crazy oversight and I'm amazed it is 3 years in the waiting with so many interested parties.
Also #14483 is not a duplicate. That set of features I also need to be able to deal with webViews and other non-textEditors but this request does not imply that non-textEditor tabs would be exposed in a useful way.
do we have a plan to get a list of open text editors. looping with the command nextEditor is really not an ideal solution. feels sluggish and hacky.
Any plan? It has been years.
Happy 2020! Still no plan?
+1
Support the author's request of this extension:
https://marketplace.visualstudio.com/items?itemName=Divni.open-files
Has this have any plans about getting the opend files?
I am doing some diffing, so I am relying on onDidOpenTextDocument to get an initial state, then using onDidChangeTextDocument to get the updated state. It seems when the editor restores files, it does not call onDidOpenTextDocument, or my extension is loaded after this happens (activation state is *). Being able to iterate over the open files would really help, especially if I could do that in activate. Thanks!
@jrieken has something changed here recently? In current stable code, I'm seeing onDidCloseTextDocument immediately when I close a tab in the editor. I'm unsure if I can rely on this now though?
I'm unsure if I can rely on this now though?
No
@jrieken do you happen to know what might be triggering it to happen immediately for me today? I'm trying to track down a bug that I think is related to it being called later, but I can't confirm it while it's triggering immediately. Thanks!
I stepped through the code, but couldn't figure out any case where it would not call onDidCloseTextDocument. If I understand the code correctly, when the editor is disposed, it disposes the model:
This results in onModelRemoved calling _updateState():
And _updateState uses the models (which no longer contains the document) to do a diff and figure out why documents to fire close events for:
I can't see any obvious way that this wouldn't happen. If there aren't any, then this issue may be resolved (which would be good, because I think delaying the close introduces weird bugs for both local extensions and LSP where the language server has invalid state for files when modifying files outside of VS Code, such as a bit branch change).
@DanTup This issue is about exposing the open editor tab model as API, not about document close events.
I'm confused - my comments have been marked as off-topic in this thread, yet many issues about that subject have been closed as duplicates of this. It's not clear what the expected behaviour is. If onDidCloseTextDocument fires reliably when you close a document, then many of the people interested in this thread may be unblocked (and also #68989 would be resolved). Is it possible someone can clarify the status?
If this is going to continue to get bumped each month, could the team outline a fix here and let the community implement it? Need some pointers to which files to look at and change, and what an acceptable behavior would look like.
I just cann't understand what prevents this issue from being fixed. It's hard? It has been years.
It's currently in the May milestone.
I'm confused - my comments have been marked as off-topic in this thread, yet many issues about that subject have been closed as duplicates of this. It's not clear what the expected behaviour is.
All those issues are closed a duplicate because what you and others are trying to achieve is impossible without this API. However, it doesn't mean that using the onDidCloseTextDocument is any good when trying to know what tabs are open.
The jsdoc for onDidCloseTextDocument reads like this:
Lines 9160 to 9168 in 9be0faf
I am not sure if "To add an event listener when a visible text document is closed, use the TextEditor events in the window namespace." is written badly or if you didn't see that.
Anyways, what that means that visible editors and closed text documents have very little in common. The only guarantee is that a document that's visible (which an editor is visible) is never closed. It also means that you cannot use the list of text documents as reliable information to know what editor tabs are open.
If onDidCloseTextDocument fires reliably when you close a document
This is a conceptual misunderstanding. You don't not close a document you close an editor or an editor tab - vscode closes the document when it thinks it is time to do so.
Tab-changes cannot be observed and are subject of this issue. In the screen shot below below, you have
- 1 text editor
- between 1 and N text documents
- 1 settings editor (which has no representation in the API)
- 7 editor tabs
We will not change 1, we will not change 2, we will not change 3. We will add an API that allows to observe and mange the list of tabs (some like to refer to this as the open editors (not text editors) list).
Goals of the API
- Have an API representation of the tab model (aka open editors)
- Have an API to manipulate the tab model (open, close, activate, move tabs and more)
- Have events that fire when tabs change
Note that "tab model != text editors" e.g an inactive tab has no text editor, an active tab might not show a text editor but something else. It's not yet clear how we associate a tab with editors that the API is aware of (text editors, notebook editors).
Properties that a "tab-object" should have
- name, detail
- view column
- uri (iff applicable)
- API editor object (iff applicable)
- likely more
Modifiers that should exist
- close, open tab
- active tab
- move tab within and across view columns
- likely more
Potential extension use-cases
- language extension validates all tabs for
fooLang, not just visible editor and not the whole project - extension to group tabs by folders, file type etc (
[foo.html], [foo.js], [foo.css], [bar.html], [bar.js], [bar.css]) - extension to open/close a set of editor tab
Thanks for that clarification and update.
I think you've hit the nail on the head:
I am not sure if "To add an event listener when a visible text document is closed, use the TextEditor events in the window namespace." is written badly or if you didn't see that.
is not consistent with
You don't not close a document you close an editor or an editor tab - vscode closes the document when it thinks it is time to do so.
It's written badly - there is no such thing as a "visible text document".
@jrieken thanks for the details.
All those issues are closed a duplicate because what you and others are trying to achieve is impossible without this API. However, it doesn't mean that using the onDidCloseTextDocument is any good when trying to know what tabs are open.
I'm not specifically trying to know what tabs are visible. It's fine for me if there's a visible tab that doesn't have an open document. It's the opposite that I think may cause issues (an open document without an editor). This is about ensuring language server state doesn't get out of sync with what the user sees. I don't think it's the same issue that this is asking for, but since my issues were all closed I'm not sure where to post it.
Here's an issue I believe may exist if onDidCloseTextDocument doesn't fire when the user closes an editor tab, though I can't verify it right now because onDidCloseTextDocument appears to be firing immediately. I'm concerned if that ceases to be the case (which you suggest may happen), this bug may occur. I'm investigating issues where users have reported changing Git branches and seem to have phantom errors left in their Problems view (or new errors that they should not). Here's what I think might be happening:
I'll use the LSP spec for examples here as it's clearest, but I think the issue is the same for non-LSP extensions.
The LSP spec says (about textDocument/didOpen):
The document open notification is sent from the client to the server to signal newly opened text documents. The document’s content is now managed by the client and the server must not try to read the document’s content using the document’s Uri
However, if you:
- Open a file in VS Code
- Close the editor
- At this point, if VS Code has not sent
didClose, the server believes the state of the document is still managed by VS Code, even though it's not visible to the user - Change Git branch so that the file is modified on disk
- I believe VS Code does not tell the server that file has modified on disk, yet the line above states that the server must also not read it from the disk. I believe this results in the server having the old contents for the file and therefore may show/send phantom errors for a file the user cannot see.
If there's some mechanism that prevents this from happening if onDidCloseTextDocument does not fire immediately, that's great - but I'd like to understand what it is so if this issue comes up again I'm able to debug better.
I believe VS Code does not tell the server that file has modified on disk,
I believe that's wrong and I am sure you'll able to file a separate bug with repro steps where a document that's considered open (e.g loaded) isn't updated anymore
It's written badly - there is no such thing as a "visible text document".
👍 Yeah, it should a text document in a visible text editor. Which is also a little bogous because all text editors visible by definition... At least we can fix the jsdoc
I believe that's wrong and I am sure you'll able to file a separate bug with repro steps where a document that's considered open (e.g loaded) isn't updated anymore
I don't have a repro because in my current testing, onDidcloseTextDocument always fires immediately. Like I said, I'm not sure that's the issue - I was trying to eliminate it. My understanding was that when the editor was visible, the user may be prompted before reloading a changed document, so I figured it might not happen if the editor is gone.
Is there some situation where onDidCloseTextDocument won't fire immediately, so I can test it?
It's written badly - there is no such thing as a "visible text document".
I raised this at microsoft/vscode-docs#1542 previously.
@jrieken please ping me if you have something. I would like to use it in the LSP client libs to only sync documents that are visible in the editor.
Happy to give feedback on the API as well.
Hi guys,
any news about this feature?
Unfortunately it's a blocker for our extension because we absolutely need to unlock the file after the has finished to editit.
Thanks
Gian
Is there any estimate on when this will actually be worked on? It keeps getting bumped (since March!) and has been open since 2016. I held off on writing some code figuring it would be done in a month, but here we are now in the June 2020 milestone. Should I just unsubscribe from this issue and cite this anytime someone asks me for VSCode support?
@jrieken lol keep on adding it will get done in few smtg 😜
I find it sad that this issue is lower priority than something like pinned tabs...
Sorry all, I've put this on the backlog again for now, since I'm not actively working on it at the moment. I am hoping to still make some progress on the design for the next iteration, but I also don't want to get anyone's hopes up (since I could easily run out of time and not be able to get to it).
Sorry Eric,
We were waiting for more the two months.
Are you able to give us some even ugly workaround?
The use case is simple in my opinion. I need a call to free the resource that was locked when it was open in the editor.
It's a blocker for us and unfortunately without this hook we cannot proceed over.
Thanks
Gian
I think this issue is taking so long because its request became too broad.
It started with “I would like to be able to get a list of all the open editors”. I’m a subscriber because when I opened #13639, it was closed being categorized as a duplicate of this one (which I didn’t buy, tbh). But after all this time, some other issues, which doesn’t seems related to the original request, are referencing this one.
You have:
- open/close events
- opening in background
- extension being able to close documents
- middle click on tabs
- and so on....
I mean, is it really necessary to have all of this features, just to provide an API to access the Open Editors? @jrieken commented above a lot of features this API could have, but as I stated, the initial request is much less complex. I know you guys take API very seriously, and that’s one of the main reasons (IMHO) VS Code is so stable for developers (👏 for that), but I think, in this particular case, the API could have started a lot simpler, and earlier, evolving with new features/areas on later releases.
Thank you
A simple list of open editors would be a good starting point
My request (also closed as a dupe of this) was for reliable open/close events. This is required for languages that want to prioritise the open files. From the open/close events you can maintain a list of open editors (and know when they changed), so I think if only one thing was done, events would be better than an API to just get the list (or at least, also an event when they changed).
We have understood the requirements and we can understand the frustration that our priorities aren't always matching expected priorities. I am now locking this issue because we haven't been able to retrieve additional actionable input. We take stable API very serious and we'll take our time to build a sound and solid API. Once that work has started we will report back here.
An API is currently being worked on slated for this iteration to address some of the common requests in the post.
The API we're focusing on right now is targeting reading of the tabs within VS Code. A modification API may come later but is not the focus of this iteration as a solid reading API is an important foundation and first step.
The current proposed shape of the API is as follows
vscode/src/vs/vscode.proposed.d.ts
Lines 2277 to 2333 in 213902e
I've unlocked the issue to gather feedback and answer any questions surrounding this particular proposal. If your questions / comments / concerns do not relate to a Tab API I suggest opening a separate feature request after searching for existing ones as excessive off topic discussion will lead to this issue being re-locked. Thank you everyone for your patience as we want to provide the best API possible to enable extension developers to create the best extensions possible 🙂
- How about a property to indicate a tab preview (italicized) state?
Tab.label: If two tabs with the same name are open, does this include the location?
What will the resource be in webview tabs?
Will they be simply null like marketplace tabs?
If they do have something, how will they be referred?
Webview url is kinda useless currently as far as I know, because you don't really have a way to get id of a webview instance.
Rather than the resource represented by the tab, wouldn't it be more useful to have the editor it contains?
Rather than the resource represented by the tab, wouldn't it be more useful to have the editor it contains?
I'm not certain, but I thought it may be possible that there are no editors for some tabs yet. For example if you open open VS Code and it re-opened 20 tabs from a previous session, it might not create editors for those items until you actually switch to them?
Fair point - the resource will definitely be a good starting point. It would be handy though if the editor was available (if it has been created).
@Gruntfuggly Do you have a good use case of when you need the editor? There's too many types of editors and the resolution is async where as the tabs are sync it wouldn't make much sense and would be a bad design.
- How about a property to indicate a tab preview (italicized) state?
@mattacosta Maybe. We don't want to get property bloat for properties that don't have viable use cases. If you have a use case for it I would be interested in hearing it
Tab.label: If two tabs with the same name are open, does this include the location?
@mattacosta They contain what group they're apart of and the array is ordered.
What will the
resourcebe in webview tabs?
@mmis1000 Not sure will have to investigate. My guess is if it does have one it will be a special URI scheme which is how you will know it's a webview
@lramos15 My extension loops through all open editors and runs a process if the editor contains a file under SCM (git) to determine whether or not to close the tab. I guess I can probably determine that from the resource though - currently it gets the URI from the document via the editor.
After ironing out some details, I'm looking for feedback from actual users of this API. This API is in a proposed changing state and as such you must use proposed API to access it. The guide to using proposed APIs can be found here. If you have any feedback pertaining to the API please comment here. Any bugs please file separate issues. Thanks!
Moving API development to #133532 as this is more than just an open editors API. The API will include the open editors feature but be more versatile to serve greater use cases.
Hi @lramos15 - that already gets me one step further regarding my usecase.
Not sure if I am missing it in the proposed API change, but would it also be possible to access the editor for the resource within a tab?
Something like this:
vscode.window.tabs.forEach((item) => {
item.resource // only gives Uri for File
item.editor?.document.close() // what I am trying to accomplish
}
@martinmeinke No, it's hard to get the distinction but Tabs != editors. Tabs are merely arbitrary view containers and therefore could have anything in them. Sometimes they can even be empty, this means there is no document or resource etc. To be helpful we provide some info about what the tab contains but there isn't a document for all tabs and therefore this isn't an option. tab.close() will be a function though which will cover your case.
Thanks for the clarification! Then I'll wait for the tab.close() support!
Thanks for the clarification! Then I'll wait for the
tab.close()support!
tab.close() has entered the proposed API. As always remember that things are just in a proposed state and continue to change.
I would welcome this. The default open editors widget is not very convenient, this API could help to get a reliable extensions to replace it.
Thank you for
the completion of one of our most upvoted issues
with April 2022.
As this feature request from November 2016 (issue no 15178) with 314 upvotes was done, is there now hope for #1012 (a feature request from December 2015 with 410 upvotes; not sure if the additional 10 hoorays, 35 hearts, 5 rockets and 11 eyes should be counted additional) to be re-inspected and at least get an up-to-date comment from the UX team?
Is there a way to get a file uri or get to the TextEditor from a tab?
tab.input.kind.uri for certain classes of tabs.
For example, see https://code.visualstudio.com/api/references/vscode-api#TabInputText