Xi-editor: Should xi-core have some concept of a 'workspace'?

[cmyr]

Thinking about a few things that might want to be aware of a 'project' scope, such as find+replace, and a quick-open panel. I think that the concept of the 'project/workspace', both implicitly (the parent directory of the current file, or the nearest parent that contains a vcs object) and explicitly (some user-specified collection of directories/files) is a very useful one. Is there a case for having this concept represented in the core in some capacity?

[jansol]

Yes please! However I'd also like to keep the possibility of just quickly opening a single file, doing some tweaks and closing it without having to deal with the whole workspace thing. It's always annoying in Atom: when I just want to tweak a lengthy C++ source file that I haven't looked at in a while (so can't remember enough of it to efficiently do the edits in vim) so I open it in Atom - which decides to also open my multi-file LaTeX project.

On the other hand, Find In Project (ripgrep integration anyone?), Refactor, Go To Definition are all very handy features which rely on having a concept of a project and I'd really want to have support for them in Xi.

Another question would be if projects should rather be implemented as a frontend feature. The above mentioned features could be implemented as operating on all open files and having the frontend open all files in the project under the hood. (although this has its own issues)

[AljoschaMeyer]

No please! Why should a program to manipulate plaintext files need to be aware of the context of the files it edits? If you need workspace-based functionality, use a plugin. Since there are multiple usecases for workspaces, there should be a plugin which simply manages them and provides an API for other plugins to hook into.

Perhaps there are performance gains to be had by making the core aware of workspaces - I don't know. But in my opinioin, that should only be an implementation detail. The abstract interface of utf-8 encoded string manipulation has nothing to to with workspaces.

[cmyr]

@jansol That sounds almost like a separate problem: the fact that atom is doing window state restoration on relaunch, so whatever you had open when you last ran it is now being reopened when it is launched to edit your new file? This seems like more of a UI consideration, which would be front-end dependent (although at some point I could imagine having a set of design guidelines for frontends, but that's a long way off). The main case I can think of for the workspace concept right now is providing consistent support for plugins, so I think it's in the core if its anywhere.

The features you list are definitely where my thinking comes from, here. In this sense I think @AljoschaMeyer is on the same page as well: the majority of this functionality would be implemented as plugins, the question is whether or not it would be useful to have a 'workplace context' that exists in core and can be passed to plugins. the language server protocol for instance uses the concept of a workspace quite heavily.

[AljoschaMeyer]

Since plugins need to communicate via IPC, they can easily expose APIs to each other. So technically there is no reason to provide the 'workplace context' from the core, rather than from a plugin.

Asynchronously interacting plugins could be very powerful, and can lead to more modular designs. A nice example of this is the atom linter package. Atom plugins can expose APIs to each other, and they can declare dependencies, so that required plugins can be installed automatically.

If there is a mindset where everyone treats their plugin as an isolated entity that only talks to the core, then having the core maintain a workspace context might make sense. I just strongly believe that modular, intercommunicating plugins make for a healthier ecosystem in the long run. And I hope that Xi does not create a self-fulfilling prophecy of isolated plugins, by putting too much behavior in the core, even though it could be provided by a plugin.

Aside: My intial strong reaction to workspaces came from too much time spent fighting Eclipse. Getting Eclipse to acknowledge that a file/directory exists, let alone to provide editor services like syntax highlighting, can be quite the experience...

[raphlinus]

My thinking here is of priorities. I think ultimately we probably will need something like a workspace in order to support the full functionality of Rust Language Server (and related). However, there's still a fair amount to be done on the single-file editing case, and I think we should focus on that first. That includes some important functionality in plugins - the ability to actually edit the text (to insert indentation and so on), annotations, etc.

At the very least, it sounds like plug-ins should be able to request opening a file and jumping to a point in it.

I haven't thought too carefully about whether workspace concepts need explicit support in the core or whether everything can be done through plug-ins. If the latter works, I'm quite open to it.

[jansol]

@AljoschaMeyer fair enough, I can see that solution working nicely. Such a workspace plugin could for example be temporarily disabled when launching the frontend with a single file as a parameter.

EDIT: I suppose one question is whether the core should support multiple simultaneous sessions for the same file, or "attaching" another frontend to a running workspace. In such a case it would make sense for the core to at least be aware of the workspace concept.

[cmyr]

@AljoschaMeyer good points, I should go spend a bit of time looking at the plugin story in atom / vscode.