geekhack
geekhack Community => Other Geeky Stuff => Topic started by: hashbaz on Thu, 29 May 2014, 16:28:49
-
(https://raw.githubusercontent.com/neovim/neovim.github.io/master/logos/neovim-logo.png)
I just learned about the neovim (http://neovim.org/) project today, which is an "aggressive refactoring" of the vim codebase.
From the bountysource (https://www.bountysource.com/teams/neovim/fundraiser) and github (https://github.com/neovim/neovim) pages, the major goals/benefits are:
- First class support for embedding
- New plugin architecture and extensibility in any programming language
- Support for modern GUI front-ends, without modifications to the core
- Compatibility with existing vim plugins
- Simplification of maintenance that will encourage contributions
I've toyed with the idea for years of attempting a major rework/rewrite of vim, and I think it's desperately needed. I'm very glad to see a major effort underway to make it happen. Even if it fails, perhaps it will spin off other projects and/or kick Bram in the pants to think about modernizing the mainline.
Thoughts?
-
I've heard about it, but I'm not very optimistic. Vim is a huge codebase, with 30+ years of work put into it.
However, if they're not out to replace vim, but merely provide another text editor based on vim, then they might have a shot. I'll give it a shot if they support surround.vim (I can't live without it).
-
Using vim daily, I can't say that I have any real complaints. Having said that, it's rare occasion when a vim session will creep beyond 2 hours for me.
Something I wouldn't mind to see would be a more human friendly command structure for common tasks such as find and replace. We all know the sed syntax but c'mon man!!
I'm interested to hear your annoyances and what you were thinking of changing?
-
Mostly what interests me is the expansion of what plugins can do and how they can be created. Fast, asynchronous plugins in any language with access to vim's full internal data model and API will allow some sweet stuff. Cleaning up and modernizing the codebase will make for better extensions, lower the barrier to entry, and attract more devs. I would also love to see vim become seamlessly embeddable in other environments such as debuggers and IDEs.
I would like to see core development move forward eventually as well. Seems like vim development underwent a large spurt several years ago with the addition of tabs and folding, and has stagnated since. There is a new generation of innovative editors out there, and incorporating their advances into vim plugins has been difficult.
-
/me uses Emacs.
/me leaves thread.
-
Vim is a huge codebase, with 30+ years of work put into it.
If they're not out to replace vim, but merely provide another text editor based on vim, then they might have a shot.
This ^^^
A complete rework of a core program such as vim could be seen as anti-unix in some circles. In fact, they may suggest to get a mac. :) . Doesn't bother me one bit either way personally.
Mostly what interests me is the expansion of what plugins can do and how they can be created. Fast, asynchronous plugins in any language with access to vim's full internal data model and API will allow some sweet stuff. Cleaning up and modernizing the codebase will make for better extensions, lower the barrier to entry, and attract more devs. I would also love to see vim become seamlessly embeddable in other environments such as debuggers and IDEs.
I would like to see core development move forward eventually as well. Seems like vim development underwent a large spurt several years ago with the addition of tabs and folding, and has stagnated since. There is a new generation of innovative editors out there, and incorporating their advances into vim plugins has been difficult.
Having drop in plugins would that are easy to build would be great and ahhhhh, isn't folding great?
The biggest struggle I believe will be attracting enough of an audience to achieve proper dev attention. I imagine that a younger generation would automatically cast vim aside as other editors are available and have smaller learning curves. There are essences of youth from VIM like the chrome plugin that may be able to create sparks of interest but it may be futile.
You just might have to write it up yourself afterall :D
-
I think the goal is to win over existing vim users, not create a new vim-ish editor that will attract new users. If the project achieves its goals of increased performance and compatibility with existing plugins, and improved/asynchronous API, the plugin development community will have a compelling reason to embrace it. And if they embrace it I can see a significant portion of the userbase embracing it too.
Again, it's all about the plugins.
-
New plugin architecture and extensibility in any programming language
this is huge.
is it backwards compatible with vimscript garbage though?
-
They're talking about writing a compatibility layer that compiles vimscript into lua to maintain compatibility with existing plugins. Not sure about existing plugins that are written in Python, Ruby, and friends.
-
any programming language? really? That's a bit ambitious.
Can I write extensions in ocaml? cobol? whitespace? BRAIN****? HUH CAN I?!?!?
-
I believe the plan is that plugins will run in separate processes and communicate with neovim through an IPC protocol. So yeah, as long as brain**** has a sockets library you should be good to go.
-
I believe the plan is that plugins will run in separate processes and communicate with neovim through an IPC protocol. So yeah, as long as brain**** has a sockets library you should be good to go.
Ok, that's friggin cool