Synchronous Core, Async Shell

[CalebLarsen]

tl;dr Should we separate the editor into an outer async shell with a synchronous core?

While working on some tests for Editor I kept thinking that it would be much easier to test internal operations (editing, selections, movement) if there was a separation from external operations (highlighting, version control, LSP, file system, rendering). This inner editor could be synchronous (if I'm not mistaken) but would be imperative with operations modifying its documents. Then, an outer editor (Application?) would manage these external operations and call the appropriate functions on the editor.

The benefits would be a separation of concerns (in-process vs external), make testing in-process editing far simpler and faster, and allow the Editor structure to be broken up and be smaller.

Drawbacks include another nested layer of structs (arguably increasing complexity), the possibility in adding bugs in the restructuring, and the adage "if it ain't broke, don't fix it."

This would be a sizable architectural shift and require significant design and implementation work. I believe that the resulting code would be better laid out and the resulting ease of testing would allow for a stronger core to the system.

Design questions:

• What do we do about commands?
  • normal commands that get just the editor and async commands that get the full context?
• What do we call the "inner" and "outer" editors?
  • I've clearly struggled with naming in this post
  • Editor, Application?
• Should this wait for the helix-term/view rewrite? Should this be done at all?

[archseer]

That's what the intent of helix-core was. The primitives are synchronous and easy to unit test.

[CalebLarsen]

I agree with having a functional, synchronous core at the heart of things.
My question is, do you believe there is value in having another split, with a synchronous, imperative Editor (calls helix-core functions) wrapped in an async, imperative Application (manages LSP, etc. and calls Editor)?