Hell_Rok writes:
"Neovim is an effort to aggressively re-factor the Vim source code and improve on:
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."
(Score: 5, Insightful) by MrGuy on Thursday March 20 2014, @04:42PM
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
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
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
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
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.