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.²
As tikhonj mentioned, Emacs evil-mode is very likely exactly what you're looking for. I had considered myself a hardcore vim user, but I felt the call of Slime and org-mode. When I finally took a serious look at Emacs, I became convinced that Emacs with evil-mode is the ultimate editor for vim lovers.
What concerns me about vim emulation modes is the uncanny valley mentioned by another poster. Working in a second-class interface doesn't sound that great.
However, that's pretty strong praise, so I promise I'll give it a shot before trying to birth a new editor into the world.
I've used Emacs for the last 10+ years first with my own custom keybindings and recently with keybindings with 'default' CUA bindings like you find them in almost any other modern application. Before I switched to Emacs I used vi/Vim for almost 10 years. Also, even when I had switched to Emacs I still used Vim on the commandline and on remote servers but not in any advanced way.
I tried out evil-mode a couple of weeks ago just on a lark and I am staying with it. You really get the best of both world[1] this way. It might be a little strange at times but I wouldn't describe the usage as a second-class interface. Just different. I'd rather describe the default Emacs keybindings as a second-class interface :-)
[1] this will not mean much if you've never used Emacs
That's a great article. Do you know when it was written? It's weird how it's just dangling there with all of 2 sentences of context at http://lubutu.com.
Unicode. In my case I input them in vim by way of vimperator. You can input them in vim using the digraph feature (try <C-K>11 in insert mode).
My vimrc actually parses my ~/.inputrc to extract the keybindings I use to input Unicode characters in bash and every other program that uses readline, allowing me to use the same keys for Unicode chars in every context that I input text.
The Compose key in in X11 does the same, but globally. I think it's not bound by default; I have it on the right extra Windows key. Compose, then 1 then ^ generates a super-scripted ¹.
/usr/share/X11/locale/en_US.UTF-8/Compose has a list, mostly filled with obscure stuff like ㊷.
Another problem with running in a terminal is the lack of good integration with window-system cut/paste (e.g., where you can use editor commands to select text, copy it, and paste it in some other app, getting the actual text instead of just what's displayed on the terminal).
I often run Emacs in a remote screen session (well actually I open a terminal frame in my already-running window-system Emacs), and this is by far the biggest annoyance for me.
> Another problem with running in a terminal is the lack of good integration with window-system cut/paste (e.g., where you can use editor commands to select text, copy it, and paste it in some other app, getting the actual text instead of just what's displayed on the terminal).
This works quite nicely in Vim (even when running in console) with X11. You can access both X11 clipboards from Vim if it was compiled with that option (if you use binaries, most likely it is).
Sure, if you also have an X display-connection to the same machine where the terminal itself is running available and advertised. Unfortunately in many running-inna-terminal scenarios, you don't have such a thing...
I haven't used it myself, but I've heard a number of people say that it's not really the same. I think their complaint was that it's a somewhat superficial emulation.
I'm on it too :) - ping me if and when you get started with this project.
My pet peeve has always been the crappiness of VimL, and the internal confusion between the scripting language and command mode. I've started designing a language (and have a toy implementation) whose goal is to be as powerful on the command-line as a shell language, but also super-easy to write large plugins in.
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.
Not really better engineering[+], I think, so much as perseverance—Emacs originally had the same character-grid limitation, and has gone through multiple display-engine (etc) rewrites to get to the point it's at now, and the amount of pain involved along the way has been ... considerable. There are still limitations stemming from the original design that are going to require even more pain to remove.
[+] This isn't a diss, mind you—I use Emacs, and love it, and have done a fair bit of Emacs development.
That is what I suspected. Kind of makes the idea of using that sort of system to create generic modern developer tools DOA I think. Definitely so if it means I lose Vim's ! command; I couldn't live without that.
I agree. You can make unitaskers like sprite packer/unpackers image quick editors/resizers and the like but anything comprehensive is going to be hard.
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.
The last commit was 19 days ago, roughly when I installed it on this machine. The whole thing was a miserable joke at the time, with less than half of the "already implemented features" working. Either the author is slipping on his local commits or there hasn't been any progress in the last 3 weeks, JS/HTML or not, 10.000$ or not.
Meanwhile, the old and rusty Vim has had 39 patches pushed.
Actually, the editor core is relatively easy. The hard part is adding all those 100s of little extra features you use every day. (Emacs ships with almost a million lines of extension code.)
Included in that million lines of code are two maybe three email clients, two IRC clients, org-mode (~100KLOC itself), tetris, and who knows what else.
I agree with your point, just not that the Emacs code base is a good reference of what's required to implement the numerous little text editing features people use every day.
"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.
> "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."
You are not talking about the same ST2 I've tried out. Mine was limited to files contained in "the project" (so none, if you just open a single file, not even nearby files) and the only way to open a a file outside of "the project" was to use the classic Ctrl+o. How "modern" that was!
> "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."
But, somehow, all the issues in your list have something to do with looks and that's one of the most subjective subjects possible. RoundRects don't help anyone write better code faster: they help you feel better and more confident but nothing more. I'm actually a fan of minimalism and text-based interface and the "fixes" you want would be of no interest to me.
> "- 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."
I'd say that LustyExplorer looked quite good and now CtrlP both looks very good and does a lot more than ST2's Ctrl+P window.
> "- 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."
I fail to see how such a feature would make Vim or any editor better.
> "- 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."
Subjectivity again. How it looks is totally irrelevant: how it works is what matters. `za`, `zM`, `zR`, `zj` and friends are the important parts: add a nice gradient, a right-pointing shadowed arrow and rounded corners and you simply have the exact same feature… with a shiny look that suits your taste. Maybe not mine.
You wrote a large reply, so I feel I owe you a good response. Honestly, I feel it's kind of, let's say, interesting, that I have to defend things like "maybe we'd like more than one font size". Maybe it's worth the sacrifice for having vim retain the same look-and-feel in the terminal, but to outright think that variable font sizes are inherently useless in a software program? Whose primary purpose is to edit text, no less?
Still, here are some examples of more functional ways vim could be better. Most of these are related to visuals, yes, because that's the main thing that plugins can't change in vim.
Examples:
1. Code folding is there to make it easier to scan code. Vim's folds take up a lot of space, and aren't very easy to scan. Yes, this is subjective - it's possible that for you, it's the easiest to scan thing in the world. But for me, the way many modern editors work is better - have a simple, colored, "..." indicator at the end of the line that has a fold after it. Simple, easy to scan, doesn't take up any more lines on screen. Minimal, in the sense of UI.
2. Adding some kind of info in the margin. Most editors add some kind of way to see folds in the margin. This is usually kept very tight, since all you really need are some dashed-lines and a "+" sign, perhaps. Not possible with vim. The closest we have is "foldcolumn", which a) takes up a lot of space, and b) is less visually appearling, making it harder to understand or use. Other info is also sometimes added, not just folds.
3. The project opening. While I love ctrl-p, especially over the alternatives, it has several flaws. For example, it's very, noticeably, slow. And I'm on small projects, usually.
But here's the bigger issue: the way ctrl-p in Sublime works is more beautiful, but that's not the only advantage. It makes it easier to see what file you're going to open. It makes it easier by doing things like bold-ing the letters that it's matched. It makes it easier by making the filenames "REALLY BIG", but still giving you the details of the file's location in a smaller font.
There are really many more issues I can bring up, but these are the keys. In all honesty, vim is a bad choice for most people because, to get it to the level of what Sublime Text or other editors do out of the box, you have to spend months tweaking vim. This makes it irrelevant for the vast, vast majority of people, which is unfortunate, because it has text-editing capabilites that are simply unsurpassed by any other editor.
1. I've seen that "…". I think it's an horrible UI as it is always at different horizontal positions forcing me to move my eyes a lot more than necessary. That symbol is also almost completely devoid of information: the number of folded lines and a sample are often useful and I can't get that with "…". Except if I take my mouse and hover on that "…" to preview my 50 or 100 folded lines cramped in a huge ass popin. Contrast that with a regular fold in Vim: http://i.imgur.com/WXg1p.png
* it is easy to find
* it is easy to parse
* it shows the number of hidden lines
* it takes only one line
* its purpose is obvious
2. Vim as signs for errors and fold indicators, there are plugins that show marks, too. A "fold" sign in the gutter is mainly useful if it's hard to notice the fold in the editor space. Because it's hard to spot "…" folds you scan the gutter to locate folds. Because it's hard to miss a fold in vim, such an indicator is not needed. But Vim's foldcolumn not only shows the location of a fold: it provides an additional information that no right pointing triangle or boxed plus sign can show: the depth of the fold. Anyway, if you only care about seeing folds in the gutter, well… that's covered too by the simple fact that the whole line is highligted.
3. I also work on small projects (under 50/60 files without assets) and everything in CtrlP is instantaneous. We obviously have very different æsthetic preferences: I find everything in ST2 absolutely hideous. The font size tricks in ctrl+p you describe are both very arbitrary, simplistic and distracting. Vim's CtrlP shows the paths of the matched files, highlights the matched characters and systematically puts the default match at the bottom. There's nothing hard about it: simple, clear, fast… and, again, it has lots more features than its ST2 "counterpart". Not to forget Vim's native wildmenu which also shows the path and highlights your choice in a very readable manner.
I don't agree with your last paragraph as well.
I really really really don't care if or why people don't like Vim. I chose it over dozens of editors/IDE because it worked for me: not because it was fashionable, not because I mistook it for something else. I have no stake in this, I don't root for Vim, I don't want more users, I don't want less users, I just don't care if it's easier, harder or whatever. I'm perfectly fine with Vim in its current state and I'm persuaded it doesn't need any of those pseudo-refinements. Vim is the work of love of a bunch of talented programmers with an unbelievable ecosystem. It's free in every meaning of the world, it's old and a lot more powerful than any other editor, with the possible exception of Emacs. Its core developpers and, I believe, many users certainly prefer Vim as it is and don't care at all about making it easier for new users. More attention, more users… all of that is necessary for Panic, MacRabbit, Macromates or SublimeHQ because that's the only way they can survive. They desperately need differentiating "features" to attract new users or justify license upgrades and make more money: skeuomorphic UI, rounded rectangles, gradients, transitions, integration with this or that trendy language or framework and so on. None of that matters to Vim and its developers and lots of its users.
ST2's author is probably happier each time a Vim user switches to ST2 but Bram Moolenaar most certainly doesn't give a flying fuck. That's very important and that has to be considered when talking about cosmetic "enhancements" or "fixes" to Vim.
I wonder, do you agree with the statement: "If someone remade vim so that you can have variable fonts and some more gui goodness, that would be a good thing"? I'm not saying changing the core of vim. I'm saying, let plugins have more options in terms of how they draw things on-screen? Because, if it's optional, I can't see why that would bother anyone. Unless you think it is simply impossible for anything other than the plain-text, single-font way vim works to have any advantage.
We have stylistic differences, obviously. I've used both vim as my main editor, complete with a very customized .vimrc, as well as dozens of other editors (less heavily), including Sublime Text. I love vim, and it works wonders for me. But I think it's odd that you literally find nothing wrong with vim or nothing that can be improved.
As for "getting users", I understand that you personally don't care. I care only inasmuch as I think the basic way of editing text that vim gives users is so much better, that I wish more people used it. I also care because I'd love something like Sublime, with a proper vim mode that actually manages to do most of what vim does, and that doesn't exist.
> "do you agree with the statement: "If someone remade vim so that you can have variable fonts and some more gui goodness, that would be a good thing"?"
I don't think I would use it. But I'm curious by nature and I would probably try it out anyway, just like I did with all the ST2/Coda/Espresso/Vico/Chocolat/HappyEdit/Whatever that popped up in the last 2 to 3 years.
At some point in the past, I felt limited as a TextMate user and I "needed" a change which I happily found in Vim. The benefits, for me, were/are absolutely huge, but I would switch again if the benefits were comparable. Cosmetic changes are not enough for me obviously and, IMO, the things you propose would a) not provide any noticeable benefit and b) work only in GVim/MacVim which makes no sense at all considering Vim's philosophy.
But putting all of your ideas into a new project… I'd say "Go for it!". Keep in mind, though, that for a lot of Vim users the ability to run Vim in a terminal is absolutely mandatory. A shiny new GUI would be worse than useless.
The "optional" part of your comment is actually very important. Adding all those things as options would take a lot of time and effort and probably a lot of rewriting for… almost nothing.
> "But I think it's odd that you literally find nothing wrong with vim or nothing that can be improved."
I think that the problems you point out are not problems at all and thus, that they don't need fixing. Vim has a bunch of low-level limitations/problems that I would like to see fixed before making it prettier: archaic keypress handling, lack of multithreading, limited RTL support, dumb terminal in the GUI version, wonky and slow syntax engine, poor external interface…
These things are way more important, IMO, than changing the color of the bike shed.
I hated every second I spent in ST2, even more with vintage mode enabled and vintageEx installed. I really don't want Vim to go that direction and, I believe, its author doesn't want that either.
This is probably a hallmark of any sufficiently large, complex and popular software. There will be completely divergent (or at least different enough to believe themselves so) subsets of users with different use requirements. Without careful negotiation this can lead to deadlock.
Objecting to a feature enhancement that has no negative effect on your own preferred usage is probably not the best use of anyone's time. Exceptions can and should be made for changes which might accidentally affect your core usage though, such as changing the default rendering.
That said, I imagine any change in vim is going to get enough exercise that bugs will be found fairly quickly.
As for this specific feature, I imagine it would be some text hinting similar to coloring, but it would be ignored in console use, leaving gvim to do different font rendering based on hints.
I don't object out of spite. I'm certainly not the best or most experienced programmer here but I have an idea of the depth and spread of the changes that the proposed enhancements would require. The usefulness of these enhancements must be weighted against their impact on the code base and (and that's very important in Vim's case) the philosophy of the project.
Incorporating all these ideas into a new project, on the other hand…
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.
Precisely. If you want to challenge a product with massive mindshare [1], then you need new, very compelling features, and preferably be compatible with the existing ecosystem.
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 would imagine because there are many UI features that cannot be easily reproduced in the terminal and maintaining two different interfaces with very different capabilities is more trouble than it's worth.
Ideally any new system should be made UI agnostic, provided a simple default UI with few features readily accessible (perhaps accessible only though a command line of sorts), and allow users of your editor to craft their own frontends, be they TTY or web-based, or anything they may dream up in the future.
Just building the web-based editor that you want this year may be fine for this year, but I am not convinced we should be putting much effort into designing systems that don't learn from their predecessors. The classic editors can feel rickety today because they were made with the TTY, and arguably only the TTY, in mind. A system designed today should keep that in mind, and I think make future-proofing it's first and for-most concern.
I think it is also really hard to justify supporting fewer features than classical editors do today. Removing the ability to implement technical features so that you can add support for UI features seems like a step backward to me. I don't think there is much (or anything) that you couldn't add to Vim or Emacs, the question is just more along the lines of "can you make it look how you want it too". An editor designed with UI agnosticy (is that a word?) as a first class feature should not have this problem.
"Modernizing" something doesn't mean removing 80% or 90% of its features, that would be "bastardizing" or something.
Your comment seems weird to me. It sounds like "Use an underpowered tool for your everyday task but turn to a vastly more powerful tool only in some strictly defined situation."
Wouldn't it be a little more sane to go the other way: use a super powerful tool for your daily work and only turn to a far less powerful tool when there's no other choice?
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.
I'm as serious as a heart attack. Actually, it's really not the same thing at all, and I'm an English major-- I know that "vim" is a noun. But "happy" is an adjective. That's part of the reason why it's a bad name.
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_.
There's a VintageEx bundle that extends Vintage mode with more vim-ness. It still lacks vim-surround which is a no-go for me, and there are a few differences in behavior (off-by-one mostly) that constantly throw me off.
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.
This is a great example of what you can do with chrome packaged apps. Many of the APIs associated with packaged apps are not supported in the current official release of chrome, unfortunately.
I didn't realize this until now, but I get a kind of satisfaction from using the old CLI Vim because it's harder and uglier than neccessary. I could be equally productive in gEdit.
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. ;)