one more refactor? (NSDocument reconsiderations)

[cmyr]

Should we ultimately be using the NSDocument Architecture?

Whether or not it was a good fit has come up various times, e.g xi-editor/xi-editor#88 (comment) & xi-editor/xi-editor#171 (comment). My initial motivation for merging the NSDocument changes was the built in support for tabbing, and my preference for moving more of the model logic out of the EditView, and introducing a per-document controller class.

I like those changes.

The NSDocument model has a few problems though: one of the most pressing of these is that it tightly couples a document to an individual window, and its tabbing model is on a per-document basis. This means that implementing split views, where we have multiple buffers open in a given window, will necessarily be a hack.

Similarly, the API around interacting with the file system does not represent how xi actually functions, where all file system interactions are the responsibility of ``xi-core`. If we're going to want to be doing our own window management and we're already handling file system interactions, the arguments in favour of NSDocument are starting to look a little threadbare.

That said, the overall architecture of the NSDocument model—that is, of having a singleton which is responsible for managing a collection of document/buffers—feels to me like an appropriate abstraction. If I were to move away from NSDocument then my replacement would probably keep that overall structure.

How I would imagine that replacement, in loose term:

• rename Document to something like CoreProxyBuffer, no longer a subclass of NSDocument. This class will be explicitly responsible for the various 'edit' RPC commands, as well as for maintaining the line cache.
• Add a new class which will serve the role currently performed by the NSDocumentController, that is of managing open / close / new / other editor-global commands, (currently in the app delegate) as well as (perhaps) things like window state restore on launch.
• Add some subclass of NSWindowController, which will handle tabbing and splits, and
• keep everything else more or less as-is, with the EditViewController still being responsible for the display of a given buffer, etc.
• manually implement various open/close/save/tabbing functionality.

When this is done, I can go ahead and implement splits.

Are there any other thoughts/concerns here? One thing I think would be a responsible step would be to see exactly how hard hacking splits into NSDocument actually is.

[raphlinus]

This sounds fine to me. Note that having multiple views for a single editor buffer (each with its own cursor state) will require some changes to the core, but I'm ok with that.

[DivineDominion]

Just wanted to chime in and point out that you can have multiple windows per NSDocument using -addWindowController: