Xi-editor: [RFC] Implementing split windows

[cmyr]

After tabs, split windows is a possible next major UI feature that we likely want to have, at some point, and figuring out how they are going to fit into the overall ownership model is something that we might want to hash out sooner rather than later.

Before getting too excited, I can see a few different ways splits could done;

1. we could go Xcode style, and simply allow for a single optional vertical split. Relatively simple to implement, but not super flexible.

2. we could go more in the style of a terminal multiplexer/vim, and basically allow any existing view to be split into two. This is trickier to implement in the front end, but not terribly so (at least in terms of programatically laying out the views)

3. we could not support splits.

Something I'm much less clear on is how this will work architecturally. Currently an editor view is owned by a view controller object, and is backed by a subclass of NSDocument. That document is responsible for creating the logical window into which that view is drawn. With tabs, documents maintain individual logical windows where are swapped in and out as tabs are swapped; each tab is considered a window. With splits, this breaks down a little bit, because a single window can contain multiple editors, but each editor's document expects to own its own window....

I haven't gone too deep down this path yet, and I suspect this won't be too tricky, but doing it well will involve some selective subclassing of NSDocument and NSWindowController.

I'm going to play around with this at some point, and if I'm making any progress I'll put up a WIP PR.

Does anyone have any thoughts on this? Should the backend be aware of split relationships?

[chriskrycho]

Input as a would-be user: I make very heavy use of multiple split panes. One of my most common use cases is developing [Ember] and other such frameworks, in which contexts it's extremely common to want to be able to see the JS implementation, the Handlebars template, the corresponding SASS file, and the test JS file all at once—those certainly wouldn't all go side-by-side comfortably even on my 5k screen; the fact that Atom and Sublime both support basically arbitrary splitting is a big selling point of both in the GUI text editors space for me. It's something I got used to in Vim and Emacs land and have wanted ever since. It's therefore also one of the bigger annoyances for me in the current version of VS Code, which does not support arbitrary splits.

[AljoschaMeyer]

Can anyone elaborate on what the core's current model of buffers and views is? Vim has buffers, windows and tabs, emacs has buffers, windows and frames, atom has buffers, panes, and tabs via a (default) package, and so on. Xi has buffers and tabs, although I could not find clear documentation on the exact role of tabs.

To play devil's advocate: If your editor has to provide split panes, then your window manager is not powerful enough. This sort of behaviour should not be duplicated (in slightly different ways of course) by every application. The editor should allow editing the same buffer from multiple windows, everything else is in the responsibility of the window manager.

This is, of course, completely unrealistic. But it should be kept in mind that most editors end up reimplementing a custom window manager. And a file manager. And a small operating system.

[cmyr]

@AljoschaMeyer as far as I'm aware (I've splunked in core but haven't contributed) the core's main concern is with a 'tab', which is (afaict) an editable view onto a file. I haven't played around with having the same file open in multiple viewports, and this isn't currently possible in the macOS frontend due to a nice helpful NSDocument behaviour that just brings your existing window to the front if you try to open a file twice.

From what I can see in the backend shared buffers may not currently be supported, but I think it's reasonable to expect them _eventually_ (@raphlinus can correct me if I'm wrong.) In any case, I'm happy to start some design-thinking from some assumptions, and revise them as we go along.

I appreciate your later point, but I think you're forgetting one of the main advantages of Xi; the small operating system can be implemented as a plugin, and all your system calls are non-blocking. 😉

[raphlinus]

There currently exists a distinction between View and Editor, but the plumbing to support multiple Views from a single Editor is not wired. It's something I'd like to have, though.

Bringing the window to the front is the right behavior when opening an existing file (before the recent NSDocument changes, it would just open two different copies, so changes made to both would clobber each other). But having a "New View into File" option is a good thing.

I don't think the core needs to be aware of whether the individual views are in windows, tabs, or split panes; this seems like entirely a UI concern. But if someone can make a case why the core needs to know, I'd like to hear it.

[portstrom]

This issue describes the frontend, not the core. To rephrase it to be about the core: I think the only thing needed in the core is a command to clone a view. The cloned view shares the same buffer but has a different ID and an independent scroll position and set of carets. Potentially a possibility to wrap lines at different widths in different views of the same buffer, but I don't consider that necessary for the initial version.

[cmyr]

When this issue was created the core and the xi-mac frontend were in the same repo, which is a reasonable source of confusion. In any case I more or less agree with your assessment. Things like line-wrap are scoped to the view, not to the buffer, so if we allow multiple views per buffer you'd get that for free.