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

Bram Moolenaar responds to Neovim

groups.google.com

Post reply on HN
Print view View original

101–110 of 151 posts

Re: Bram Moolenaar responds to Neovim

#101

Post by ramgorur »

Jare wrote: post #28
sramsay wrote: post #2

Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.

When we started work on Commandos 2, we threw away everything from Commandos 1, and started from scratch. 15 years down the road, all the coders still agree that was the best decision ever.

When I hear "Commandos" it makes me nostalgic :-(, but kudos to you and your team !!

Re: Bram Moolenaar responds to Neovim

#103

Post by maxk42 »

dylnclrk wrote: post #25

Was Vim a complete rewrite of Vi?

Lots of things were a complete rewrite of vi. Vi was a complete rewrite of ex. ex was a rewrite of em, which was in turn a rewrite of ed, which was a rewrite of qed.

Trying to rewrite vim is the wrong approach. Trying to replace it in a backward-compatible way, the way vim did to vi might received a lot better.

Re: Bram Moolenaar responds to Neovim

#104

Post by psquid »

svalorzen wrote: post #68
aeonsky wrote: post #45

Earlier quoted context omitted.

I still have yet to see these concrete user benefits.

The benefit is indirect rather than direct, as in the user benefits from the increased availability of plugins/guis since they would be easier to create. Also vim lacks lots of very simple but essential features of modern code editors simply because it lacks the graphical capabilities to do so (an example would be displaying the documentation of some method you are autocompleting, something which I have never seen in…

> an example would be displaying the documentation of some method you are autocompleting, something which I have never seen in vim and which I actually believe is impossible

For python at least, having 'preview' as part of your completeopt has it display the docstring of what you're completing. And :h completeopt suggests that's intended behaviour for all types of completion (where it makes sense), too.

Re: Bram Moolenaar responds to Neovim

#105

Post by eru »

Someone wrote: post #71
sramsay wrote: post #2

Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.

What makes you think this is a rewrite? If this is a rewrite from scratch, they are insanely fast coders, considering that they have a full-blown editor in less than a month (first commit is from January, 31) That first commit also shows it is not a rewrite, though, since it has a comment starting with "Import vim from changeset v5628:c9cad40b4181"

I wonder why they start with fresh history.

Re: Bram Moolenaar responds to Neovim

#106

Post by Jasber »

teacup50 wrote: post #88
btipling wrote: post #54

Earlier quoted context omitted.

At Floobits we tried to submit set_timeout/async stuff, and couldn't get anywhere with Bram. Months of work wasted. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

Your patches were broken. People spent plenty of time trying to help you fix them. Your response is to tell the Internet that Vim is wrong for not accepting broken patches?

Did you read the same thread I did? Floobits addressed all the issues.

It came down to a fundamental design decision—and after months of hard work, they got a non-answer.

Re: Bram Moolenaar responds to Neovim

#107

Post by jbranchaud »

As vi was a popular editor amongst programmers and system administrators, there initially was doubt whether Bram's 'improved' version could achieve the quality and fan following of the original. But since its first release for Unix systems in 1992, Vim has effectively eclipsed the original Vi, having won several awards[3] and has been referred to as one of the most popular text editors.

- Excerpt from http://en.wikipedia.org/wiki/Bram_Moolenaar

Re: Bram Moolenaar responds to Neovim

#108

Post by GFK_of_xmaspast »

jey wrote: post #79
sramsay wrote: post #2

Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.

This isn't a "rewrite the code from scratch", but instead is an incremental but aggressive refactoring. There's at least one wildly successful example of this successfully being done for GCC, which is a project even bigger and more complex than Vim. Around GCC 2.8, it was forked into EGCS where major changes were made. This fork was so successful that it then became the official branch of GCC, and modern versions of…

As I recall, EGCS happened because GCC development had stagnated, if not stalled entirely.

Re: Bram Moolenaar responds to Neovim

#109

Post by ampersandy »

Jasber wrote: post #106
teacup50 wrote: post #88

Earlier quoted context omitted.

Your patches were broken. People spent plenty of time trying to help you fix them. Your response is to tell the Internet that Vim is wrong for not accepting broken patches?

Did you read the same thread I did? Floobits addressed all the issues. It came down to a fundamental design decision—and after months of hard work, they got a non-answer.

Bram's last post was 10/21/13, and a month later Bjorn confirmed in his fork that he could reliably freeze VIM and had segfaults that he had yet to fix. The final word seemed to be:

"There are enough vim users out there (myself among them) to warrant supporting a fork for as long as we're around. We'll try to keep it up to date with the latest changes."

I don't think anyone should expect Bram to chase them down for updates to the patch. Reading through the discussion, it seems clear to me that while good-natured, the feature was not ready to be merged into VIM.

Re: Bram Moolenaar responds to Neovim

#110

Post by kamaal »

hglaser wrote: post #8

Why aren't there other vim committers? Bram's conservatism makes perfect sense for someone who has to maintain this huge, consequential, intimidating codebase. Why hasn't he gotten some help?

Big old code bases, have a lot of what I call as 'tribal knowledge' associated with them. People go out, and do experiments only to burn their hands. Over years, the old maintainers generally accumulate a lot of ideas and 'tribal knowledge' to know why 'pie in the sky' ideas won't work.

Nevertheless, people still try. A lot of them fail, a few succeed.

The vim code base is around 300K lines of C code. I'm sure its nothing like Java where 90% of the code is get/set methods, high level delegating classes and exception handling code. 300K lines of code which does the actual work is simply too much code. And one should exercise great caution while dealing with it. Regression is just one thing, I'm sure there are a lot of places in the code which can silently break things you can't detect only to pop up in some strange case in the wild.

Post reply on HN