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

31–40 of 105 posts

Re: Neovim's Next Feature Poll

#31

Post by dasil003 »

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…

I don't want a product that moves fast and breaks things, but I also don't want to carry the baggage of legacy support for strict vi-mode and whatever else ungodly edge cases vim continues to support.

What I'd rather see is vim with deprecations and upgrades on a reasonably timed roadmap. It's obviously a lot more work to maintain a 7.x branch, 8.x branch etc, but this is much more sustainable and meets everyone's needs better than saying "fuck it I just want Sublime with better vim bindings". An editor is not something where I want to chase the flavor of the month and deal with constant plugin breakages, but neither is it something where I want to be stuck in the 90s forever. There has to be a middle ground.

For the time being Bram's approach has earned my trust, and Neovim has to demonstrate many years of good project management and momentum before I will really be willing to trust it.

Re: Neovim's Next Feature Poll

#32

Post by MetaCosm »

exDM69 wrote: post #30
MetaCosm wrote: post #25

Earlier quoted context omitted.

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…

The Neovim development path -- by design -- had no chance of upstream-downstream merges. It is a departure, not a premature mistake, but a decision.

The code had to be re-factored to let the community in -- the Vim code is a horrific legacy cruft-fest that terrifies even the most brave developers. But it is a historical working one, which is hard to argue with -- look at those styling commits, they are wonderfully sane.

Re: Neovim's Next Feature Poll

#33

Post by MetaCosm »

dasil003 wrote: post #31
MetaCosm wrote: post #25

Earlier quoted context omitted.

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…

I don't want a product that moves fast and breaks things, but I also don't want to carry the baggage of legacy support for strict vi-mode and whatever else ungodly edge cases vim continues to support. What I'd rather see is vim with deprecations and upgrades on a reasonably timed roadmap. It's obviously a lot more work to maintain a 7.x branch, 8.x branch etc, but this is much more sustainable and meets everyone's ne…

Those ungodly edge cases are what makes vim usable everywhere, and the default of the defaults on so many systems. That trusty vi command that works a certain way has been dependable since the late 1970s.

But, that misses the point of Neovim a bit -- Neovim is about letting the community in (with all the good, and bad that comes with that). I suspect most people won't shift over to Neovim until either (1) They want to actually contribute something and find Vim proper far too daunting, or (2) because of the entirely new plugin model, some amazing plugin is only available on Neovim and it drags them over from Vim.

The Neovim plan seems to be "in months to gain momentum, in years to gain trust" -- which is really the only way you can do it.

Re: Neovim's Next Feature Poll

#34

Post by [deleted] »

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…

[deleted]

Re: Neovim's Next Feature Poll

#35

Post by chroma »

I am convinced that Vim's greatest asset and risk is Bram Moolenar. Bram is a talented, experienced developer, and I commend him for creating Vim. But he is the only person with write access to Vim's codebase. The primary author of NeoVim is Thiago de Arruda. Thiago tried to work with Bram, but was rejected.[1] Patches similar to Thiago's have been proposed before, but were also rejected.[2] It is for this reason that Thiago has forked Vim, and I wish him luck.

It's important to remember that everyone involved is trying to improve Vim as they see it. I think this is a prime example of how the benevolent dictatorship model can fail.

1. https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ

2. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

Re: Neovim's Next Feature Poll

#36

Post by edanm »

Please, please implement multi-cursor support. For anyone that doesn't agree, please read my previous post on HN on the topic: https://news.ycombinator.com/item?id=1625382

I wrote to Thiago about this already, but we don't even need multi-cursor support - just a few additional hooks so we can implement a multi-cursor plugin.

Although to be honest, making it part of core is vastly preferable, since it is a hard feature to get right (e.g., how do you deal with copy-pasting into multiple-cursors)?

Re: Neovim's Next Feature Poll

#37

Post by jeremyjh »

deckiedan wrote: post #28
martius wrote: post #12

Earlier quoted context omitted.

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…

It's later in the roadmap but Neovim will also run as a headless slave for use in new GUI applications.

Re: Neovim's Next Feature Poll

#38

Post by hk__2 »

edanm wrote: post #36

Please, please implement multi-cursor support. For anyone that doesn't agree, please read my previous post on HN on the topic: https://news.ycombinator.com/item?id=1625382 I wrote to Thiago about this already, but we don't even need multi-cursor support - just a few additional hooks so we can implement a multi-cursor plugin. Although to be honest, making it part of core is vastly preferable, since it is a hard featur…

What problems can you solve with multi-cursors that you can’t with actual features like block selection?

Re: Neovim's Next Feature Poll

#39

Post by metrix »

gitaarik wrote: post #22
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.

It seems to be in a working state, and loads VERY fast. But I haven't tried modifying the nvimrc or use plugins.

Re: Neovim's Next Feature Poll

#40

Post by weaksauce »

hk__2 wrote: post #38
edanm wrote: post #36

Please, please implement multi-cursor support. For anyone that doesn't agree, please read my previous post on HN on the topic: https://news.ycombinator.com/item?id=1625382 I wrote to Thiago about this already, but we don't even need multi-cursor support - just a few additional hooks so we can implement a multi-cursor plugin. Although to be honest, making it part of core is vastly preferable, since it is a hard featur…

What problems can you solve with multi-cursors that you can’t with actual features like block selection?

Editing the same thing in different places at the same time.
Post reply on HN