Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Thursday March 20 2014, @04: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 Threshold/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: 2) by hubie on Thursday March 20 2014, @04:35PM

    by hubie (1068) Subscriber Badge on Thursday March 20 2014, @04:35PM (#18941) Journal

    I'm sure there is a lot of cleanup that can be done, and this is a good thing, and I know there is a fine line between "nice-to-have" and "needs-to-have", but apart from that does vim have longevity issues?

    • (Score: 4, Funny) by Anonymous Coward on Thursday March 20 2014, @04:40PM

      by Anonymous Coward on Thursday March 20 2014, @04:40PM (#18942)

      Yep. Emacs is clearly superior and kicking Vi(m)'s ass.

      • (Score: 5, Funny) by Anonymous Coward on Thursday March 20 2014, @05:07PM

        by Anonymous Coward on Thursday March 20 2014, @05:07PM (#18955)

        Can NeoVim finally be the decent text editor that Emacs has been missing to be a complete OS?

        • (Score: 0, Redundant) by JohnnyComputer on Thursday March 20 2014, @05:09PM

          by JohnnyComputer (3502) on Thursday March 20 2014, @05:09PM (#18958)

          This is sort of funny. +1 man.

        • (Score: 5, Informative) by Thexalon on Thursday March 20 2014, @06:22PM

          by Thexalon (636) on Thursday March 20 2014, @06:22PM (#18998)

          Unnecessary: You can already run vim inside of emacs, by using "M-x term". Emacs will prompt you with "Run program:", and then you enter in /usr/bin/vim (or wherever you have one), and poof, you now have vim running in emacs.

          --
          The only thing that stops a bad guy with a compiler is a good guy with a compiler.
          • (Score: 2, Funny) by rufty on Thursday March 20 2014, @11:05PM

            by rufty (381) on Thursday March 20 2014, @11:05PM (#19101)

            So what I need is M-x term find / -type f -name emacs | xargs rm -f ???

          • (Score: 2) by isostatic on Friday March 21 2014, @09:31AM

            by isostatic (365) on Friday March 21 2014, @09:31AM (#19211) Journal

            That's fine, as I can the type !emacs from vim, and up pops emacs.

      • (Score: 4, Funny) by isostatic on Thursday March 20 2014, @05:19PM

        by isostatic (365) on Thursday March 20 2014, @05:19PM (#18963) Journal

        Eight megabytes and constantly swapping? No thanks, I like my text editor lean and mean.

        • (Score: 2) by buswolley on Thursday March 20 2014, @05:25PM

          by buswolley (848) on Thursday March 20 2014, @05:25PM (#18967)

          /sarcasm?

          --
          subicular junctures
          • (Score: 2, Insightful) by DNied on Thursday March 20 2014, @10:45PM

            by DNied (3409) on Thursday March 20 2014, @10:45PM (#19094)

            /sarcasm?

            I sure hope so. "Lean" is about the last word that comes to mind when thinking of Vim. Gimme Nvi any day of the week (I'm even using it to type this post!)

        • (Score: 2) by lx on Thursday March 20 2014, @06:01PM

          by lx (1915) on Thursday March 20 2014, @06:01PM (#18984)

          I can still (vaguely) remember a time when 8 megabytes was a lot of memory. Like six floppies [tumblr.com].

          • (Score: 1, Insightful) by Anonymous Coward on Thursday March 20 2014, @06:30PM

            by Anonymous Coward on Thursday March 20 2014, @06:30PM (#19006)

            If you've ever worked with 8-bit or 16-bit microcontrollers it still is!

        • (Score: 2) by TheRaven on Friday March 21 2014, @09:01AM

          by TheRaven (270) on Friday March 21 2014, @09:01AM (#19197) Journal
          Escape Meta Alt Control Shift? I prefer an editor designed for human hands...
          --
          sudo mod me up
          • (Score: 2) by isostatic on Friday March 21 2014, @09:23AM

            by isostatic (365) on Friday March 21 2014, @09:23AM (#19207) Journal

            Quite, hence using vim with caps lock mapped to escape. Hands never move far.

    • (Score: 5, Informative) by jtt on Thursday March 20 2014, @10:03PM

      by jtt (3540) on Thursday March 20 2014, @10:03PM (#19083) Homepage

      If the code is getting too intransparent to make any changes than there's not a "longevity" but a "petrification" issue - people willing to improve it will become discouraged if it's too hard to find out where what is happening where within a reasonable amount of time. And in the long run there will be less an less improvements.

      I've recently ported vim to an ebook-reader and luckily had only to deal with some issues with terminal settings that could be resolved in a relatively short amount of time. And the vim code is definitely not one of the worst I've seen (there are even a lot of comments;-) But given the sheer size of it (the src directory alown is about 380 kLoC in C and header files) I think it's not really optimal for allowing even experienced programmers to quickly find their way around. Having a lot of '#if' and '#else" stuff to cater for different environments doesn't help a lot and functions that run for several hundreds of lines also don't. So a "refactoring" (whatever it may mean as long as it makes the code easier to understand) could help to make vim an editor that's mallable enough to be used also in the future because it's easy enough to adapt to new requirements.

      And if there are a lot of people willing to spend money on the chance of keeping vim alive and able to address further needs what's wrong with that? From what I've seen nearly every piece of software could benefit from a rewrite after 10 to 15 years (but which hardly ever happens). If neovim succeeds it may make vi an editor more fit for the future

    • (Score: 5, Informative) by Koen on Thursday March 20 2014, @11:23PM

      by Koen (427) on Thursday March 20 2014, @11:23PM (#19113)

      does vim have longevity issues?

      From TFA [bountysource.com]:

      Problem

      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.

      Another issue is that as the only person responsible for maintaing vim's big codebase, Bram Moolenaar has to be extra-careful when accepting patches because once merged, the new code will be his responsibility.

      These problems make it very difficult to have new features and bug fixes merged into the core. vim just can't keep up with the development speed of its plugin ecosystem.

      and also:

      I'm the author of vim's event loop patch and the job control patch, which were big motivators for this project.

      --
      /. refugees on Usenet: comp.misc [comp.misc]
  • (Score: 5, Insightful) by MrGuy on Thursday March 20 2014, @04:42PM

    by MrGuy (1007) on Thursday March 20 2014, @04: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.

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

      by Anonymous Coward on Thursday March 20 2014, @04: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, @05:39PM

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

      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.

      --
      Account abandoned.
      • (Score: 2) by istartedi on Thursday March 20 2014, @07:54PM

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

        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.

        --
        Appended to the end of comments you post. Max: 120 chars.
    • (Score: 1) by HiThere on Thursday March 20 2014, @08:28PM

      by HiThere (866) Subscriber Badge on Thursday March 20 2014, @08:28PM (#19056) Journal

      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.

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
  • (Score: 5, Insightful) by fliptop on Thursday March 20 2014, @04:52PM

    by fliptop (1666) on Thursday March 20 2014, @04:52PM (#18950) Journal

    It lets you extend the editor in any programming language

    Just last night I forked/cloned the SN git repo and took a look at Environment.pm in vim. The following line in the prepareUser method has a regex that screws up the syntax highlighting for the rest of the code:

            if ($uri =~ m[^/$]) {

    I changed it to:

            if ($uri =~ m{^/$}) {

    which fixed it, but the original code is syntatically correct. Like I said, just getting stuff like that fixed would be a good thing, IMHO.

    --
    Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other.
    • (Score: 1) by The Mighty Buzzard on Thursday March 20 2014, @05:07PM

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Thursday March 20 2014, @05:07PM (#18956) Homepage Journal
      Erm, that's the exact same meaning in perl. Unless there's a bug in the perl version, there should be absolutely no difference between m[^/$], m{^/$}, or even m#^/$#.
      --
      My rights don't end where your fear begins.
      • (Score: 2) by The Mighty Buzzard on Thursday March 20 2014, @05:12PM

        by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Thursday March 20 2014, @05:12PM (#18960) Homepage Journal
        Yeah, feel free to ignore the above post. Believe I'll go with Way Too Much Coffee as my excuse for failing at basic reading comprehension.
        --
        My rights don't end where your fear begins.
        • (Score: 2) by fliptop on Thursday March 20 2014, @06:09PM

          by fliptop (1666) on Thursday March 20 2014, @06:09PM (#18990) Journal

          I'll go with Way Too Much Coffee as my excuse

          No worries, after rereading my comment I probably could've worded it more clearly anyway.

          --
          Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other.
    • (Score: 2) by TheRaven on Friday March 21 2014, @09:08AM

      by TheRaven (270) on Friday March 21 2014, @09:08AM (#19201) Journal
      My issue with vim's highlighting is that it does not differentiate between spacing for indent and spacing for alignment. Our coding style says that you must indent one tab for every indent level, but may use spaces to align code. For example, if you have an if statement that wraps, the next line would have the same number of tabs as the preceding one, but then 4 spaces to line up with the character after the ( of the if statement. Other continued lines follow the same rule. If you're lining up comments or variable declarations, you similarly use spaces.
      --
      sudo mod me up
    • (Score: 1) by michealpwalls on Friday March 21 2014, @02:27PM

      by michealpwalls (3920) on Friday March 21 2014, @02:27PM (#19314) Homepage Journal

      "just getting stuff like that fixed would be a good thing, IMHO.

      That is the point, I think. The vim code-base is ancient and very large, filled with old and largely unfamiliar dialects of C (C'89) that few would be able to find and correct bugs, regardless of how trivial they may appear.

      I think, the whole point is to refactor out that code to make fixing trivial bugs like that much, much more easier. The largest problem with open source projects isn't fixing bugs, it's actually getting into the codebase and finding what it is you're looking for... When you're a volunteer, wading through 300k lines of foreign C89 code you've never seen in your life isn't exactly what I call a good day. Not only that, but being unfamiliar with the dialect will quickly destroy your courage to make any changes, for fear of outright breaking it :)

      As an aside, my PERL is pretty rusty but I think both are syntactically correct:

      if ($uri =~ m[^/$]) {

      =

      if ($uri =~ m{^/$}) {

  • (Score: 2) by egcagrac0 on Thursday March 20 2014, @05:09PM

    by egcagrac0 (2705) on Thursday March 20 2014, @05:09PM (#18957)

    It would seem that Elvis has left the building. [the-little...d-girl.org]

    Which is kinda sad; I always liked Elvis over vim.

    • (Score: 2) by melikamp on Thursday March 20 2014, @05:19PM

      by melikamp (1886) on Thursday March 20 2014, @05:19PM (#18964) Journal

      Ed, man. Man ed.

      I wish there was ed+readline kind of editor. That would be simply killer.

      • (Score: 3, Funny) by egcagrac0 on Thursday March 20 2014, @05:37PM

        by egcagrac0 (2705) on Thursday March 20 2014, @05:37PM (#18970)

        Have you tried not making errors, and just using "cat >file"? ;)

  • (Score: 5, Insightful) by Lagg on Thursday March 20 2014, @05:49PM

    by Lagg (105) on Thursday March 20 2014, @05:49PM (#18980) Homepage Journal
    Just like with github's own already-failed editor (WebTechnologies (TM), open core, somehow managing to be dependent on OS X despite being written mostly in HTML and JS as per their words) this is yet another thing that is pretty much already dead if they can't even get the fundamentals right. Getting real tired of this shit. I saw news of this earlier and this was my mental progression from beginning to end: "Oh cool, refactoring it? Well that's great it needs a cleanup- wait. Wait, where are these features coming from out of left field. How is adding more cruft refactoring? Wait, wait, vim for the 21st century? What? Oh... Oh crap... It's one of those editor projects.".

    They can keep their misuse of terms, buzzwords and other such nonsense. Those of us who get things done (whether you use vim or emacs, doesn't matter) will continue to do so with our so-called "outdated" editors and those who want the new purdy can use their webkit powered layers upon layers of hacks to get various extension language bindings to work and sorry excuses for embedding that end up breaking subsystems because of the hacks used to make the embedding work in the first place and struggle with it more than actually writing code.
    --
    http://lagg.me [lagg.me] 🗿
  • (Score: 3, Interesting) by Marneus68 on Thursday March 20 2014, @06:09PM

    by Marneus68 (3572) on Thursday March 20 2014, @06:09PM (#18991) Homepage

    I find this project a nice but unnecessary rewrite. Sure, the vim source could use a little cleanup, but as I see it, this piece of software reached the "done" status a while ago already. It does everything I need to the notable exception of the famed (and still kinda rare) elastic tabstops [nickgravgaard.com].
    If this rewrite includes (or makes it easier to implement) these, then, I might donate. Any info on the matter ?

    • (Score: 2, Informative) by Desler on Thursday March 20 2014, @06:14PM

      by Desler (880) on Thursday March 20 2014, @06:14PM (#18994)

      It's not a rewrite. The are working from the Vim code as the starting point.

  • (Score: 2, Interesting) by sl4shd0rk on Thursday March 20 2014, @06:48PM

    by sl4shd0rk (613) on Thursday March 20 2014, @06:48PM (#19021)

    I cut my teeth on Borland's IDEs' and really miss the features and functionality. Linux could still use something with the features of Vim and Emacs, but the simplicity of Nano (without all the CTRL key combo oddities). Too bad RHIDE [rhide.com] never made it out of 2004.

  • (Score: 2, Interesting) by drasha on Thursday March 20 2014, @07:27PM

    by drasha (1201) on Thursday March 20 2014, @07:27PM (#19038)

    I am not saying that this is not a worthy endeavor, but I felt little uneasy looking at the proposed plugin scheme.

    Each plugin should be a process that will communicate with vim via rpc:

    plugin -> neovim: {"id": 1, "method": "listenEvent", "params": {"eventName": "keyPressed"}}
    neovim -> plugin: {"id": 1, "result": true}
    neovim -> plugin: {"method": "event", "params": {"name": "keyPressed", "eventArgs": {"keys": ["C"]}}}
    neovim -> plugin: {"method": "event", "params": {"name": "keyPressed", "eventArgs": {"keys": ["Ctrl", "Space"]}}}
    plugin -> neovim: {"id": 2, "method": "showPopup", "params": {"size": {"width": 10, "height": 2} "position": {"column": 2, "line": 3}, "items": ["Completion1", "Completion2"]}}
    plugin -> neovim: {"id": 2, "result": true}}

    This reads like a mother of all inefficiency...

    • (Score: 2) by Marneus68 on Thursday March 20 2014, @08:32PM

      by Marneus68 (3572) on Thursday March 20 2014, @08:32PM (#19057) Homepage

      > This reads like a mother of all inefficiency...
      Don't worry. Throwing some LUA interpretation in will speed up everything. That makes perfect sense !

  • (Score: 3, Interesting) by mechanicjay on Thursday March 20 2014, @08:42PM

    by mechanicjay (7) <{mechanicjay} {at} {soylentnews.org}> on Thursday March 20 2014, @08:42PM (#19059) Homepage Journal

    Outside of a couple of minor bugs mentioned above -- I have no problem with vi/vim. It's lightweight, does what I need and is pretty much guaranteed to be on any *nix box you're on. I spend about 1/2 my day in vim and don't really see where's it lacking as a text editor.

    I suppose if you really wanted to turn vim into a full-fledged IDE, this is what you do. But why would you do that when there are already really good IDE's out there? Though in TFA, they say explicitly that this is not supposed to turn vim into an IDE. I'm confused.

    --
    My VMS box beat up your Windows box.
    • (Score: 1) by Anonymous Coward on Friday March 21 2014, @04:53AM

      by Anonymous Coward on Friday March 21 2014, @04:53AM (#19162)

      I really like Cream for Vim.

      from the Wikipedia page ( http://en.wikipedia.org/wiki/Cream_(software) [wikipedia.org] )--
      "Cream is a configuration of the Vim text editor that consists of a set of scripts which can be run within Vim to make it behave"...

      or Cream's 'home' page:

      "A modern configuration of the powerful and famous Vim, Cream is for Microsoft Windows, GNU/Linux, and FreeBSD."

      Works great for me... probably a good variant for people who like their apps more 'GUIfied'. :)

    • (Score: 1) by omtinez on Friday March 21 2014, @07:49AM

      by omtinez (2733) on Friday March 21 2014, @07:49AM (#19179)

      Lightweight? Are we talking about the same 25MB console application that is a text editor with fancy highlighting and little more? I find humorous that Notepad++ can compete with Vim in size

      • (Score: 3, Informative) by TheRaven on Friday March 21 2014, @09:21AM

        by TheRaven (270) on Friday March 21 2014, @09:21AM (#19204) Journal
        25MB? My Vim binary is 1.9MB. The vim runtime directory is 30MB, but the big parts of that are:
        • 8.MB of localisation files (which you don't need if you only want one language) and
        • 3.8MB of spell checking dictionaries
        • 6.5MB of docs (how much documentation does Notepad++ have?)
        • 2MB of vim tutor (basically more documentation)
        • 5.3MB of syntax highlighting definitions for various languages.
        • 1.8MB of autoload scripts, including remote file I/O, compressed file I/O and some things like the PHP syntax highligting thing that switches between PHP and HTML modes on boundaries.

        The rest comes to a total of 2.6MB. If you don't want documentation, localisation, or spell checking, it's under 5MB.

        --
        sudo mod me up