6 ms·

How much of a challenge would it be to rewrite vim properly? Or is that a crazy idea..

recuter 13y ago
Not that crazy. Vim itself is a reboot of Vi, and there were/are other minimal Vi clones that are very small (couple of KLOCs). You'd be throwing away the horrible Vimscript, and sadly the community is married to it. As a result your neat little Vim2 reboot thing will not be nearly as useful for a long time, so you've lost backwards compatibility for what? Cleaner internals? Doesn't really benefit the end user much. :)
- lightblade 13y ago
  I really don't care much about backward compatibility with existing plugins. We're using vim not the plugins anyway. I justed wanted an terminal editor with vi bindings.
  - eyko 13y ago
    As long as it can parse my .vimrc (but then, that's vimscript)
    - platz 13y ago
      Is there so much in your .vimrc that it couldn't be written in a new syntax, without that much effort? We're not talking about supporting an entire legacy software app here.
- icambron 13y ago
  Not every potential Vim user already uses it. So right, you couldn't pry Vimscript out of the hands of diehard users, but you might get a big crowd of people who aren't otherwise willing to take on Vim in the first place.
leokun 13y ago
The challenge will be in getting the crazy compatibility that vim currently has. Given the pre-1989 C style syntax it probably still compiles on the original Amiga it was developed on. That's not really a good thing unless you use an Amiga still.
kansface 13y ago
Vim is a house of cards. It relies on global state for everything; changing a global variable, calling a function, and changing it back to the original value is a common pattern. Precompiler switches also cause trouble. Nested ifdefs - inside functional calls (adding or removing arguments) are another common pattern. There is also quite a bit of copy paste. Vim supports every OS- amiga, VMS, dos to name the uncommon ones. It has bindings to nearly every scripting language including python, perl, and ruby, scheme, lua, and others. The code base is such a mess that new features are very difficult to write, but there is no incentive to fix that.
- TallboyOne 13y ago
  Not that I would want to do this, but (just so I can judge the scope of what you're saying), if someone were to start a kickstarter to rewrite it, would $100,000 be enough?
  - kansface 13y ago
    I suppose it depends on what you want to accomplish. Most of the extra baggage could be removed within a month. Fixing other things would be much much harder. For instance, Vim uses an internal byte queue to represent all input. When Vim receives keystrokes, it translates them to known sequences, sometimes combining them with previous bytes, and shoves them back into the input stream- ie, instead of using structs/unions, Vim uses raw bytes. The down side (besides the insanity of doing this in the first place) is that some sequences can never be represented unless you want a byte/multibyte sequence for every possible combination. Data is just lost. On the upside, Vim potentially saves a few bytes. No one would make that tradeoff in 2013. See https://groups.google.com/forum/#!topic/vim_dev/2bp9UdfZ63M https://groups.google.com/forum/#!topic/vim_dev/2bp9UdfZ63M for the discussion about this. Another problem for attack is that Vim uses a pile of regex hacks for syntax highlighting. Presumably, the hacks make it go faster. Of course, some things are context specific, so this gets really fucking ugly really quickly. Perhaps this wouldn't be a huge problem, but Vim also lacks the ability to run any asynchronous plugins (https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM). IE, you couldn't do the highlighting outside of Vim and apply the rules in real time. You can't run a linter in the background and highlight errors. The patch ostensibly fixes these problems, but in reality it will never be merged because of existing bugs in Vim (ie, the extension causes Vim to crash through no fault of its own). The design philosophy of Vim is that it should be embedded (not an IDE). This is fine, but Vim makes this hard because it uses global variables for everything instead of internal interfaces among other reasons. If Vim made this easy, you'd see Vim embedded into other text editors (instead of emulated or instead of using crazy pty hacks). The most useful change I could see would be dropping Vim script entirely and replacing it with a single, well known scripting language. This is somewhat in the works right now- Bram is currently in the process of better bridging the gap between python and Vim (currently, python is restricted to evaling vimscript/ex commands). Ultimately, 100K could do a bit to cleanup Vim, but that probably isn't helpful to end users. If you peruse the vim mailing list, there are quite a few topics like this- people suggesting or implementing large changes- they all get dropped. Realistically, I just see Vim stagnating.

Not that crazy. Vim itself is a reboot of Vi, and there were/are other minimal Vi clones that are very small (couple of KLOCs). You'd be throwing away the horrible Vimscript, and sadly the community is married to it. As a result your neat little Vim2 reboot thing will not be nearly as useful for a long time, so you've lost backwards compatibility for what? Cleaner internals? Doesn't really benefit the end user much. :)

lightblade 13y ago
I really don't care much about backward compatibility with existing plugins. We're using vim not the plugins anyway. I justed wanted an terminal editor with vi bindings.
- eyko 13y ago
  As long as it can parse my .vimrc (but then, that's vimscript)
  - platz 13y ago
    Is there so much in your .vimrc that it couldn't be written in a new syntax, without that much effort? We're not talking about supporting an entire legacy software app here.
icambron 13y ago
Not every potential Vim user already uses it. So right, you couldn't pry Vimscript out of the hands of diehard users, but you might get a big crowd of people who aren't otherwise willing to take on Vim in the first place.

leokun 13y ago

The challenge will be in getting the crazy compatibility that vim currently has. Given the pre-1989 C style syntax it probably still compiles on the original Amiga it was developed on. That's not really a good thing unless you use an Amiga still.

kansface 13y ago

Vim is a house of cards. It relies on global state for everything; changing a global variable, calling a function, and changing it back to the original value is a common pattern. Precompiler switches also cause trouble. Nested ifdefs - inside functional calls (adding or removing arguments) are another common pattern. There is also quite a bit of copy paste. Vim supports every OS- amiga, VMS, dos to name the uncommon ones. It has bindings to nearly every scripting language including python, perl, and ruby, scheme, lua, and others. The code base is such a mess that new features are very difficult to write, but there is no incentive to fix that.

TallboyOne 13y ago
Not that I would want to do this, but (just so I can judge the scope of what you're saying), if someone were to start a kickstarter to rewrite it, would $100,000 be enough?
- kansface 13y ago
  I suppose it depends on what you want to accomplish. Most of the extra baggage could be removed within a month. Fixing other things would be much much harder. For instance, Vim uses an internal byte queue to represent all input. When Vim receives keystrokes, it translates them to known sequences, sometimes combining them with previous bytes, and shoves them back into the input stream- ie, instead of using structs/unions, Vim uses raw bytes. The down side (besides the insanity of doing this in the first place) is that some sequences can never be represented unless you want a byte/multibyte sequence for every possible combination. Data is just lost. On the upside, Vim potentially saves a few bytes. No one would make that tradeoff in 2013. See https://groups.google.com/forum/#!topic/vim_dev/2bp9UdfZ63M https://groups.google.com/forum/#!topic/vim_dev/2bp9UdfZ63M for the discussion about this. Another problem for attack is that Vim uses a pile of regex hacks for syntax highlighting. Presumably, the hacks make it go faster. Of course, some things are context specific, so this gets really fucking ugly really quickly. Perhaps this wouldn't be a huge problem, but Vim also lacks the ability to run any asynchronous plugins (https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM). IE, you couldn't do the highlighting outside of Vim and apply the rules in real time. You can't run a linter in the background and highlight errors. The patch ostensibly fixes these problems, but in reality it will never be merged because of existing bugs in Vim (ie, the extension causes Vim to crash through no fault of its own). The design philosophy of Vim is that it should be embedded (not an IDE). This is fine, but Vim makes this hard because it uses global variables for everything instead of internal interfaces among other reasons. If Vim made this easy, you'd see Vim embedded into other text editors (instead of emulated or instead of using crazy pty hacks). The most useful change I could see would be dropping Vim script entirely and replacing it with a single, well known scripting language. This is somewhat in the works right now- Bram is currently in the process of better bridging the gap between python and Vim (currently, python is restricted to evaling vimscript/ex commands). Ultimately, 100K could do a bit to cleanup Vim, but that probably isn't helpful to end users. If you peruse the vim mailing list, there are quite a few topics like this- people suggesting or implementing large changes- they all get dropped. Realistically, I just see Vim stagnating.