7 ms·

Because vim is broken. I gave up vim after 7 years because of all the segfaults, in-extensibility and just horrible code. Some of the files in the vim code base

by leokun 13y ago

Because vim is broken. I gave up vim after 7 years because of all the segfaults, in-extensibility and just horrible code. Some of the files in the vim code base are over 20,000 lines with hundreds of ifdefs, and littered with unsafe pointer use. The code is a horrible experience to just look at, pre 1989 C style functions, mixed tabs and spaces everywhere, and the files aren't even a valid encoding of any kind whatsoever, instead it has this broken mbyte that will ruin your day if you touch a vim source file in anything but vim. If you use vim as is you may not notice much, but vim will forever be limited to responding only to user interaction with no hope of ever getting any kind of timers, async actions or event loop. Try making a simple clock for your status line that updates every second. You can't. And it will never be possible. Because vim is broken.

TallboyOne 13y ago
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.
tmhedberg 13y ago
A patch series implementing asynchronous timers has in fact recently been posted to the Vim development list [^1]. Its status is uncertain, and is still being actively discussed, but to state that such a thing "will never be possible" is just blatantly false. [^1]: https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%5B1-25-false%5D https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...
- leokun 13y ago
  Actually I know all about that patch and have commented in that thread. I tried that patch and vim segfaults. It's not the patch's fault, it's vim's fault. Checkout this response from Bram when one of the devs for that patch reveals an error: https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_dev/Mssm8pKtnGM/kgm_-j6PCXAJ https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_... It's clearly an unsafe operation that wont work with async/timed code, because the buffer may be null at that point, but Bram's response is how do you reproduce it? How do you reproduce it? It's a segfault on an unsafe pointer! It crashes vim. Anyway, the way to reproduce it and all the other segfaults I encountered is to develop a plugin using the timers in that patch. So nope, vim is broken, and that patch will never see the light of day. Those guys put months of work into that patch and Bram is like "I don't have time." His instincts are right. The patch would ruin vim for anyone using timers.
  - chrisbra10 13y ago
    > https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_.. https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_.... [...] This has been acknowledged and even patched as you surely know. So what are you complaining about exactly?
    - leokun 13y ago
      I didn't know it was patched. https://groups.google.com/forum/#!searchin/vim_dev/set_last_cursor/vim_dev/2_2o5EVhTfM/wkJwdwKr7jMJ https://groups.google.com/forum/#!searchin/vim_dev/set_last_... Cool.
Jare 13y ago
But this thing is Vim.
- leokun 13y ago
  No, it connects to vim via vim's client server mechanism. The docs for it are wrong, because it will work on OS X if you have MacVim set as your default vim because MacVim is compiled with +server. Anyway, I am quite sure this thing will run into all kinds of trouble because of how broken vim is.
  - lunixbochs 13y ago
    Nope, no +server in default OS X CLI Vim. I'm actually using a combination of their NetBeans communication protocol and raw tty output right now.
    - leokun 13y ago
      I didn't say default OS X, I said MacVim, which many Mac OS X users use. To say it doesn't work on Macs is wrong when there is MacVim.
      - lunixbochs 13y ago
        I wrote it in OS X. I'm not sure where you see "doesn't work in OS X". I said it doesn't work in Windows. Quoting the docs: "it's likely to only work in Linux and OS X for the near future" It works out of the box for me in Mavericks. It would actually have a worse time running if you managed to use MacVim on the backend, because it scrapes the status and command lines from terminal output.
        leokun 13y ago
        Oh, I misread that. Thanks and sorry.
