> It's easy to accidentally make a Vim script that consumes all memory.
If you see this often then you must be running Vim on a machine with an extremely low amount of memory. This is not the case for most users though, in the few years using Vim I never experienced this and I use some pretty heavy plugins. Even if OOM was common due to bugs in vimscript, it's not like the user will try to recover the current Vim instance without exiting. The common course of action would be to exit and remove the buggy vimscript program. Add this to the fact that not handling OOM simplifies code and you will see that it's not so weird that Neovim opted for this path. > Though I would better see NeoVim developers to add OOM testing rather then make the app crash, but this would add too much overhead for little gain because OOM is rare. Testing OOM should be easier now that Neovim abstracts all memory management functions into memory.c(for jemalloc integration). With some changes we could add a hook that simulates out of memory. But as you said, OOM is rare enough for this to have an extremely low priority. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
