It seems a very tough (if not impossible?) problem describing the GUI/editor relationship in a generic and thin API, because of each one's many designs interacting with their usual interface. I would like to follow a project attempting it though!
What do you mean by “being full access”?
In general I just meant that the GUI would attempt to reduce assumptions and be as flexible as possible. Ie, I would want to be able to control multiple cursors. Control multiple highlights. etc
Bonus points if it provided various events to trigger built in IDE features like auto complete popups, debug breakpoints, file panes, etc.
Fwiw, I don't think a "generic" interface is ideal. Perhaps for basic editor tasks, but when writing a kak<->sublime (fake example), I think it's acceptable to write it specifically for sublime. Having that binding be interchangeable between sublime, atom, xi, etc seems overreaching with little to gain.
Though, to a degree a subset of general commands which all editors support would be really handy. Similar to the Language Server Protocol, if Sublime implemented the fake "Editor Server Protocol" it would allow Sublime to instantly support Kak, Vim, Nano, etc. ESP extensions for Sublime, VisualStudio/etc would provide full functionality without affecting the ESP Core.
Hmm, this is neat. Perhaps a bit lofty, I just want a nice GUI for Kakoune hah.
(separating the engine from the GUI)