Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neovim's Next Feature Poll

neovim.org

Post reply on HN
Print view View original

21–30 of 105 posts

Re: Neovim's Next Feature Poll

#21

Post by CyberMuz »

dasil003 wrote: post #19

Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds? The reason I ask is because one of the primary reasons I made the switch to Vim from TextMate is ubiquity and longevity. In the age of GitHub, fads, forks and abandoned projects have become all too common. Meanwhile Bram has proven himself to be a pillar-like benevolent dictator for decades, and to me that means a hell o…

He is not very enthusiastic about it. Here is his comment about Neovim from two months ago. I don't know if he changed his mind in the meantime. https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

Re: Neovim's Next Feature Poll

#22

Post by gitaarik »

seren wrote: post #3

Has anyone used neovim yet ? Is it usable ? Is there any new features or are they only refactoring under the hood ?

I tried it. For now it just behaves the same as normal Vim. Most of the work done is indeed under the hood. They are refactoring the codebase so that it will be easier to create plugins, extentions and to use Neovim inside other apps.

Re: Neovim's Next Feature Poll

#23

Post by aidos »

dasil003 wrote: post #19

Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds? The reason I ask is because one of the primary reasons I made the switch to Vim from TextMate is ubiquity and longevity. In the age of GitHub, fads, forks and abandoned projects have become all too common. Meanwhile Bram has proven himself to be a pillar-like benevolent dictator for decades, and to me that means a hell o…

I've only seen his original post on it [0] - not sure if anything had changed since then.

For selfish reasons I'm behind neovim but I can see that it puts Bram in a bad position, which is unfortunate. He's done so much work for all of us (vim users), and ultimately this project just adds to the work he has to do (and makes it even more thankless). He'll be dealing with incompatibility issues between plugins trying to support both systems.

Ultimately, I guess he'll have to make a choice as to which codebase to support, by choosing neovim he's deserting everyone on esoteric systems. I think that may be the best outcome; Neovim becomes the new standard, Bram switches over and leaves vim to die. But then what control does he have?

It's one of those situations, it seems like a good idea, and could be a massive net win. Then again, it could also really destroy the project.

[0] https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

Re: Neovim's Next Feature Poll

#24

Post by kleim »

kachnuv_ocasek wrote: post #16
SeoxyS wrote: post #7

How could they make a sublime-style code minimap in a CLI app?

The goal (as I understood it) is to separate back-end and front-end. That is, you could have a CLI front-end with just text interface, or a GUI front-end with all the fancy features.

Maybe I didn't get the point of neovim but I don't really see how a GUI could be a useful addition for vim. I only use gvim because colorschemes have nicer colors.

Re: Neovim's Next Feature Poll

#25

Post by MetaCosm »

dasil003 wrote: post #19

Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds? The reason I ask is because one of the primary reasons I made the switch to Vim from TextMate is ubiquity and longevity. In the age of GitHub, fads, forks and abandoned projects have become all too common. Meanwhile Bram has proven himself to be a pillar-like benevolent dictator for decades, and to me that means a hell o…

Bram has said very little. He, IMHO, massively underestimates the communities desire to contribute... Neovim simply tapped in to a community desperate to improve a project they love, and finding no good options on howto do so.

As for "getting behind it if it succeeds" lets hope not! I was a financial supporter of Neovim. I also have run the #vim channel on FreeNode for over a decade. They serve different goals.

Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome.

Vim is -- the default on many systems, shipped with fully working vi compatible mode, has literally millions and millions of users. It can not -- by its nature -- move fast and break shit. Vim has a much, older, slower development process -- from the days well before Github and friends... it might slowly open up -- but not much, because again, millions depend on it. This is also, awesome.

I hope the very best ideas, once they are tested, debugged, and tested again will make their way up from Neovim to Vim, but it will be a very slow process. Neovim gives no thought to Vim -- because it can't -- it has to be its own thing to move forward. Vim gives no thought to Neovim yet -- it is an established, dependable, amazing tool... and Neovim has not yet risen to the point to even be worthy of a response.

Re: Neovim's Next Feature Poll

#26

Post by mikaelj »