m2mdas 13y ago
WTF are you talking about? Vim have may have many demerits but segfaults is not on that list. If segfaults are that frequent you described then people would have jumped ship already. I can't comment on the code structure of Vim but it does not matter to me because end product is working fine for me for 5+ years. Also bad code structure did not stop continuous development of Vim. Just for example there were 1000 patches added to the core before Vim version was changed from 7.3 to 7.4 within 2 years. Important features like more python binding, lua bindings were added during this time. Even if you see the current patch log of 7.4 ftp://ftp.vim.org/pub/vim/patches/7.4/README 68 patches were added since 7.4 release. Though async future is not built-in there are several plugins for doing async operation, for example vim-dispatch[1] and vimproc. Vimproc is more widely used. See Unite.vim[3] , neocomplete[4], VimShell[5] for demonstration. I would specially point to VimShell because with the help of it you can run REPL inside Vim and pass buffer content to it. Also there is YouCompleteMe[6] which provides FAST autocomplete. [1](https://github.com/tpope/vim-dispatch/ https://github.com/tpope/vim-dispatch/) [2](https://github.com/Shougo/vimproc.vim/ https://github.com/Shougo/vimproc.vim/) [3](https://github.com/Shougo/unite.vim https://github.com/Shougo/unite.vim) [4](https://github.com/Shougo/neocomplete.vim https://github.com/Shougo/neocomplete.vim) [5](https://github.com/Shougo/vimshell.vim https://github.com/Shougo/vimshell.vim) [6](https://github.com/Valloric/YouCompleteMe/ https://github.com/Valloric/YouCompleteMe/)
- leokun 13y ago
  Nope, and nope. > WTF are you talking about? Vim have may have many demerits but segfaults is not on that list. If segfaults are that frequent you described then people would have jumped ship already. Vim is all segfaults once you introduce async, and it's highly unstable during any dev work. On any given day visit the Vim dev mailing list and scroll down. Today I see: Scrolling in a c file segfaults: https://groups.google.com/forum/#!topic/vim_dev/teRV3RyDtzc https://groups.google.com/forum/#!topic/vim_dev/teRV3RyDtzc Referencing an old buffer seg faults: https://groups.google.com/forum/#!topic/vim_dev/Mssm8pKtnGM https://groups.google.com/forum/#!topic/vim_dev/Mssm8pKtnGM Segfault opening a readme: https://groups.google.com/forum/#!topic/vim_dev/SE31YUccJN4 https://groups.google.com/forum/#!topic/vim_dev/SE31YUccJN4 Segfault selecting a lot of text: https://groups.google.com/forum/#!topic/vim_dev/yzVqZ3qogho https://groups.google.com/forum/#!topic/vim_dev/yzVqZ3qogho Segfault on autocompletion: https://groups.google.com/forum/#!topic/vim_dev/lqcn57eRGGs https://groups.google.com/forum/#!topic/vim_dev/lqcn57eRGGs Segfault on tab switching: https://groups.google.com/forum/#!topic/vim_dev/Vc9Z8rfe22w https://groups.google.com/forum/#!topic/vim_dev/Vc9Z8rfe22w Just keep scrolling, the segfaults never stop. > Though async future is not built-in there are several plugins for doing async operation, for example... For your other point, some plugins fake async using a cursorhold hack that break vim for users who use leader keys. That is they insert fake key strokes. Vimproc actually quits on cursorhold: https://github.com/Shougo/vimproc.vim/blob/master/autoload/vimproc.vim#L1124 https://github.com/Shougo/vimproc.vim/blob/master/autoload/v... That's right thess plugins inserts keys to trigger autocommand. I would like you to go ahead and type a long vim command using leader keys and see if that works for you. When a plugin inserts keys while you are inserting keys everything stops and you have to start over. Go ahead, go implement a clock with a plugin that updates every second. I bet that plugin fakes user interaction. It doesn't work. Edit: Also nice on the downvotes, perhaps explain how my post is wrong in addition to downvoting. Everything I have said are matters of fact. Are my facts wrong?
duaneb 13y ago
I have no idea how you make vim crash; usually it's because I attempt to search through a multigigabyte file or something. Vim may have many issues but stability is NOT one of them.
- leokun 13y ago
  You are quite wrong, on any given day vim dev's mailing list has recent seg faults at the top of its list.
  - inDigiNeous 13y ago
    Vim is one of the software I use almost everyday. I've almost never seen it segfault. You are doing something very experimental or running some stuff that maybe is not just suitable to be used with VIM. What is this async stuff you are talking about ?
    - leokun 13y ago
      > What is this async stuff you are talking about ? Something vim cannot do, that other editors can. It's called an event loop. Vim only ever does anything based on user interaction. Sometimes you may just want to sit back and have vim do things even though you hadn't typed something recently. Like pair program remotely, have a clock, get notifications, all kinds of timed things.
      - dllthomas 13y ago
        For many of these, there are better solutions than shoving them into vim. You can easily add a clock to a hardstatus line in screen or tmux. You can also use these for pair programming, reasonably easily. Notifications are better piped through notify, so you see them even if vim hidden. This isn't to say there's no legitimate use for async processing in vim - just trying to be helpful to anyone wanting these particular things.
      - inDigiNeous 13y ago
        Okay cool, I get it. Thanks for the info. Yeah I see these could be useful in a modern environment. But nothing really beats (at least for me) the expressive way I can edit text in VIM. I would love to see some of the more modern stuff implemented into VIM, like the whole page code scroll preview from Sublime Text.
