Stories
Slash Boxes
Comments

Dev.SN ♥ developers

posted by janrinok on Thursday March 20 2014, @12:27PM   Printer-friendly
from the cue-vim-emacs-war-in-5-4-3-2-1 dept.

Hell_Rok writes:

"Neovim is an effort to aggressively re-factor the Vim source code and improve on:

  • It will provide first class support for embedding.
  • It lets you extend the editor in any programming language.
  • It supports more powerful GUIs.
  • Vim plugins will work with it.

Hosted on Bounty Source it has reached $25,500 of it's goal of $10,000, although there are still 3 days to reach further stretch goals! You can view the projects current progress and even pitch in over at GitHub. As someone who has started using Vim full-time over the last 6 months I feel that this is a very good project for the longevity of Vim."

 
This discussion has been archived. No new comments can be posted.
Display Options Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by MrGuy on Thursday March 20 2014, @12:42PM

    by MrGuy (1007) on Thursday March 20 2014, @12:42PM (#18943)

    You're refactoring vim to do this? Emacs vs. vi is such an old school argument, and no amount of "improving" vi/vim will ever settle it.

    What's the attraction in doing this off the existing codebase, and "aggressively refactoring" it to do things it was not designed to do, rather than starting "clean" and building something that innately supports the concepts you want? TextMate FTW.

    By the way, this is a misuse of the term "refactoring." Refactoring is changing the structure of code to be more readable/efficient/maintainable/extensible/etc. without changing it's externally visible behavior. You can refactor code to make it easier to add new features later. But you can't (by definition) "refactor" in new features. You're redesigning.

    Starting Score:    1  point
    Moderation   +3  
       Insightful=5, Overrated=2, Total=7
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2, Insightful) by Anonymous Coward on Thursday March 20 2014, @12:49PM

    by Anonymous Coward on Thursday March 20 2014, @12:49PM (#18946)

    What's the attraction in doing this off the existing codebase, and "aggressively refactoring" it to do things it was not designed to do, rather than starting "clean" and building something that innately supports the concepts you want? TextMate FTW.

    Because rewriting from scratch often leads to a project never succeeding.

  • (Score: 1) by Bot on Thursday March 20 2014, @01:39PM

    by Bot (3902) on Thursday March 20 2014, @01:39PM (#18971)

    I agree.
    Besides, when needed, I just redirect my output to a text file, with no need for those "editors" you keep speaking about. You should try that, too.

    • (Score: 2) by istartedi on Thursday March 20 2014, @03:54PM

      by istartedi (123) on Thursday March 20 2014, @03:54PM (#19043)

      I just redirect my output to a text file, with no need for those "editors" you keep speaking about.

      Damn straight, and my first project was a parser that reads the history file and removes erroneous commands. Then it intelligently infers which commands were simply tests to see if I had the right command. The end result is a shell script that does what I want. Half joking of course. I suppose you could adopt that as your personal process if such an intelligent parser existed. It would be a bit like using a REPL for development which I understand some hardcore Lisp guys do. I can imagine developing in a REPL... but I don't see myself ever working that way.

  • (Score: 1) by HiThere on Thursday March 20 2014, @04:28PM

    by HiThere (866) on Thursday March 20 2014, @04:28PM (#19056)

    Well, for one thing EMACS aggressively doesn't understand file systems. (That's not quite right, but I can't figure out how better to say it.) I've tried EMACS a few times, and I'll never learn it because of the strain that multi-key commands put on my hands, but their "buffers" are a ridiculously complex way to deal with files. And it's not inherent in LISP, so that's not the excuse. I have done (a very small amount of) LISP programming, and a standard editor is much more usable than is EMACS. (I will grant that I'm not using vi for this purpose either, but it's EMACS that is supposed to be adapted to LISP.)

    OTOH, I'm not sure what one gains from "refactored vi". The purpose of vi is to be used in situations where there's slightly more RAM available than nano needs. It's not a geany or kate replacement. Trying to make it one is more likely to kill it than to improve it.

    --
    Put not your faith in princes.