Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Software

Neovim: Rebuilding Vim For the 21st Century 248

Posted by timothy from the vigor-next-to-be-upgraded dept.
An anonymous reader writes "Neovim is a major overhaul of the vim editor to provide better scripting, cleaner support for plugins and integration with modern graphical interfaces. Modernising the large and complex codebase of Vim is a formidable task, but the developer has a clear plan, and has already begun work. There's a Bountysource fundraiser running to support the effort. If Vim is your editor of choice, check it out." (The crowd-funding effort has only one more day to go, but has well exceeded already the initial goal of $10,000.)
This discussion has been archived. No new comments can be posted.

Neovim: Rebuilding Vim For the 21st Century More

Neovim: Rebuilding Vim For the 21st Century

Comments Filter:

  • Obligatory xkcd, and rirst post (Score:5, Funny)

    by Anonymous Coward on Saturday March 22, 2014 @09:09AM (#46550881)

    http://xkcd.com/378/

  • formidable task != $10k budget (Score:5, Interesting)

    by Anonymous Coward on Saturday March 22, 2014 @09:20AM (#46550947)

    if someone came to me to evaluate their budget reasonableness for something they described as a formidable task taking more than a week or two, and asked for $10k, I'd know they were egregiously underestimating or something is missing.
    (and as TFA says: "Over its more than 20 years of life, vim has accumulated about 300k lines of scary C89 code that very few people understand or have the guts to mess with."... that's pretty formidable)

    I suppose some ambitious person living in a low cost of living locale could survive for 6 months on 10k, and that would be a fair amount of work time; toiling in their barren garret or tower.

    TFA says "$10,000 will allow me to dedicate two months of full time work to this project, which will be enough to implement the following:"

    Is $5000/mo a reasonable sum in Recife, Brazil? Probably.

    Is 2 months sufficient time to do all he wants to do? I'm not so sure. That's a pretty long list of things he wants to do.

    • A consulting company would ask 1,000 to 2,000 per day, so 40,000 to 80,000.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      I'm a Brazilian, though I don't live in Recife.

      > Is $5000/mo a reasonable sum in Recife, Brazil? Probably.

      Agreed.

      USD $5,000 is a hefty sum in Brazil to be earned for a month's work, though it's not obscene. Some things are way expensive here (like cars and houses), some are somewhat more expensive (like computers) and some are cheap (like food). We're more or less like an inverted Japan, in economic terms.

      From his previous initiatives, the guy seems to belong to a category with few people who could deser

    • It depends on the circumstances. As you said, without doing anything different, I could survive for about half a year or more on $10k. Think "slow burn." I don't have kids in the house, most of my assets are paid off, including my house, and it's in an economically depressed area, so most stuff, including taxes, is cheap. I can see where $10k wouldn't get you two months, and I've lived like that, but that's not everyone.

      • Depends, are you paying me in BitCoins so I don't pay taxes?

        I live on just about $5.3K per month, which is what the government lets me keep of my 6 figure income, and I save out of that amount too.

        • (that is for a family of 4, btw, not just myself. Much lower burn rate if it was just me, but I like my family =) )

  • Certainly as a fork... good luck (Score:5, Interesting)

    by inflex ( 123318 ) on Saturday March 22, 2014 @09:26AM (#46550987) Homepage Journal

    I admit to being curious to see how this one goes as a fork off the existing vim codebase, but I'm not sure I'd be putting any bets on its long term viability. I suspect an overdose of optimism and insufficient compelling reasons for users to shift from vim will starve this project out.

    Good luck to the developer - it's going to be one hell of a learning experience.

  • Vim's Bram Moolenaar on 'Neovim' (Score:5, Informative)

    by RDW ( 41497 ) on Saturday March 22, 2014 @09:27AM (#46550991)

    https://groups.google.com/foru... [google.com]

    "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."

    • It sounds more like a task that the maintainers of VIM should actually be undertaking on the main branch. One step at a time.

    • Re:Vim's Bram Moolenaar on 'Neovim' (Score:5, Informative)

      by jjohnson ( 62583 ) on Saturday March 22, 2014 @10:14AM (#46551303) Homepage

      what's the gain for the end user exactly?

      The origin of the fork is that tarunna submitted two large patches to vim that would have fixed a lot of process management in vim, and was rejected because the current vim codebase is so large and crufty that it's impossible to make major architectural changes to it, like allowing for async process management, just because the risk is too high (especially when there's literally one person, Moolenaar, with a commit bit and thus accepting responsility for every change). And the risk really is very high, I'm not faulting Moolenaar for this.

      The gain is that (neo)vim will be able to keep up with current technologies in its plugins (like non-blocking operations), it'll allow plugin authors to write faster plugins by speeding up the plugin architecture, existing plugins will see a speed increase, and other programs will be able to embed vim as an editor rather than hacky "vim keybindings" plugins. Given time and asm.js, it'll run natively within a web browser. None of these were in reach with Moolenaar squatting on the code rejecting risky patches. Sounds like a lot of gains to me.

      • Re: (Score:2)

        by Alomex ( 148003 )

        As a data point, a while back I peaked into the Vim source code and was amazed at how complicated the code base was. On the other hand I was very impressed with the sophisticated data structures it was using to support large files efficiently.

        • Re:Vim's Bram Moolenaar on 'Neovim' (Score:5, Insightful)

          by jjohnson ( 62583 ) on Saturday March 22, 2014 @12:03PM (#46552109) Homepage

          The root problem here that tarruda is addressing (and he's very explicit about this in the neovim newsgroup) is that the code needs to be refactored for maintainability and to open up the development process. There's one guy in the world who really understands the codebase, so we're all one sleepy bus driver or bursting blood vessel away from vim becoming a frozen pile of code. Tarruda's starting point is refactoring out huge swathes of platform specific code, to be replaced with a single dependency on libuv for cross-platform support, to get to full test coverage, to modernize the C, and to craft a multi-developer process that allows for modern ongoing development by a large number of people, like other OSS projects have.

          All the user focussed gains that will flow from that are real gains, but really what Tarruda is doing is freeing Moolenaar from the corner into which he's painted himself. I like to think that Moolenaar (like Stallman with JWZ's fork of emacs) will come around, see the real improvement in the fork, and arrange to cut over to it.

    • This kind of thing works from time to time when the original developers really aren't in sync with what's wanted or needed by the public. It worked with gcc -> egcs for instance, but most of the time its a waste of code and effort.

  • It's a pretty big step to just fork a major project like that. Have they actually talked to Bram and the other vim hackers first? I can only assume that if their ideas are sound that he would have no problem integrating them upstream.

    • Apparently Bram has already said that he thinks it's a bad idea.

      A lot of the proposed changes are apparently to remove support for "obsolete" systems and configurations. It's really doubtful that it would ever be merged into the main vim codebase.

      • I see. Well, it's going to be interesting to see what comes out of it.

        • Re: (Score:2)

          by jjohnson ( 62583 )

          It's worth observing that Bram's vim started as an early 90s reimplementation of vi, which at the time was stuck in legal limbo due to its BSD origins. Vim eventually became the vi of choice for linux distributions, and was lifted by that rising tide to become what everyone now thinks of as vi. The vi that is considered a direct dependent of the original version written by Bill Joy is called "traditional vi".

          If in five years, vi is typically a symlink to nvim instead of vim, I will be totally unsurprised.

  • Broken link (Score:2, Funny)

    by gentryx ( 759438 ) *
    You can download the successor to vim [gnu.org] here. FTFY.

    • Re: (Score:2)

      by koinu ( 472851 )
      Well, there is no successor to vim without saying that it sucks.
  • When the primary forum for discussion of said program is still on usenet.

  • Full blown vim in a good IDE:one of my dreams (Score:5, Interesting)

    by rabbin ( 2700077 ) on Saturday March 22, 2014 @09:49AM (#46551155)
    Vim has to be one of my favorite programs but I rarely use it for any "ambitious" coding project because it lacks critical features that an IDE provides (the plugins don't cover these gaps either). Right now I'm using Netbeans with the jVi plugin (provides a subset of common vim behavior) for c++ programming and it works well, but if an IDE plugin could simply embed instances of vim into the program itself and have it work seamlessly with the existing IDE features (e.g. advanced code understanding of inheritance hierarchies and type deduction) that would be the ideal. With this in mind, the following from the website sounds really promising:

    First class support for embedding

    Since Neovim will be provide the interface to interacting with text, any program will be able to tap into this potential and be able to include Neovim commands right in the application.

  • I think instead of rewriting the C part, they should improve Vim's scripting language to the point where it can be used for moving larger portions of the editor into it. Vim script is a decent effort, but it feels a bit cumbersome and non-standard. I think they'd be better off with something that more widely used and possibly JIT compiled.

  • 'Rebuilding Vim for the 21st Century' says it all. The problem with the 21st century from what I've seen, is this insistence that we must re-invent the ENTIRE wheel.
    I'm going to suggest that if you feel it's time to re-invent vim, that it target a universal platform. There's really only one - the web. You can use it on every platform. Using the project node-webkit, there's really no reason not to use HTML5 and Javascript to develop an honestly modern application. (The sarcasm is dwindling, I'm half serious

    • The problem is simply that vi/vim aren't meant for the 21st century and trying to shoehorn it in is a stupid idea.

      You're really inexperienced in the wide range of places vi ends up.

      vi as you know it, works the same on pretty much EVERY unix at this stage, including tiny tiny embedded ones. I heard a rumor of which I'm entirely sure was false that its even been on one of nasa's creations floating around off in the cosmos.

      You are not putting webkit on my raspberry pi, I want to see the text updated sometime

      • Re: (Score:2)

        by Kremmy ( 793693 )
        I love the wide range of places that vi has ended up... I feel like we really need to go retrograde to have honest software innovation at this point, I like the idea of using a modern web browser to re-implement something like MobaXterm (it's a slick cyg/mingw terminal emulator package for Windows) and then using classical foundation technologies as the classical foundation on all these devices. The old unix philosophy of having the utilities do what they do well combined with the technology to put a shiny
  • i quit using vim because the god damn Ugandan orphan spam in my face every time i opened it, if i see that in neovim i will not use it either,

  • As long as it passes VSC5, I don't care.

    They could put antlers on the thing, as long as it continues to pass the POSIX conformance test suite Validation Suite for Commands version 5, it doesn't matter, my medulla will be able to still type the commands to operate it while I'm up in my cerebral cortex thinking about higher level problems than "will typing this command too many times give me carpal tunnel syndrome like RMS has from emacs use?" or "how an I get a graduate student to take dictation into an edit

  • You would have to break all the things that cause people to use it ... and then its not going to work the same on EVERY unix machine on the planet. vi's strength lies in the fact that as crappy as it is, its consistently crappy, the same way (vi feature set) across all machines, even the crappiest tiny embedded linux distro, to full server and desktops. I don't have to wonder what editor I'm going to have to find and use nor how it works.

    Stop fucking with vi.

    If you want a non-shitty editor, stop using a s

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close