glesica 13y ago
So Vim is broken because you can't have a clock in your status line? Are you an idiot? Seriously, all that ranting and you can't come up with a single practical example of Vim being "broken" other than not being able to have a clock in your status line? I'm assuming you just made up the segfault thing because I have literally never seen that happen.
- leokun 13y ago
  The clock is a basic example of something simple vim can't do. It's not because I can't have a clock.
  - johncoltrane 13y ago
    That's a stupid example and it undermines everything sensible you said elsewhere. What about the following useful usecases? * on-the-fly syntax validation * non-blocking as-you-type completion * live results from shell commands * fast syntax highlighting * etc.
    - leokun 13y ago
      Well a clock is pretty easy to make, so an easy challenge to anyone countering me, you just change some numbers somewhere, but sure. I guess I just didn't have the imagination to think of something better while in rant mode.
angersock 13y ago
Might I suggest using the text editor for editing text? It seems rather silly to complain about missing functionality that doesn't achieve the tools core value prop.
johncoltrane 13y ago
That's a point of view. From my point of view it is a very dependable text editor with lots of room for customizability and an unparalleled text editing paradigm. How many ifdefs it has, the length of its source files or its use of pointers don't matter to me because they have zero negative effect on my workflow. I like Vim as it is, I don't feel limited in any way. The impossibility to make a clock in a text editor is not an indication that it's broken: it's a sign that you should buy a wristwatch.
deelowe 13y ago
Just asked my office mate who's been using VIM on ubuntu for probably 10 years (vim, maybe not ubuntu) now about this. He literally edits and builds code all day every day for 8+ hours. His environment is pretty simple, not many plugins, a solarized them and that's about it. He mostly develops in css, html, javascript, lots of python, and c++. Never had a segfault. This matches my experience as well. As others have said, how in the world are you having these kinds of issues?

by leokun 13y ago

TallboyOne 13y ago

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.

tmhedberg 13y ago

A patch series implementing asynchronous timers has in fact recently been posted to the Vim development list [^1]. Its status is uncertain, and is still being actively discussed, but to state that such a thing "will never be possible" is just blatantly false. [^1]: https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%5B1-25-false%5D https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

leokun 13y ago
Actually I know all about that patch and have commented in that thread. I tried that patch and vim segfaults. It's not the patch's fault, it's vim's fault. Checkout this response from Bram when one of the devs for that patch reveals an error: https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_dev/Mssm8pKtnGM/kgm_-j6PCXAJ https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_... It's clearly an unsafe operation that wont work with async/timed code, because the buffer may be null at that point, but Bram's response is how do you reproduce it? How do you reproduce it? It's a segfault on an unsafe pointer! It crashes vim. Anyway, the way to reproduce it and all the other segfaults I encountered is to develop a plugin using the timers in that patch. So nope, vim is broken, and that patch will never see the light of day. Those guys put months of work into that patch and Bram is like "I don't have time." His instincts are right. The patch would ruin vim for anyone using timers.
- chrisbra10 13y ago
  > https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_.. https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_.... [...] This has been acknowledged and even patched as you surely know. So what are you complaining about exactly?
  - leokun 13y ago
    I didn't know it was patched. https://groups.google.com/forum/#!searchin/vim_dev/set_last_cursor/vim_dev/2_2o5EVhTfM/wkJwdwKr7jMJ https://groups.google.com/forum/#!searchin/vim_dev/set_last_... Cool.

Jare 13y ago

But this thing is Vim.

