How to get EditorView from Editor?


I realize that there can be multiple EditorViews per Editor. So what I’m looking for is editor.getEditorViews(). My end goal is to remove the entire EditorView and corresponding pane, just knowing the editor.

Can Atom be a browser?

I don’t think thats possible. However you can go the other way round to achieve what you want:

getEditorViewsForEditor: (editor) ->
  results = []
  for editorView in atom.workspace.getEditorViews() 
    results.push editorView if editorView.getEditor() == editor

getEditorViewsForEditorShort: (editor) -> 
  editorView for editorView in atom.workspace.getEditorViews() when editorView.getEditor() == editor



I tried your function and got this error …

TypeError: Object #<Workspace> has no method 'getEditorViews'

I’m beginning to think Atom core goes out of it’s way to keep you from finding editorViews.

Is there any other idea to try?

Edit: Never mind, I found this …

for editorView in atom.workspaceView.getEditorViews()


Going forward, this will be easier. Although 98% of the time you should only ever need access to the Editor (aka. the model), but if you need access to the associated view, with the changes to the APIs, there will be functions on the various container modes along the lines of getViewForModel (the exact name escapes me, and I’m too lazy and tired to dig up the GitHub issue where it was discussed).


A related question. When you have an editor how do you show it (switch to its tab)?


You need to get the associated pane. One approach might be something like this following, untested snippet:

# ...
uri = editor.getUri()
if pane = atom.workspace.paneForUri(uri)

Please note, that the code in my snippet above will only activate the first matching pane. There might be multiple associated panes (unless the buffer URI is unique). If you need more control, you can iterate through all the panes via workspace::getPanes() and compare the pane’s associated “item” against your editor instance.


BTW, you were wrong about editorViews only being needed 2% of the time. Right now I need getFirstVisibleScreenRow and scrollToBufferPosition. Any time you are persisting things you need a lot of EditorView methods.


Many of the things currently in views, will be moved to models. Views should only be about manipulating the DOM. Whether it makes sense to move those specific functions to models, is not something I’m sure about, but not unlikely.

Views should only ever be concerned about presentation. Persistence is always the concern of models. The core team seems to want to move in that direction (based on API related discussions in a couple of GitHub issues).


Another related question: How do I find an editor based on a URI? I need to find the tab for a URI and open that tab.

This is so frustrating. How do I get all the URIs for all the tabs? EditorViews don’t even exist for unopened tabs. Do editors exist? I can’t use my usual method of finding editors using the DOM because the DOM doesn’t have them yet.

This whole editor/editorView area is not fun.

I’m probably missing something obvious. I’m a bit frustrated and probably not thinking correctly.


Wrong. Persisting presentation, scroll position, cursor position, etc. is quite valid. I’m trying to do that right now.


From the official API documentation:

This class represents all essential editing state for a single TextBuffer, including cursor and selection positions, folds, and soft wraps. If you’re manipulating the state of an editor, use this class. If you’re interested in the visual appearance of editors, use EditorView instead.


Yes, your can get cursor and selection positions, but not scroll position and other necessary things. To quote your quote …

. If you're interested in the visual appearance of editors, use EditorView instead.

I want to persist the visual appearance including the scroll. The docs can say whatever they want about intent, but I’m facing reality, not intent.

Edit: I guess a more reasonable way to put this is that too much is in the view that should be in the model. Sorry for my aggressive tone. I’m just frustrated.


Anyone have any ideas on this? Should I open a new thread?


I apologize. I missed this comment and you are absolutely right in this whole discussion. I just need to find workarounds until this happens.


I generally find that people get better help when they say what, in general, they’re trying to do. For example, rather than say something like, “I need to start a process when the file is getting ready to be saved and then finish it after it is written to disk.” One should say something like, “I need to know the file name of any file that is saved.” This is because people get bogged down in their assumed implementation and don’t give people the chance to help find the right way to do something.

So, @mark_hahn, what is it you’re trying to get done?


I’m writing a package that archives a file (editor contents and view) on every single save of every file. Then you can review the archives to find any old version of code. A key point of my app is to travel back in time so I want to take them back to the view they had when they saved.

  1. I need to save and restore the editing state. This means persisting view stuff.

  2. When the review key combination is pressed I need to open a second tab to view the past versions. If the tab already exists then I need to just switch to that tab instead of creating a new one. I’m having trouble finding editors for tabs with a certain uri.

I can handle item 1 with workarounds I’ve found. I am truly stuck on item 2. That is the thing I’m thinking of opening a new thread on.

Edit: I only have a problem finding editors when the tab has never been opened. That is when no DOM element for the editor exists yet.


For item 2, you could assign a URI to the “history” tab and then use the regular mechanisms to open URIs. atom.workspace.paneForUri can give you the pane that contains your tab, and Pane::itemForUri can give you the tab within that pane.

For example, for the file foo/bar/baz.c you could say that history://foo/bar/baz.c is the history tab. And you can register an opener for the history protocol that does what you need to do.


That sounds like something i should be doing. I’ll investigate it. Thanks.


I would hook into atom.workspaceView.eachEditorView and just keep a list of all editor views. You probably want to use their serialize functionality to save their state rather than trying to collect it yourself. If you keep a list of all the editor views, then you never have to try to go from the editor to the editor view. Remember, each editor can have more than one view associated with it too.

This is kind of what I mean … if it is hard to go one way but not the other, maybe you should just reformulate so you can go the easier way to solve the problem?


Hadn’t thought of using serialize. I can’t use the actual json because it isn’t compressed enough but I can pick out the vars I need.

My archive is extremely compressed. Data is stored in variable length bit fields. This engine is finished and the result works much better than I expected. The differencing and bit manipulation usually only takes a few ms even for large changes. You’d think bit handling in javascript would be slow but actually the opposite is true. Bit operations like AND and SHIFT are very fast. I ported a big C app to asm.js with emscripten. The resulting JS was half the speed of native C.