Is it still a plan to move TextEditor to it's own package?


I think I read somewhere (sorry can’t find reference) that it was a goal to move TextEditor and related classes to there own package. I expect this would be post 1.0 now, but is this still an eventual goal?

I personally think this would be really useful. I think Atom core should just include a “Document” pane item class which implements and documents all the methods that the workspace calls when managing pane items. ‘getTitle’, getPath, save, saveAs, etc.

TextEditor (in the other package) would inherit from that. But other classes could too. It would make the whole process of defining a custom editor easier and able to use documented API.


I believe you’re thinking of the now abandoned text-document package. It was being used as a place to explore options for implementation of features for things like large file support. The best of it has already been pulled back into Atom core.


What I’m thinking about is different.

It was along the lines of: everything in Atom is packages … even the text editor is just a package that can be replaced like everything else.

I’m not so interested in replacing the text editor right now, but I am interested in getting as many text editor dependencies out of core Atom as possible. Right now there’s lots of undocumented convention between workspace, pane, and TextEditor. If TextEditor were moved to its own package that convention would need to be documented.

I’d like to eventually see “TextEditor” as just one of many equal editor types. And for that to happen I think it need to be moved out of core.


I feel documentation isn’t a good reason to pull things out of Atom Core. For example, almost nothing in Tree View is documented, yet it is an external package. The same goes for Status Bar (though I think it is a little better due to its use of the Services API). If documentation is what is desired, then lets just document it.


Yeah that would work too. The idea would be:

  1. Create a new Document class.

  2. Make TextEditor subclass Document.

  3. Move “generic” document management methods from TextEditor up into Document (and document them there).

For example right now has special handling in saveAs:

  saveItemAs: (item, nextAction) ->
    return unless item?.saveAs?

But it’s not clear when creating your own pane item that you need to implement that method to take part in the file save process. To resolve this saveAs would be moved up into the Document class and documented there.

Now for people who want to create a document style pane item (i.e. save’s loads, etc) would extend from Document and know all the methods that they need to override to get the desired behavior.