I am wondering in what way a "modern vim" isn't "vim". GVim exists, and plugin management is a problem frankly solved years ago.
I also wonder how he is going to support modern features that Vim currently has with a web-based editor. Can I script this in my choice of modern languages? Python? Ruby?
If I were going to change any single thing about Vim, it would be to make MzScheme scripting support a first class citizen, and slowly re-engineer the backend to be more Emacs styled. Core C (or whatever, but C out of momentum) functions with the rest of the system build up in Scheme. I think it would be foolish to call such an improvement "modernizing" though, since it is hardly a new idea. ;)
> If I were going to change any single thing about Vim, it would be to make MzScheme scripting support a first class citizen, and slowly re-engineer the backend to be more Emacs styled. Core C (or whatever, but C out of momentum) functions with the rest of the system build up in Scheme.
Thank god there are people who share this vision! I have solemnly promised to myself that I will write a new vim in exactly this fashion if no one has done so in the next 10 years.
One thing that I don't understand about contemporary developers is the aversion to running their editors in a terminal. The benefits of doing this are significant (e.g. session management with tmux, remote pair programming via the same), but programmers leave them behind for what is ultimately just eye candy.
The major reasons for this are the difficulty in binding complex key chords in a terminal, and the poor implementation of OS X's Terminal.app (both of which can be worked around today with a little work, and a proper X terminal). If this terminal-based workflow is going to thrive in the future, what will need to be modernized is the terminal.¹
So you heard it here first: if a new vim built atop a Lisp interpreter running on a new data-centric, mixed character-grid/HTML5-webview terminal emulator does not appear in the next 10 years, I'm on the job.²
I'd actually approach the issue from the other end (that is, frontend) - There is a slight pain point in the strong binding between vim and terminals in that, as this video points out, the UI is limited by a character grid. This makes many features uglier and less usable, such as autocomplete, file viewers, the command line, the gutter, etc. It also limits your choices for fonts.
If I were to design a "modern" vim from the ground up, I'd probably arrive at something a lot like Sublime Text 2 with vim at the core.
I can almost guarantee that it would be easier to fix whatever it is you don't like about vim than to start from scratch.
Too many developers have this conceit that it's easier to start from scratch. Sometimes that's true, but usually not. Usually there's an exaggerated fear of extending other people's code.
Of course the world is big enough for another project, and you might make the next great editor. But be realistic about how much effort went into something like vim, and don't think you're going to single-handedly replace it in a month.
"I can almost guarantee that it would be easier to fix whatever it is you don't like about vim than to start from scratch."
That's just not true. I'm a huge vim fan, I've customized my vim a ton, I have maybe 30 installed plugins. But when I open Sublime Text and type "ctrl-p" to go to another file, it just works plain better than any vim plugin can achieve.
Vim is made to work on a terminal. Great for some people, lousy for people who want the vim model of text editing with a modern gui.
A few specific things that you simply can't fix in vim:
- Making pop-up boxes, a-la Sublime Text, that moves you to a new file. Simply cannot be implemented in a nice-looking way in vim.
- Making some fonts smaller or bigger, to display extra information that isn't code. Simply impossible to do, because vim is a one-size font. This alone is a huge limitation.
- Making a decent-looking code-folding system. The code folding in vim doesn't look good, and since you're limited to one font size and to only putting in characters, you're stuck with the very ugly way of doing things. I'm a huge fan of vim folding, and the way of controlling them is just amazing. Except for the way it looks, which is terrible.
Now, these aren't just "I want my editor to be pretty" issues. A lot of these things are functionally important to get working faster on your code.
On the one hand you say it can be easier to start from scratch, but on the other you say you can almost guarantee it wouldn't be. It can't really be both.
I think the only meaningful thing to say would be whether, in the specific case of Vim, you can outline why it wouldn't be easier.
Using Chrome packaged apps makes compilation problematic if not impossible as well as running command-line functions.
The file model for Chrome packaged apps is similar to the Mac App Store in that you can access files but you have to get explicit permission for each one you open. There's also an internal file system to the app that you can create.
I write HTML5 apps but also do quite a bit of Java moving between different projects during the course of the day and running some command-line functions too. Happy Edit as it appears today wouldn't give me parity to how I use vim.
If I were on a Chromebook, I would probably just use tmux/screen and a ssh session.
Have you considered alternate ways of funding your development? Like subscriptions? (it's a web app right?). Maybe figure out a price... let's say $10 a month or $100 a year and get people to pay for a yearly subscription up front.
It may not allow you to focus on it full time at first, but could give you the incentive to continue improving the product and eventually work on it full time.
I think that the author will get all the funds regardless of reaching the goal. It is the first time I see indiegogo and it would be quite different from kickstarter, but that's what their page seems to indicate:
>Flexible Funding campaign
>This campaign will receive all of the funds contributed by Wed Oct 31 at 11:59PM PT.
I must admit a marked lack of enthusiasm for projects like this. You already have a number of vim "clones" developed with various technologies (ysis in qt4 - dead, yi in haskell - though it has also an emacs mode, still actively developed, probably others I don't know about). They haven't managed to take off in a significant way, what is this one bringing to the table? The idea of taking on an editor with about 20 years of development behind it, even with the editor core already written, in a couple of months, is ludicrous.
And to top it all, it doesn't even work in a terminal.
The problem is attracting a large enough group of users and contributors. If you have only a handful people working on it then it will quickly fade away. I've seen this with several open source projects. One maintainer finishes college, the other changes jobs, the one guy who thought he could make a living out of it realises he's broke, the biggest contributor becomes father and all of the sudden there are too few people left. And although everybody loves the new ideas behind the project it quickly turns into an unmaintained mess and because there are so many alternatives available they'll eventually move on.
Let's face it the editor market is really really crowded. And there are tons of great editors out there. You really have to be innovative to get a foothold there. And can HappyEdit really provide that by simply being a vim-like in-browser editor with some sublime features? It is incompatible to all the existing vim plugins and has to reimplement everything vim does. The majority of vim users are probably not interested in fancy guis or even leaving the terminal ("it's not the UNIX way"(tm)). And the $10,000 he asks for will only get him 1-2 month of development. Oh and the indiegogo campaign has less than 3days left and currently only a bit more than $1,000 of the $10,000 he asks for.
Awesome. I'm always on the lookout for a text editor with all the cool things from Vim, but without having to fiddle with the stupid plugin and config system.
I like the product but I really dislike the way he's trying to fund it. You know, once upon a time people would just build and launch shit, instead of begging people for money even before building it. I understand this type of Kickstarter-like campaign is really helpful for building hardware products which require upfront budget, since building hardware costs real money. But building a software? Please... If I was so motivated, I would just build it and release it.
I don't see why it's that bad. You describe it pejoratively as "begging for money", but it does take time to develop anything, and you need money to live. What's wrong with someone wanting to be able to work full-time developing it? And what's wrong if some people want to provide monetary support so the person can do that?
That's not a lot of money. He says it will only get him 1-2 month of development time. Depending on where you are it might get you a few more month but achieving what he wants to achieve would take several years.
I came here to say just this. I'm a vim user, and I have my doubts about this project, but overall I encourage people to experiment and do new things in the editor space-- so I don't begrudge this. But the name is terrible. Don't project an emotion onto your users.
No offence, but as far as I can see, this does nothing that can't be done in vim (or one of its forks) with pathogen/vundle and the extant plugin ecosystem. Also I doubt people will want to pay if there is no native editor/terminal support. ;(
this doesn't look thought out. you need way more than "1-2 months" to develop a good IDE. there's no mention of supported languages and popular features like code indexing and live compilation will never happen on a web platform.
The money buys time for me to work on this project. With the $10,000 that I am asking for, I expect to get 1-2 months of development. This should be enough time to finish what's on the roadmap."
Why would he need an average yearly income to be coding ± 45 days?
How is this editor "vim-inspired"?
Has a vim-like editing language? (not just shortcuts, but combinable verbs, objects and modifiers)
Has different modes? (normal or command, editing, ...)
Is very extensible?
I don't see any of those in the video, and they are vim's most important features (especially the first one).
Sublime Text 2 has Vintage mode which supports Vim-like commands, is a native app, and is elegant.
However, HappyEdit has one significant advantage over ST2, in that it is open source. While I love ST2, I feel like for it to really be embraced as a great editor, it needs to be open source.
I've tried using Sublime with Vintage mode, and about 30% of the time I'm editing, I try a Vim combo and nothing happens. This isn't just for advanced Vim features -- it's for basic things like g_.
I love Sublime and have been using it since the beginning of this year but I'm really worried about getting too "invested" in it because it isn't released under a Free Software license.
My old emacs.d still sits in my home folder because I have this fear that Sublime will just stop being supported tomorrow and I would have no choice but to go back to emacs.
I really just wish emacs had an amazing mixed mode, it's the only thing that even made me try out Sublime. All the php mixed modes I tried were really bad and I do a lot of work in PHP/HTML mixed view files.
I'd love for someone to remake vim, in a modern way. With a modern GUI. And with a lot of thought put into how to make vim easier to use for new users. And with a better solution for plugins and customization.
I'd love for this project to succeed, and I was ready to pay for it, but frankly, I'm skeptical, after looking at the product page. He's asking for money equal to 2 months of development. This is nowhere near, not even remotely close, to how much time it will take to get even a semi-descent version of an editor. I'm sorry, but that's just unrealistic.
Also, I'd love to see other projects he's worked on, to see he knows how to build things, before I back a project.
Looks interesting. Is it possible to support real-time collaboration? By real-time collaboration I mean multiple people working on the same file and being able to see other people changing the file in real time, like Google Wave or Google Docs.
[+] [-] jlgreco|13 years ago|reply
I also wonder how he is going to support modern features that Vim currently has with a web-based editor. Can I script this in my choice of modern languages? Python? Ruby?
If I were going to change any single thing about Vim, it would be to make MzScheme scripting support a first class citizen, and slowly re-engineer the backend to be more Emacs styled. Core C (or whatever, but C out of momentum) functions with the rest of the system build up in Scheme. I think it would be foolish to call such an improvement "modernizing" though, since it is hardly a new idea. ;)
[+] [-] guns|13 years ago|reply
Thank god there are people who share this vision! I have solemnly promised to myself that I will write a new vim in exactly this fashion if no one has done so in the next 10 years.
One thing that I don't understand about contemporary developers is the aversion to running their editors in a terminal. The benefits of doing this are significant (e.g. session management with tmux, remote pair programming via the same), but programmers leave them behind for what is ultimately just eye candy.
The major reasons for this are the difficulty in binding complex key chords in a terminal, and the poor implementation of OS X's Terminal.app (both of which can be worked around today with a little work, and a proper X terminal). If this terminal-based workflow is going to thrive in the future, what will need to be modernized is the terminal.¹
So you heard it here first: if a new vim built atop a Lisp interpreter running on a new data-centric, mixed character-grid/HTML5-webview terminal emulator does not appear in the next 10 years, I'm on the job.²
¹ Some excellent musings on the subject: http://lubutu.com/idea/ivo
² This would all be easier if I could love to learn Emacs, but Vim modal editing is a pernicious addiction.
[+] [-] jrajav|13 years ago|reply
I'd actually approach the issue from the other end (that is, frontend) - There is a slight pain point in the strong binding between vim and terminals in that, as this video points out, the UI is limited by a character grid. This makes many features uglier and less usable, such as autocomplete, file viewers, the command line, the gutter, etc. It also limits your choices for fonts.
If I were to design a "modern" vim from the ground up, I'd probably arrive at something a lot like Sublime Text 2 with vim at the core.
[+] [-] ecspike|13 years ago|reply
As such, scripting would be limited to languages that can run in JS. So if he allows plugins, it would be JS, CoffeeScript, or possibly Emscripten.
[+] [-] Evbn|13 years ago|reply
[+] [-] ef4|13 years ago|reply
Too many developers have this conceit that it's easier to start from scratch. Sometimes that's true, but usually not. Usually there's an exaggerated fear of extending other people's code.
Of course the world is big enough for another project, and you might make the next great editor. But be realistic about how much effort went into something like vim, and don't think you're going to single-handedly replace it in a month.
[+] [-] kkowalczyk|13 years ago|reply
1. The major difficulty in writing an editor is in writing the editor core. He didn't write it from scratch but used existing ACE editor.
2. VIM is a huge mass of C code. Working on a huge mass of C code is ridiculously slow.
He's writing in JavaScript and using html for the UI - this is orders of magnitude faster.
[+] [-] edanm|13 years ago|reply
That's just not true. I'm a huge vim fan, I've customized my vim a ton, I have maybe 30 installed plugins. But when I open Sublime Text and type "ctrl-p" to go to another file, it just works plain better than any vim plugin can achieve.
Vim is made to work on a terminal. Great for some people, lousy for people who want the vim model of text editing with a modern gui.
A few specific things that you simply can't fix in vim:
- Making pop-up boxes, a-la Sublime Text, that moves you to a new file. Simply cannot be implemented in a nice-looking way in vim.
- Making some fonts smaller or bigger, to display extra information that isn't code. Simply impossible to do, because vim is a one-size font. This alone is a huge limitation.
- Making a decent-looking code-folding system. The code folding in vim doesn't look good, and since you're limited to one font size and to only putting in characters, you're stuck with the very ugly way of doing things. I'm a huge fan of vim folding, and the way of controlling them is just amazing. Except for the way it looks, which is terrible.
Now, these aren't just "I want my editor to be pretty" issues. A lot of these things are functionally important to get working faster on your code.
[+] [-] jamesrcole|13 years ago|reply
I think the only meaningful thing to say would be whether, in the specific case of Vim, you can outline why it wouldn't be easier.
[+] [-] ecspike|13 years ago|reply
The file model for Chrome packaged apps is similar to the Mac App Store in that you can access files but you have to get explicit permission for each one you open. There's also an internal file system to the app that you can create.
I write HTML5 apps but also do quite a bit of Java moving between different projects during the course of the day and running some command-line functions too. Happy Edit as it appears today wouldn't give me parity to how I use vim.
If I were on a Chromebook, I would probably just use tmux/screen and a ssh session.
[+] [-] sudonim|13 years ago|reply
http://www.indiegogo.com/happyedit (3 days left, $805 / $10,000 raised).
Have you considered alternate ways of funding your development? Like subscriptions? (it's a web app right?). Maybe figure out a price... let's say $10 a month or $100 a year and get people to pay for a yearly subscription up front.
It may not allow you to focus on it full time at first, but could give you the incentive to continue improving the product and eventually work on it full time.
[+] [-] marekmroz|13 years ago|reply
>Flexible Funding campaign >This campaign will receive all of the funds contributed by Wed Oct 31 at 11:59PM PT.
[+] [-] johncoltrane|13 years ago|reply
[+] [-] mercurial|13 years ago|reply
And to top it all, it doesn't even work in a terminal.
[+] [-] fafner|13 years ago|reply
Let's face it the editor market is really really crowded. And there are tons of great editors out there. You really have to be innovative to get a foothold there. And can HappyEdit really provide that by simply being a vim-like in-browser editor with some sublime features? It is incompatible to all the existing vim plugins and has to reimplement everything vim does. The majority of vim users are probably not interested in fancy guis or even leaving the terminal ("it's not the UNIX way"(tm)). And the $10,000 he asks for will only get him 1-2 month of development. Oh and the indiegogo campaign has less than 3days left and currently only a bit more than $1,000 of the $10,000 he asks for.
So yeah I doubt that this will be a huge success.
[+] [-] dantiberian|13 years ago|reply
[+] [-] barbs|13 years ago|reply
The closest thing I've found so far is Vico (http://www.vicoapp.com/)
[+] [-] buf|13 years ago|reply
http://lepture.com/work/vundle-vs-pathogen/ https://github.com/gmarik/vundle
[+] [-] johncoltrane|13 years ago|reply
[+] [-] volaski|13 years ago|reply
[+] [-] jamesrcole|13 years ago|reply
[+] [-] dysoco|13 years ago|reply
[+] [-] ibotty|13 years ago|reply
[+] [-] fafner|13 years ago|reply
That's not a lot of money. He says it will only get him 1-2 month of development time. Depending on where you are it might get you a few more month but achieving what he wants to achieve would take several years.
[+] [-] sergiotapia|13 years ago|reply
[+] [-] calinet6|13 years ago|reply
[+] [-] wyclif|13 years ago|reply
[+] [-] Magenta|13 years ago|reply
[+] [-] zapt02|13 years ago|reply
[+] [-] jcheng|13 years ago|reply
Never say never...
I agree though that 1-2 months would only be scratching the surface, surely.
[+] [-] BasDirks|13 years ago|reply
"What will you do with the money?
The money buys time for me to work on this project. With the $10,000 that I am asking for, I expect to get 1-2 months of development. This should be enough time to finish what's on the roadmap."
Why would he need an average yearly income to be coding ± 45 days?
[+] [-] microtonal|13 years ago|reply
[+] [-] Deestan|13 years ago|reply
[+] [-] fisadev|13 years ago|reply
[+] [-] gnuvince|13 years ago|reply
[+] [-] venatiodecorus|13 years ago|reply
However, HappyEdit has one significant advantage over ST2, in that it is open source. While I love ST2, I feel like for it to really be embraced as a great editor, it needs to be open source.
[+] [-] djacobs|13 years ago|reply
[+] [-] krakensden|13 years ago|reply
[+] [-] doesnt_know|13 years ago|reply
My old emacs.d still sits in my home folder because I have this fear that Sublime will just stop being supported tomorrow and I would have no choice but to go back to emacs.
I really just wish emacs had an amazing mixed mode, it's the only thing that even made me try out Sublime. All the php mixed modes I tried were really bad and I do a lot of work in PHP/HTML mixed view files.
[+] [-] edanm|13 years ago|reply
I'd love for this project to succeed, and I was ready to pay for it, but frankly, I'm skeptical, after looking at the product page. He's asking for money equal to 2 months of development. This is nowhere near, not even remotely close, to how much time it will take to get even a semi-descent version of an editor. I'm sorry, but that's just unrealistic.
Also, I'd love to see other projects he's worked on, to see he knows how to build things, before I back a project.
[+] [-] tsahyt|13 years ago|reply
[+] [-] songgao|13 years ago|reply
[+] [-] klibertp|13 years ago|reply
[+] [-] jamesrcole|13 years ago|reply
The "Back This Project" button send this message: only click this button if you have already decided you want to pledge money.
I think more people would click on it if it was named something like: "Find Out More" or "Visit Project Page".