leokun 13y ago
No, it connects to vim via vim's client server mechanism. The docs for it are wrong, because it will work on OS X if you have MacVim set as your default vim because MacVim is compiled with +server. Anyway, I am quite sure this thing will run into all kinds of trouble because of how broken vim is.
- lunixbochs 13y ago
  Nope, no +server in default OS X CLI Vim. I'm actually using a combination of their NetBeans communication protocol and raw tty output right now.
  - leokun 13y ago
    I didn't say default OS X, I said MacVim, which many Mac OS X users use. To say it doesn't work on Macs is wrong when there is MacVim.
    - lunixbochs 13y ago
      I wrote it in OS X. I'm not sure where you see "doesn't work in OS X". I said it doesn't work in Windows. Quoting the docs: "it's likely to only work in Linux and OS X for the near future" It works out of the box for me in Mavericks. It would actually have a worse time running if you managed to use MacVim on the backend, because it scrapes the status and command lines from terminal output.
      - leokun 13y ago
        Oh, I misread that. Thanks and sorry.

m2mdas 13y ago

WTF are you talking about? Vim have may have many demerits but segfaults is not on that list. If segfaults are that frequent you described then people would have jumped ship already. I can't comment on the code structure of Vim but it does not matter to me because end product is working fine for me for 5+ years. Also bad code structure did not stop continuous development of Vim. Just for example there were 1000 patches added to the core before Vim version was changed from 7.3 to 7.4 within 2 years. Important features like more python binding, lua bindings were added during this time. Even if you see the current patch log of 7.4 ftp://ftp.vim.org/pub/vim/patches/7.4/README 68 patches were added since 7.4 release. Though async future is not built-in there are several plugins for doing async operation, for example vim-dispatch[1] and vimproc. Vimproc is more widely used. See Unite.vim[3] , neocomplete[4], VimShell[5] for demonstration. I would specially point to VimShell because with the help of it you can run REPL inside Vim and pass buffer content to it. Also there is YouCompleteMe[6] which provides FAST autocomplete. [1](https://github.com/tpope/vim-dispatch/ https://github.com/tpope/vim-dispatch/) [2](https://github.com/Shougo/vimproc.vim/ https://github.com/Shougo/vimproc.vim/) [3](https://github.com/Shougo/unite.vim https://github.com/Shougo/unite.vim) [4](https://github.com/Shougo/neocomplete.vim https://github.com/Shougo/neocomplete.vim) [5](https://github.com/Shougo/vimshell.vim https://github.com/Shougo/vimshell.vim) [6](https://github.com/Valloric/YouCompleteMe/ https://github.com/Valloric/YouCompleteMe/)

leokun 13y ago
Nope, and nope. > WTF are you talking about? Vim have may have many demerits but segfaults is not on that list. If segfaults are that frequent you described then people would have jumped ship already. Vim is all segfaults once you introduce async, and it's highly unstable during any dev work. On any given day visit the Vim dev mailing list and scroll down. Today I see: Scrolling in a c file segfaults: https://groups.google.com/forum/#!topic/vim_dev/teRV3RyDtzc https://groups.google.com/forum/#!topic/vim_dev/teRV3RyDtzc Referencing an old buffer seg faults: https://groups.google.com/forum/#!topic/vim_dev/Mssm8pKtnGM https://groups.google.com/forum/#!topic/vim_dev/Mssm8pKtnGM Segfault opening a readme: https://groups.google.com/forum/#!topic/vim_dev/SE31YUccJN4 https://groups.google.com/forum/#!topic/vim_dev/SE31YUccJN4 Segfault selecting a lot of text: https://groups.google.com/forum/#!topic/vim_dev/yzVqZ3qogho https://groups.google.com/forum/#!topic/vim_dev/yzVqZ3qogho Segfault on autocompletion: https://groups.google.com/forum/#!topic/vim_dev/lqcn57eRGGs https://groups.google.com/forum/#!topic/vim_dev/lqcn57eRGGs Segfault on tab switching: https://groups.google.com/forum/#!topic/vim_dev/Vc9Z8rfe22w https://groups.google.com/forum/#!topic/vim_dev/Vc9Z8rfe22w Just keep scrolling, the segfaults never stop. > Though async future is not built-in there are several plugins for doing async operation, for example... For your other point, some plugins fake async using a cursorhold hack that break vim for users who use leader keys. That is they insert fake key strokes. Vimproc actually quits on cursorhold: https://github.com/Shougo/vimproc.vim/blob/master/autoload/vimproc.vim#L1124 https://github.com/Shougo/vimproc.vim/blob/master/autoload/v... That's right thess plugins inserts keys to trigger autocommand. I would like you to go ahead and type a long vim command using leader keys and see if that works for you. When a plugin inserts keys while you are inserting keys everything stops and you have to start over. Go ahead, go implement a clock with a plugin that updates every second. I bet that plugin fakes user interaction. It doesn't work. Edit: Also nice on the downvotes, perhaps explain how my post is wrong in addition to downvoting. Everything I have said are matters of fact. Are my facts wrong?

