4 ms·

I strongly agree with the sentiment. It would be wonderful to be able to plug GUIs on top of an editor of your choice (kak, (neo)vim, emacs, nano, sublime, note

I strongly agree with the sentiment. It would be wonderful to be able to plug GUIs on top of an editor of your choice (kak, (neo)vim, emacs, nano, sublime, notepad++). 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”?

pier25 8y ago
Isn't that what Google is making with XiEditor? (separating the engine from the GUI) https://github.com/google/xi-editor https://github.com/google/xi-editor
- adrianN 8y ago
  Separating the engine from the gui is also were Neovim is headed.
notheguyouthink 8y ago
> 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.

pier25 8y ago

Isn't that what Google is making with XiEditor? (separating the engine from the GUI) https://github.com/google/xi-editor https://github.com/google/xi-editor

adrianN 8y ago
Separating the engine from the gui is also were Neovim is headed.

notheguyouthink 8y ago

> 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.