bpierre wrote: post #20
dasil003 wrote: post #19

Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds? The reason I ask is because one of the primary reasons I made the switch to Vim from TextMate is ubiquity and longevity. In the age of GitHub, fads, forks and abandoned projects have become all too common. Meanwhile Bram has proven himself to be a pillar-like benevolent dictator for decades, and to me that means a hell o…

Quoting his answer [1] in the vim_dev mailing list: It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly? Total refactoring is not a solution. It's much better to improve what we have. Perhaps with some small refactorings specifically aimed at making Vim work better for users. [1] https://groups.google.com/d/msg…

The refactorings thus far have been specifically aimed at making Neovim work better for /developers/. Which in turn will make it better for the users.

A very good way of thinking.

Re: Neovim's Next Feature Poll

#27

Post by kansface »

threatofrain wrote: post #8

I've heard from a HN commentator that Neovim has given up on its principle goal of refactoring, and that progress has largely been due to uncrustify. Can anyone else speak to the health of the project?

Have a look for yourself: https://github.com/neovim/neovim/commits/master.

The code base is now about half of the original size (removed support for legacy OSes, swap all native IO abstractions for libuv, removed dead code, etc). They also split the 25Kloc files called things like misc2.c into multiple files and neovim uses cmake instead of a slew of hand written make files with two decades of commented out hacks. Work on a vimscript -> lua compiler (https://github.com/neovim/neovim/pull/243) is underway as well as the new RPC plugin stuff (https://github.com/neovim/neovim/pull/582).

Re: Neovim's Next Feature Poll

#28

Post by deckiedan »

martius wrote: post #12
SeoxyS wrote: post #7

How could they make a sublime-style code minimap in a CLI app?

They are willing to make it more like gvim, running in a separate window, and one of targets of neovim is to use a modern graphics backend to achieve that.

Nonsense, mate.

https://groups.google.com/forum/#!topic/neovim/hTPKGGzwWKA

neovim is sticking with the standard fixed terminal as the 'main interface', but is building a better/easier way to communicate with external processes. That way a non-terminal Vim plugin can open up extra windows for minimaps, etc.

Ideally, this would mean you could have a vim "server" (for lack of a better term) on your dev VM, or where-ever, and local "client" windows on your actual workstation which displays beautiful helptexts, minimaps, code trees, etc.

Re: Neovim's Next Feature Poll

#29

Post by mseidl »

kleim wrote: post #24
kachnuv_ocasek wrote: post #16

Earlier quoted context omitted.

The goal (as I understood it) is to separate back-end and front-end. That is, you could have a CLI front-end with just text interface, or a GUI front-end with all the fancy features.

Maybe I didn't get the point of neovim but I don't really see how a GUI could be a useful addition for vim. I only use gvim because colorschemes have nicer colors.

You can use CSExact to get GUI color schemes to work.

https://github.com/KevinGoodsell/vim-csexact

There is also csapprox.

Re: Neovim's Next Feature Poll

#30

Post by exDM69 »

MetaCosm wrote: post #25
dasil003 wrote: post #19

Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds? The reason I ask is because one of the primary reasons I made the switch to Vim from TextMate is ubiquity and longevity. In the age of GitHub, fads, forks and abandoned projects have become all too common. Meanwhile Bram has proven himself to be a pillar-like benevolent dictator for decades, and to me that means a hell o…

Bram has said very little. He, IMHO, massively underestimates the communities desire to contribute... Neovim simply tapped in to a community desperate to improve a project they love, and finding no good options on howto do so. As for "getting behind it if it succeeds" lets hope not! I was a financial supporter of Neovim. I also have run the #vim channel on FreeNode for over a decade. They serve different goals. Neovi…

> Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome.

The first thing done to Neovim was to re-format all the code and then do some refactoring that breaks things. You can't make an omelette without breaking eggs but this practically burned the bridges behind and any hope of merging stuff upstream/downstream from neovim to vim or vice versa is gone. At least without significant manual labor.

If you ask me, this was a premature move and the neovim guys should have tried to make non-breaking changes first with an opportunity for upstream-downstream merges.

Post reply on HN