duaneb 13y ago

I have no idea how you make vim crash; usually it's because I attempt to search through a multigigabyte file or something. Vim may have many issues but stability is NOT one of them.

leokun 13y ago
You are quite wrong, on any given day vim dev's mailing list has recent seg faults at the top of its list.
- inDigiNeous 13y ago
  Vim is one of the software I use almost everyday. I've almost never seen it segfault. You are doing something very experimental or running some stuff that maybe is not just suitable to be used with VIM. What is this async stuff you are talking about ?
  - leokun 13y ago
    > What is this async stuff you are talking about ? Something vim cannot do, that other editors can. It's called an event loop. Vim only ever does anything based on user interaction. Sometimes you may just want to sit back and have vim do things even though you hadn't typed something recently. Like pair program remotely, have a clock, get notifications, all kinds of timed things.
    - dllthomas 13y ago
      For many of these, there are better solutions than shoving them into vim. You can easily add a clock to a hardstatus line in screen or tmux. You can also use these for pair programming, reasonably easily. Notifications are better piped through notify, so you see them even if vim hidden. This isn't to say there's no legitimate use for async processing in vim - just trying to be helpful to anyone wanting these particular things.
    - inDigiNeous 13y ago
      Okay cool, I get it. Thanks for the info. Yeah I see these could be useful in a modern environment. But nothing really beats (at least for me) the expressive way I can edit text in VIM. I would love to see some of the more modern stuff implemented into VIM, like the whole page code scroll preview from Sublime Text.

glesica 13y ago

So Vim is broken because you can't have a clock in your status line? Are you an idiot? Seriously, all that ranting and you can't come up with a single practical example of Vim being "broken" other than not being able to have a clock in your status line? I'm assuming you just made up the segfault thing because I have literally never seen that happen.

leokun 13y ago
The clock is a basic example of something simple vim can't do. It's not because I can't have a clock.
- johncoltrane 13y ago
  That's a stupid example and it undermines everything sensible you said elsewhere. What about the following useful usecases? * on-the-fly syntax validation * non-blocking as-you-type completion * live results from shell commands * fast syntax highlighting * etc.
  - leokun 13y ago
    Well a clock is pretty easy to make, so an easy challenge to anyone countering me, you just change some numbers somewhere, but sure. I guess I just didn't have the imagination to think of something better while in rant mode.

angersock 13y ago

Might I suggest using the text editor for editing text? It seems rather silly to complain about missing functionality that doesn't achieve the tools core value prop.

johncoltrane 13y ago

That's a point of view. From my point of view it is a very dependable text editor with lots of room for customizability and an unparalleled text editing paradigm. How many ifdefs it has, the length of its source files or its use of pointers don't matter to me because they have zero negative effect on my workflow. I like Vim as it is, I don't feel limited in any way. The impossibility to make a clock in a text editor is not an indication that it's broken: it's a sign that you should buy a wristwatch.

deelowe 13y ago

Just asked my office mate who's been using VIM on ubuntu for probably 10 years (vim, maybe not ubuntu) now about this. He literally edits and builds code all day every day for 8+ hours. His environment is pretty simple, not many plugins, a solarized them and that's about it. He mostly develops in css, html, javascript, lots of python, and c++. Never had a segfault. This matches my experience as well. As others have said, how in the world are you having these kinds of issues?