Hacker News Reader

Comment by notheguyouthink | Hacker News Reader

On this note, do any of these nice GUI editors provide a good API for control of the buffer contents, multiple cursor positions, multiple highlights, etc?

I'd love to experiment with various editing models but hate the idea of implementing the entire GUI layer. Also I'm dying for a pretty GUI for Kakoune (my editor of choice).

I'd pay hundreds for this honestly. Maybe I'm too niche for it to matter, but I feel like these companies putting so much work into their editors are not fully utilizing the effort they put into it.

Ie, many don't want to switch from Vim, but if we could take a really well polished and established editor like TextMate and make it the GUI for Vim? Well that's just amazing. I'd buy it hands down, for quite a lot. It would need to be full access though, and not explicitly tied to (Neo)Vim.

View on HN

As far as I know Atom provides an all-you-can-eat-buffet of extensibility. I don't think there's many other editors that offer that, as far as GUI editors are concerned.

Maybe Textadept also offers what you want? https://foicica.com/textadept/

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”?

Isn't that what Google is making with XiEditor?

(separating the engine from the GUI)

https://github.com/google/xi-editor

Separating the engine from the gui is also were Neovim is headed.

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

There's jEdit.

It looks horrible out of the box, but it looks as good, if not better than most modern editors.

It runs on the jvm and so is sluggish to launch, but it's an extremely mature product and the plugin ecosystem is nice. Getting the latest plugins is a bit hit or miss, but it's worked great for me and my colleagues.

Font rendering is awesome and has support for ligatures etc.

Reply on news.ycombinator.com