Separation of Core and UI

[critiqjo]

Assumptions: Single window, single file

Concerns of Core

• Buffer (text) management
• Typesetting (constrained to a viewport dimensions RxC)
• Command handling
  • Key-mappings
  • Cursor movements etc.

    Concerns of UI

• Drawing (of course)
• Keyboard and mouse events handling
• Syntax highlighting (incl. parsing)

  Inputs to Core

• Stream of keys (w/ modifiers)
• Viewport dimensions (and changes)

  Outputs from Core

• File/buffer metadata (current)
• Row-wise:
  • String of characters (exposed as an iterator or a list of slices?)
  • Line number (and starting offset)
• Cursor info
  • Primary cursor position/range (w.r.t viewport, file, and line)
  • Other visible cursor positions/ranges (w.r.t viewport)
  • Number of cursors
• Raw (mmap-ed) buffer access interface? (for syntax highlighting, maybe)
• Command line invocation (: or /) (optionally overridable by UI)

  Unresolved

• Threadsafety if raw buffer is exposed
  • The LRE piece can get modified in-place
• Multiple window handling
  • Coordination between 2 event loops?

    Low-level details

    Core API

TODO

[critiqjo]

@martanne I'm ready to work on this during the coming June. What are your thoughts? If you don't have any plans to separate the UI out, then do mention and close this issue...

[critiqjo]

Although I'd say that before attempting this, a proper test suite have to be ready.

[martanne]

What are your thoughts?

I think the current code base is already mostly structured that way, I certainly tried to keep separate things separate. vis.h specifies a "high level" editor interface, view.[ch] is your viewport, ui.h defines an abstract interface currently implemented by one concrete backend ui-curses.[ch].

There certainly exist some warts. A general ui should not directly have to depend on libtermkey (as is currently the case). Also the rendering code in view.[ch] has become somewhat of a mess and is quite limited. Basically you can only specify a starting position from which it will render text content until the available space is filled up. There is currently no way to display/attach arbitrary data (such as compiler error messages) inline. Also the displayed text has to be contiguous i.e. no support for folds etc (not that I miss them, but they should in principle be possible). The Lua based syntax coloring should also be moved out of it, view.[ch] should not depend on Lua. It should be possible to run multiple lexers (e.g. a language specific one followed by one highlighting trailing white spaces etc) on the same view.

Feel free to improve it. While I personally don't have an interest in alternative GUIs, trying to add an EFL (or GTK) based UI would surely highlight some more deficits of the current architecture. Also the necessary integration into a proper main loop could prove to be useful for async I/O related activities.

Also the most interesting section of your post, the "Core API" is marked as TODO ...

[critiqjo]

I think the current code base is already mostly structured that way

Great!! :+1:

While I personally don't have an interest in alternative GUIs

Neither do I, but that may be because I haven't found one that integrates with terminals the way I would like.

"Core API" is marked as TODO ...

That needs a lot of thinking. I'm getting a few ideas but it doesn't seem general enough (considering that it should work across languages). For single-file single-view part may not be that hard, but we'll have to support multiple files & windows at some level. If the design fundamentally cannot accommodate inter-widow interactions (same-file-multi-views, diff-mode, locked-scrolling etc.), then it would be a lot of pain to change it in future.

One major thing I noticed is that the pieces are presented as a linked list. I loved the design, but linked lists are not a great choice when you consider sharing access. I've been thinking about writing a CoW Binary tree with some specific properties to keep track of line numbers. But I would be a madman to try making it in C (it would literally take years to make it memory&thread-safe). I'm referring to Rust, of course. And thinking further, I'm actually interested in rewriting this in Rust (which would actually make me a madman!)...

[mcepl]

OK, what is this ticket good for? Does anybody work towards it?