Vim 8.0 Will See GTK3 Support, Async I/O, Jobs & More

[Goddard]

I personally use NeoVim.

[liam]

I wonder if people use vim or the gvim front-end more?

Also now with async things in Vim 8.0 what happens to NeoVim?

Btw, does Emacs have any GTK frontend?

Off-topic: Lately I've been using Atom.

I've moved to atom as well. It's pretty damn fantastic, and I've not had any performance issues (I mention this b/c this is an oft cited reason for using vim).

BTW, presumably that should be "Async" I/O since linux doesn't have asynchronous sockets?

PS: Sometimes I really hate how stubborn the kernel developers are.

[e_tank]

i tend to use neovim in the terminal and gvim when i want the gui for convenience. i really wish someone would produce a good, preferably gtk, gui frontend to neovim already. its been a while since i last tried neovim-qt, but i remember it lacking any of the features you'd expect, it was essentially just neovim running in a qt window and that's all.

another editor i really like is ne (the nice editor), it's a console editor that's vastly superior to nano in terms of both capability and ease of use, plus its got a similarly well organized nice and simple codebase to boot. it has a few quirks that could/should be fixed, but other than that i find it a damn shame that it hasn't replaced nano as the default console text editor in any distros

[wizard69]

I wonder if people use vim or the gvim front-end more?

I've been using MacVim on and off.

Also now with async things in Vim 8.0 what happens to NeoVim?

Neovim? Never heard of it but it likely will suffer the same fate as other forks.

Btw, does Emacs have any GTK frontend?

Off-topic: Lately I've been using Atom.

[gilboa]

BTW, presumably that should be "Async" I/O since linux doesn't have asynchronous sockets?
PS: Sometimes I really hate how stubborn the kernel developers are.

Say WHAT?
fcntl(socket,F_SETFL,O_NONBLOCK)

Per subject at hand, I appreciate the effort to port gvim to a modern gtk 3.0. While gvim is rock solid, it beginning to look out-of-place in modern KDE 5/Plasma 2 desktop.
I'd also hope the job and inter-process improvements will make it easier to integrate gvim and gdb.

- Gilboa

[liam]

Say WHAT?
fcntl(socket,F_SETFL,O_NONBLOCK)

Per subject at hand, I appreciate the effort to port gvim to a modern gtk 3.0. While gvim is rock solid, it beginning to look out-of-place in modern KDE 5/Plasma 2 desktop.
I'd also hope the job and inter-process improvements will make it easier to integrate gvim and gdb.

- Gilboa

I said asynchronous not nonblocking.

[gilboa]

I said asynchronous not nonblocking.

Sorry, my mistake.
Though, I can't say that I see much use in pure-async-socket support. (aio, even in Windows, was designed with slow-spinning disks in mind).
Far easier (and cheaper) to setup a single listening non-blocking thread that handles multiple connections via poll/select.

If I'm wrong please enlighten me.

[liam]

Sorry, my mistake.
Though, I can't say that I see much use in pure-async-socket support. (aio, even in Windows, was designed with slow-spinning disks in mind).
Far easier (and cheaper) to setup a single listening non-blocking thread that handles multiple connections via poll/select.

If I'm wrong please enlighten me.

All of this is aiui.
Epoll can be nearly as performant as iocp, for instance, but it has a couple drawbacks: it can be harder for the developer (they can say what it is they want and the kernel doesn't callback until they have all of it...a good deal of this is due to the .NET runtime) and it's less efficient (there's more overhead with an epoll multiplexing.... polling and data structures).

[gilboa]

All of this is aiui.
Epoll can be nearly as performant as iocp, for instance, but it has a couple drawbacks: it can be harder for the developer (they can say what it is they want and the kernel doesn't callback until they have all of it...a good deal of this is due to the .NET runtime) and it's less efficient (there's more overhead with an epoll multiplexing.... polling and data structures).

A couple of years ago I was hired to port a IOCP heavy server to Linux.
As I'm cheap-ass, I developed a simple thread pool + select (for some odd reason I didn't want to use epoll).
The number of connections per thread was configurable, but we usually kept it 10-20.
Needless to say the Linux solution was *far* leaner than the Windows one (At least under Win2K3 IOCP was far-from-cheap).

Of-course, given the fact that we are talking about vim here, I doubt that it would matter either way.

[liam]

A couple of years ago I was hired to port a IOCP heavy server to Linux.
As I'm cheap-ass, I developed a simple thread pool + select (for some odd reason I didn't want to use epoll).
The number of connections per thread was configurable, but we usually kept it 10-20.
Needless to say the Linux solution was *far* leaner than the Windows one (At least under Win2K3 IOCP was far-from-cheap).

Of-course, given the fact that we are talking about vim here, I doubt that it would matter either way.

So, these aren't the resources I was looking for but:

https://www.slideshare.net/mobile/sm9kr/iocp-vs-epoll-perfor

http://tinyclouds.org/iocp-links.html

Clearly Linux can achieve similar results but without asynchronous sockets we won't have both the nice semantics (and unified treatment of FDs, though eventfd certainly can be employed to achieve some of the same effects) and performance.
It's really too bad that the kernel posix aio error just died, and the remaining work in kernel aio seems mostly interested in fixing bugs.
Really, I bemoan the fact that Linux developed a available event multiplexer than any of the other major kernels but, instead of creating an elegant solution that works for everything (yes, it's hard, but its been done) they prioritised backwards compatibility. In general I'm not happy that the kernel devs haven't added some long needed features because they are hard to do.