15 ms·

Questions with Vim’s Creator, Bram Moolenaar

195 points by ProfDreamer 12y ago

Reebles 12y ago
Not sure why Bram doesn't believe that removing support for obsolete OSes such as MS-DOS, Amiga, and BeOs helps with Neovim's goal of simplifying the codebase and maintenance. Are there even any actual users of these systems that are disappointed that they won't be able to use neovim? If they're satisfied on those OSes surely they'd be satisfied with legacy vim.
- teacup50 12y ago
  Bulk churn is the kind of easy task that gives the impression of progress while providing very little actual value. In 8 months, here's what NeoVim has done: 1) Reformatted all the code. 2) Deleted a lot of working, old code. 3) Raised a good chunk of cash. 4) Published a very shiny website. 5) Released nothing. There's nothing wrong with simplifying a code base, but if you run around trying to do that independent of any reasonable technical direction, you're just making noise. Given that NeoVim's technical direction is extremely poorly considered (while also disparaging Bram's work), I can't help but think highly of Bram for being polite -- at all -- to such a disrespectful fork.
  - sondr3 12y ago
    I don't really see any problems here, they haven't made any promises either to release anything either before they are up to speed with where they want to be, just looking at their Github repo shows that there's a lot of activity going on. I'm really looking forward to seeing where they are going. In eight months things may have changed drastically, who knows, but I think that NeoVIM is going to be great. Besides, this is a bit like complaining about vim being a fork of vi, it's how things goes with open source software.
    - hjek 12y ago
      original vi was not free software. vim is a clone, not a fork.
      - sondr3 12y ago
        In that case I stand corrected on that point, however I still feel like it's a bit of the same thing. :)
  - dennyabraham 12y ago
    neovim is in the process of several major under-the-hood refactorings to enable larger scale changes. If it's not immediately apparent to you what the team is working on, you can see the project goals and progress thereupon on the project tracker. https://waffle.io/neovim/neovim https://waffle.io/neovim/neovim
  - kev6168 12y ago
    How is forking an open source project disrespectful? For the past eight months I have only seen Neovim folks being very professional, open, and quick to respond to user input. They have been keeping their heads down quietly working on extremely hard problems. Natively supporting Lua/LuaJIT and Python in writing asynchronous plugins, this alone is worth the wait. I am willing to give them A LOT MORE than 8 months if they can pull just this single feature off. The request for Python integration has been sitting at the top of Vim's voting list for many years. It must be a very very difficult task, otherwise it could be done years ago. http://www.vim.org/sponsor/vote_results.php/ http://www.vim.org/sponsor/vote_results.php/ Other than the new plugin infrastructure, Neovim's GUI and embedding systems will be awesome. Anyway, I applaud people who explore and try to make progress (like from Vi to Vim, a natural process). In the mean time, I am happily using Vim which is both extremely powerful and stable. TL,DR; I can wait.
    - btipling 12y ago
      > For the past eight months I have only seen Neovim folks being very professional, open, and quick to respond to user input. They've done even more than that. They have gone to great lengths to be helpful. For example, tarruda created an issue on our own issue tracker to let us know they updated their python plugin architecture so that we could fix our Neovim plugin. He didn't have to do this. https://github.com/Floobits/floobits-neovim/issues/10 https://github.com/Floobits/floobits-neovim/issues/10 tarruda has shown himself to be a very productive engineer and a great steward of a growing Neovim community. Our experience with Neovim and Vim has been night and day. The reality is that with Neovim you can build plugins that do more than you can with vim, painlessly. I don't really want it to be a vim versus neovim thing, but Bram strikes me as someone who at the very least doesn't understand Neovim's goals. I certainly hope that Neovim's changes are not backported into vim, Neovim is much more open about contributions whereas with vim there's a single gatekeeper with limited time to address big changes.
      - deleted 12y ago
        [deleted]
      - PieSquared 12y ago
  - jballanc 12y ago
    > 5) Released nothing. I've been tracking the neovim repo for a while, and my feeling is that they could have easily made a couple of releases with stability matching some other notable projects, but they have intentionally chosen to be conservative and wait. If you want an example of one area where there has been work and improvement, check out the Wiki page on the updated clipboard integration: https://github.com/neovim/neovim/wiki/Python-plugins,-clipboard-integration-and-other-service-providers-through-msgpack-RPC-channels https://github.com/neovim/neovim/wiki/Python-plugins,-clipbo... . Yeah, it's different, and not yet as capable as Vim's built-in clipboard integration. But if they are headed toward a goal of more generalized integration points, then this is a strong step in the right direction.
  - deleted 12y ago
    [deleted]
  - ggreer 12y ago
    Your comment seems to consist of some things that aren't true, and some true things accompanied with baseless insinuations. 1. The code was reformatted because Vim's codebase is a mess. It mixes tabs and spaces willy-nilly. It uses different indentation rules in different parts of files. These issues may seem cosmetic, but they make the code harder to follow and increase the likelihood of bugs. Indentation can be especially misleading when control flow lacks braces (a common occurrence in Vim). The change didn't require much effort and it made it easier for people to contribute to Neovim. 2. Actually, quite a bit of Vim's old platform-specific code is broken. It's just that nobody uses an SGI IRIS or Amiga, so nobody complains about it. In some cases, Neovim removed ifdef'd code that could never possibly be included[1]. 3. People have donated less than $40k to Neovim. That's not even the salary of a single developer for the 8 months it's been around. The contributors aren't in it for the money. They simply want to build a great editor. 4. A very shiny website? It's just static pages hosted on Github. If you look at the commit history[2], you can see it's insignificant compared to work done on the Neovim codebase. 5. Nothing? There's an entire repository of working code. Right now you can clone Neovim, compile it, and it will run almost all Vim plugins without issue. The team is very conservative about declaring software stable. They may not have a tagged release, but to call the existing work "nothing" is unreasonable. It's at least as stable as Atom. You also neglected to mention all the other work done on Neovim, such as replacing ad-hoc cross-platform compatibility and event handling with libuv. Then there's the improved plugin APIs which allow features that aren't possible in Vim.[3] And of course, plugins can be written in any language. No more VimL shims needed. Lastly: Disparaging? Disrespectful? It's hard to find any criticism the Neovim contributors have made towards Bram or Vim. They like Bram. They like Vim. Thiago tried to contribute to Vim multiple times, but was discouraged or ignored.[4][5] Instead of complaining or giving up, he and the other contributors are trying to improve the editor and the community around it. There's no malice or greed involved. 1. https://github.com/neovim/neovim/pull/814 https://github.com/neovim/neovim/pull/814 2. https://github.com/neovim/neovim.github.io/ https://github.com/neovim/neovim.github.io/ 3. https://github.com/benekastah/neomake https://github.com/benekastah/neomake 4. https://groups.google.com/d/msg/vim_dev/QF7Bzh1YABU/02-YGr7_sCwJ https://groups.google.com/d/msg/vim_dev/QF7Bzh1YABU/02-YGr7_... 5. https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIBwNAJ https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIB...
  - sbilstein 12y ago
    I often refer to these two pieces when debating rebooting a project from scratch: Joel Spolksy Things You Should Never Do Part 1 http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html Darmesh Shah How To Survive a Ground-Up Rewrite Without Losing Your Sanity (a response to essay #1 13 years later) http://onstartups.com/tabid/3339/bid/97052/How-To-Survive-a-Ground-Up-Rewrite-Without-Losing-Your-Sanity.aspx http://onstartups.com/tabid/3339/bid/97052/How-To-Survive-a-... It's not always cut and dry when you should start over, but if you are make sure you are doing it in a way that starts presenting customer/user value ASAP.
- SamReidHughes 12y ago
  Are you familiar with Vim's code? How is support for those OSes making things substantially more complicated?
  - ggreer 12y ago
    Are you familiar with Vim's code? Just look at all the OS-specific files in the source tree[1]. Not only that, there are ifdefs-galore in the shared code. RealWaitForChar is over 400 lines and contains 41 ifdefs.[2] Many are for long-dead features or platforms. That function just waits for user input, but it has to be ridiculously complicated to account for platforms without basic functions like select(). The infamous eval.c starts off with ifdefs for Amiga, VMS, and Mac OS Classic.[3] Neovim has ripped out tons of this stuff, and it's drastically reduced line count. 1. https://github.com/b4winckler/macvim/tree/master/src https://github.com/b4winckler/macvim/tree/master/src 2. https://github.com/b4winckler/macvim/blob/master/src/os_unix.c#L5222 https://github.com/b4winckler/macvim/blob/master/src/os_unix... 3. https://github.com/b4winckler/macvim/blob/master/src/eval.c https://github.com/b4winckler/macvim/blob/master/src/eval.c
    - dllthomas 12y ago
      I think the parent can be read as an honest request for more details. It doesn't need to be met with snark. (Don't take this too harshly - the content in your post is good.)
    - SamReidHughes 12y ago
      How does this stuff get in the way of the features that NeoVim intends to add? -- features they list such as "job control", a msgpack remote API, or a new plugin architecture. (I don't really expect you to be capable of answering this question unless you're familiar enough with the code to give an operational description of how these ifdefs get in the way.)
  - coldtea 12y ago
    You don't have to be familiar with Vim's code to know that having support for obsolete OSes makes the code substantially more complicated.
- johncoltrane 12y ago
  That's not what he said. He said that Neovim's goals could be achieved without cutting out features and removing supports for exotic OSes.
  - coldtea 12y ago
    >He said that Neovim's goals could be achieved without cutting out features and removing supports for exotic OSes. That's the same as what parent said. Neovim's #1 goal (from the webpage) is: "Neovim is a project that seeks to aggressively refactor Vim in order to simplify maintenance and encourage contributions". And other goals including adding new features for the future. You might not 100% HAVE to drop "supports for exotic OSes" for that, but is extremely logical, and very much helpful in that direction. Anything that reduces code size makes it easier for maintanance. You don't want to have to check how things play for those IFDEFS for Amiga OS when you write code for 2014.
    - wojt_eu 12y ago
      Dropping support for exotic OSes frees you from having to test on that OSes.
    - Argorak 12y ago
      Given that the statement is very short, I'd expect that cutting out features is the point Brad puts more weight on. For example, Neovim has plans to remove ex: https://github.com/neovim/neovim/issues/1089 https://github.com/neovim/neovim/issues/1089 Exotic is also a matter of definition, there are still applications in use on those oses, and supporting them is a service to those that have to work in them. Not everyone is building apps for Heroku deployment nowadays.
      - oblio 12y ago
        While true, many of those OSes are not updated anymore. So good old Vim (4, 5, 6, 7) will serve them just fine. More than that, several of them (Amiga, BeOS, etc.) run on underpowered machines so the latest and greatest Vim updates won't run on them anyway. We could say that they're well served by Vim 5, for example. In your concrete example of a feature being removed, Neovim is actually removing a misfeature: the interactive ex mode, not the command line ex mode. The feature they're removing is akin to: http://xkcd.com/1172/ http://xkcd.com/1172/.
jvm 12y ago
> 8: How can the community ensure that the Vim project succeeds for the foreseeable future? > > Keep me alive. :-) Odd to express narcissism in response to this question. I have no idea whether NeoVim is going in the right direction but the feeling you get from this response is that Bram is focused on guarding his turf rather than thinking constructively about how to move Vim forward.
- rbonvall 12y ago
  I'm sure it was just a playful response. In case anyone doesn't know, this is Vim's license: ”Vim is Charityware. You can use and copy it as much as you like, but you are encouraged to make a donation for needy children in Uganda.” Hard to believe the guy is narcissistic at all :)
  - razammataz 12y ago
    Note that Bram is the treasurer of said charity. You can read their latest financial report here: http://iccf-holland.org/jaarrekening2013en.pdf http://iccf-holland.org/jaarrekening2013en.pdf
    - x0x0 12y ago
      and note this: We aim at very low costs. The goal is to limit the costs to 5% of the revenue. The revenue and expenses show that the costs in 2013 were only 0.5% of the total revenue. This is within the goal by a large margin. The largest parts of the costs are unavoidable banking costs. That is an exceptionally frugal charity; lots of charity monitoring sites seem to think that over 80% is doing well.
      - noir_lord 12y ago
        Incredible, I don't use Vim very much (once in a while) but I think I'll make a donation when I get paid just for the times when I do.
- imron 12y ago
pherocity_ 12y ago
I can't help but feel, since many of the same arguments against neovim could be said of the rewrite from vi to vim, that this is the natural order of things and the point of open source.
- DontGiveTwoFlux 12y ago
  Wasn't vi closed source until Bram came along? Then the name just got changed to vim because of the additions along the way?
  - stsp 12y ago
    vi history in BSD goes back to 1980 Sources are at http://svnweb.freebsd.org/csrg/usr.bin/ex/ http://svnweb.freebsd.org/csrg/usr.bin/ex/
    - cpach 12y ago
      It’s pretty amazing to browse code repos that go back over 25 years. Does anyone know which version control system they (BSD) used back then? SCCS?
      - oblio 12y ago
        More likely a file server somewhere, email and patches. After all Linux didn't use a SCM until quite late.
        the_why_of_y 12y ago
        That's because Linus had the fairly unique position that CVS et al. are actually worse than not using a SCM at all. The BSDs have been using CVS for a long time so it's plausible they used something like RCS or SCCS before CVS was available. FreeBSD repo goes back to 1993: https://svnweb.freebsd.org/base?view=revision&revision=2 https://svnweb.freebsd.org/base?view=revision&revision=2
      - makomk 12y ago
adambenayoun 12y ago
If you liked this interview - make sure to check the other podcasts we recorded: http://www.binpress.com/blog/category/podcast/ http://www.binpress.com/blog/category/podcast/
andyl 12y ago
It's unfortunate that Bram isn't more enthusiastic about NeoVim - it looks to me like they have made great progress and gathering momentum. NeoVim's support for Lua, Ruby and Python plugins, embeddable core would be a big step forward.
coldtea 12y ago
>No idea. Some of the basic choices seem odd and irrelevant for the main goals. Such as dropping support for some systems and not being backwards compatible. The goals could just as well been implemented without that. How are those steps "odd and irrelevant"? Dropping support for BS OS makes the code leaner and cleaner, and easier to update.
hyp0 12y ago
persistent undo seems pretty cool! enable with :set undofile in .vimrc NB: if you want to specify a dir for it, you need to create it yourself, or it silently won't work. eg mkdir ~/.vim/undodir, then in .vimrc :set undodir=~/.vim/undodir I also love the idea of undotree, with branches etc, but found it too confusing in practice. Could the UI be more git-like, I wonder?
- hf 12y ago
  As with many of Vim's questionable but ultimately effective interface decisions, I have found 'chronological undo' to alleviate all my undo-tree-related pains: Step through the undo tree sequentially with 'g+' and 'g-' until you've found what you're looking for.
  - hyp0 12y ago
    whoa, just tried it, works and makes sense! It just undoes everything, including undos; but not g-/g+ themselves (which are purely browsing). Nice SO ans: http://stackoverflow.com/questions/1088864/how-is-vims-undo-tree-used http://stackoverflow.com/questions/1088864/how-is-vims-undo-...
- certainly_not 12y ago
  undotree only becomes usable once you install https://github.com/sjl/gundo.vim https://github.com/sjl/gundo.vim It's a lifesaver after that.
  - thebelal 12y ago
    Completely agree with this. I actually think vims undo tree might be the most useful feature in vim for me. You can basically use it as version control lite with automatic commits.
  - alwillis 12y ago
    You took the words right out of my mouth. Gundo is great.
- 12y ago
tempodox 12y ago
Spoiler alert: I won't say anything about NeoVim. From the article: Write nice code. Use white space properly, use good names for methods, add comments to explain anything that isn’t obvious... I do wish more people subscribed to that notion, even if it doesn't sound like the magic recipe to become the next rockstar ninja. (Edit: Cloning the Zombie of Obscure Comment Formatting)
unfunco 12y ago
My favourite question and answer from this is the last one. Q: "What does the future hold for Vim?" – A: "Nothing spectacular." That's quite a refreshing view, I don't think a person exists that has mastered Vim absolutely, who knows the most efficient way to achieve everything they need to. It probably takes just as long to master Vim than it has for Vim to be developed to where it is, and it's good to see that there's a focus on improving the existing functionality than extending it further.
- segmondy 12y ago
  Just because you haven't doesn't mean others haven't. You will be surprised.
  - Bjartr 12y ago
    I think his statement there is more an observation about how every time a discussion about some less used vim feature comes up there is invariably at least one person to say "I've been using vim for x decades and never knew this".
alwillis 12y ago
We as developers and open source advocates have to get over this "thou shall not ever remove code" no matter how old and useless it may be. What the NeoVim team is doing sounds a whole lot like what the libressl team did when they forked OpenSSL, which also had tons of code for obsolete operating systems. At the point of this presentation[1], they removed 90,000 lines of code; it's probably more now. Unlike system software like OpenSSL, Vim is something I (and many developers) spend many hours each day using. In 2014, there's no good reason why it shouldn't be as responsive and flexible as possible. Sometimes when my projects get large and have lots of files open and Vim starts to slowdown just a little, you can almost feel the decades of technical debt taking its toll. As someone mentioned previously, the function that waits for user input [2] is 400 lines long and has more the 41 ifdefs, many for operating systems that have been long dead. Interestingly enough, it's because of the growing popularity of Vim that this is becoming more of an issue. I live in the Boston area and have visited many startups; Vim is quite popular among them. Yes, it's a little hipster, but in a good way. ;-) We have lots of seasoned developers at our Vim meetup [3] of course, but there are way more younger people who've discovered Vim. The room is usually packed. 1. http://www.openbsd.org/papers/bsdcan14-libressl/mgp00026.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00026.htm... 2. https://github.com/b4winckler/macvim/blob/master/src/os_unix.c#L5222 https://github.com/b4winckler/macvim/blob/master/src/os_unix... 3. http://www.meetup.com/The-Boston-Vim-Meetup/ http://www.meetup.com/The-Boston-Vim-Meetup/

195 points by ProfDreamer 12y ago

Not sure why Bram doesn't believe that removing support for obsolete OSes such as MS-DOS, Amiga, and BeOs helps with Neovim's goal of simplifying the codebase and maintenance. Are there even any actual users of these systems that are disappointed that they won't be able to use neovim? If they're satisfied on those OSes surely they'd be satisfied with legacy vim.

teacup50 12y ago
Bulk churn is the kind of easy task that gives the impression of progress while providing very little actual value. In 8 months, here's what NeoVim has done: 1) Reformatted all the code. 2) Deleted a lot of working, old code. 3) Raised a good chunk of cash. 4) Published a very shiny website. 5) Released nothing. There's nothing wrong with simplifying a code base, but if you run around trying to do that independent of any reasonable technical direction, you're just making noise. Given that NeoVim's technical direction is extremely poorly considered (while also disparaging Bram's work), I can't help but think highly of Bram for being polite -- at all -- to such a disrespectful fork.
- sondr3 12y ago
  I don't really see any problems here, they haven't made any promises either to release anything either before they are up to speed with where they want to be, just looking at their Github repo shows that there's a lot of activity going on. I'm really looking forward to seeing where they are going. In eight months things may have changed drastically, who knows, but I think that NeoVIM is going to be great. Besides, this is a bit like complaining about vim being a fork of vi, it's how things goes with open source software.
  - hjek 12y ago
    original vi was not free software. vim is a clone, not a fork.
    - sondr3 12y ago
      In that case I stand corrected on that point, however I still feel like it's a bit of the same thing. :)
- dennyabraham 12y ago
  neovim is in the process of several major under-the-hood refactorings to enable larger scale changes. If it's not immediately apparent to you what the team is working on, you can see the project goals and progress thereupon on the project tracker. https://waffle.io/neovim/neovim https://waffle.io/neovim/neovim
- kev6168 12y ago
  How is forking an open source project disrespectful? For the past eight months I have only seen Neovim folks being very professional, open, and quick to respond to user input. They have been keeping their heads down quietly working on extremely hard problems. Natively supporting Lua/LuaJIT and Python in writing asynchronous plugins, this alone is worth the wait. I am willing to give them A LOT MORE than 8 months if they can pull just this single feature off. The request for Python integration has been sitting at the top of Vim's voting list for many years. It must be a very very difficult task, otherwise it could be done years ago. http://www.vim.org/sponsor/vote_results.php/ http://www.vim.org/sponsor/vote_results.php/ Other than the new plugin infrastructure, Neovim's GUI and embedding systems will be awesome. Anyway, I applaud people who explore and try to make progress (like from Vi to Vim, a natural process). In the mean time, I am happily using Vim which is both extremely powerful and stable. TL,DR; I can wait.
  - btipling 12y ago
    > For the past eight months I have only seen Neovim folks being very professional, open, and quick to respond to user input. They've done even more than that. They have gone to great lengths to be helpful. For example, tarruda created an issue on our own issue tracker to let us know they updated their python plugin architecture so that we could fix our Neovim plugin. He didn't have to do this. https://github.com/Floobits/floobits-neovim/issues/10 https://github.com/Floobits/floobits-neovim/issues/10 tarruda has shown himself to be a very productive engineer and a great steward of a growing Neovim community. Our experience with Neovim and Vim has been night and day. The reality is that with Neovim you can build plugins that do more than you can with vim, painlessly. I don't really want it to be a vim versus neovim thing, but Bram strikes me as someone who at the very least doesn't understand Neovim's goals. I certainly hope that Neovim's changes are not backported into vim, Neovim is much more open about contributions whereas with vim there's a single gatekeeper with limited time to address big changes.
    - deleted 12y ago
      [deleted]
    - PieSquared 12y ago
- jballanc 12y ago
  > 5) Released nothing. I've been tracking the neovim repo for a while, and my feeling is that they could have easily made a couple of releases with stability matching some other notable projects, but they have intentionally chosen to be conservative and wait. If you want an example of one area where there has been work and improvement, check out the Wiki page on the updated clipboard integration: https://github.com/neovim/neovim/wiki/Python-plugins,-clipboard-integration-and-other-service-providers-through-msgpack-RPC-channels https://github.com/neovim/neovim/wiki/Python-plugins,-clipbo... . Yeah, it's different, and not yet as capable as Vim's built-in clipboard integration. But if they are headed toward a goal of more generalized integration points, then this is a strong step in the right direction.
- deleted 12y ago
  [deleted]
- ggreer 12y ago
  Your comment seems to consist of some things that aren't true, and some true things accompanied with baseless insinuations. 1. The code was reformatted because Vim's codebase is a mess. It mixes tabs and spaces willy-nilly. It uses different indentation rules in different parts of files. These issues may seem cosmetic, but they make the code harder to follow and increase the likelihood of bugs. Indentation can be especially misleading when control flow lacks braces (a common occurrence in Vim). The change didn't require much effort and it made it easier for people to contribute to Neovim. 2. Actually, quite a bit of Vim's old platform-specific code is broken. It's just that nobody uses an SGI IRIS or Amiga, so nobody complains about it. In some cases, Neovim removed ifdef'd code that could never possibly be included[1]. 3. People have donated less than $40k to Neovim. That's not even the salary of a single developer for the 8 months it's been around. The contributors aren't in it for the money. They simply want to build a great editor. 4. A very shiny website? It's just static pages hosted on Github. If you look at the commit history[2], you can see it's insignificant compared to work done on the Neovim codebase. 5. Nothing? There's an entire repository of working code. Right now you can clone Neovim, compile it, and it will run almost all Vim plugins without issue. The team is very conservative about declaring software stable. They may not have a tagged release, but to call the existing work "nothing" is unreasonable. It's at least as stable as Atom. You also neglected to mention all the other work done on Neovim, such as replacing ad-hoc cross-platform compatibility and event handling with libuv. Then there's the improved plugin APIs which allow features that aren't possible in Vim.[3] And of course, plugins can be written in any language. No more VimL shims needed. Lastly: Disparaging? Disrespectful? It's hard to find any criticism the Neovim contributors have made towards Bram or Vim. They like Bram. They like Vim. Thiago tried to contribute to Vim multiple times, but was discouraged or ignored.[4][5] Instead of complaining or giving up, he and the other contributors are trying to improve the editor and the community around it. There's no malice or greed involved. 1. https://github.com/neovim/neovim/pull/814 https://github.com/neovim/neovim/pull/814 2. https://github.com/neovim/neovim.github.io/ https://github.com/neovim/neovim.github.io/ 3. https://github.com/benekastah/neomake https://github.com/benekastah/neomake 4. https://groups.google.com/d/msg/vim_dev/QF7Bzh1YABU/02-YGr7_sCwJ https://groups.google.com/d/msg/vim_dev/QF7Bzh1YABU/02-YGr7_... 5. https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIBwNAJ https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIB...
- sbilstein 12y ago
  I often refer to these two pieces when debating rebooting a project from scratch: Joel Spolksy Things You Should Never Do Part 1 http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html Darmesh Shah How To Survive a Ground-Up Rewrite Without Losing Your Sanity (a response to essay #1 13 years later) http://onstartups.com/tabid/3339/bid/97052/How-To-Survive-a-Ground-Up-Rewrite-Without-Losing-Your-Sanity.aspx http://onstartups.com/tabid/3339/bid/97052/How-To-Survive-a-... It's not always cut and dry when you should start over, but if you are make sure you are doing it in a way that starts presenting customer/user value ASAP.
SamReidHughes 12y ago
Are you familiar with Vim's code? How is support for those OSes making things substantially more complicated?
- ggreer 12y ago
  Are you familiar with Vim's code? Just look at all the OS-specific files in the source tree[1]. Not only that, there are ifdefs-galore in the shared code. RealWaitForChar is over 400 lines and contains 41 ifdefs.[2] Many are for long-dead features or platforms. That function just waits for user input, but it has to be ridiculously complicated to account for platforms without basic functions like select(). The infamous eval.c starts off with ifdefs for Amiga, VMS, and Mac OS Classic.[3] Neovim has ripped out tons of this stuff, and it's drastically reduced line count. 1. https://github.com/b4winckler/macvim/tree/master/src https://github.com/b4winckler/macvim/tree/master/src 2. https://github.com/b4winckler/macvim/blob/master/src/os_unix.c#L5222 https://github.com/b4winckler/macvim/blob/master/src/os_unix... 3. https://github.com/b4winckler/macvim/blob/master/src/eval.c https://github.com/b4winckler/macvim/blob/master/src/eval.c
  - dllthomas 12y ago
    I think the parent can be read as an honest request for more details. It doesn't need to be met with snark. (Don't take this too harshly - the content in your post is good.)
  - SamReidHughes 12y ago
    How does this stuff get in the way of the features that NeoVim intends to add? -- features they list such as "job control", a msgpack remote API, or a new plugin architecture. (I don't really expect you to be capable of answering this question unless you're familiar enough with the code to give an operational description of how these ifdefs get in the way.)
- coldtea 12y ago
  You don't have to be familiar with Vim's code to know that having support for obsolete OSes makes the code substantially more complicated.
johncoltrane 12y ago
That's not what he said. He said that Neovim's goals could be achieved without cutting out features and removing supports for exotic OSes.
- coldtea 12y ago
  >He said that Neovim's goals could be achieved without cutting out features and removing supports for exotic OSes. That's the same as what parent said. Neovim's #1 goal (from the webpage) is: "Neovim is a project that seeks to aggressively refactor Vim in order to simplify maintenance and encourage contributions". And other goals including adding new features for the future. You might not 100% HAVE to drop "supports for exotic OSes" for that, but is extremely logical, and very much helpful in that direction. Anything that reduces code size makes it easier for maintanance. You don't want to have to check how things play for those IFDEFS for Amiga OS when you write code for 2014.
  - wojt_eu 12y ago
    Dropping support for exotic OSes frees you from having to test on that OSes.
  - Argorak 12y ago
    Given that the statement is very short, I'd expect that cutting out features is the point Brad puts more weight on. For example, Neovim has plans to remove ex: https://github.com/neovim/neovim/issues/1089 https://github.com/neovim/neovim/issues/1089 Exotic is also a matter of definition, there are still applications in use on those oses, and supporting them is a service to those that have to work in them. Not everyone is building apps for Heroku deployment nowadays.
    - oblio 12y ago
      While true, many of those OSes are not updated anymore. So good old Vim (4, 5, 6, 7) will serve them just fine. More than that, several of them (Amiga, BeOS, etc.) run on underpowered machines so the latest and greatest Vim updates won't run on them anyway. We could say that they're well served by Vim 5, for example. In your concrete example of a feature being removed, Neovim is actually removing a misfeature: the interactive ex mode, not the command line ex mode. The feature they're removing is akin to: http://xkcd.com/1172/ http://xkcd.com/1172/.

jvm 12y ago

> 8: How can the community ensure that the Vim project succeeds for the foreseeable future? > > Keep me alive. :-) Odd to express narcissism in response to this question. I have no idea whether NeoVim is going in the right direction but the feeling you get from this response is that Bram is focused on guarding his turf rather than thinking constructively about how to move Vim forward.

rbonvall 12y ago
I'm sure it was just a playful response. In case anyone doesn't know, this is Vim's license: ”Vim is Charityware. You can use and copy it as much as you like, but you are encouraged to make a donation for needy children in Uganda.” Hard to believe the guy is narcissistic at all :)
- razammataz 12y ago
  Note that Bram is the treasurer of said charity. You can read their latest financial report here: http://iccf-holland.org/jaarrekening2013en.pdf http://iccf-holland.org/jaarrekening2013en.pdf
  - x0x0 12y ago
    and note this: We aim at very low costs. The goal is to limit the costs to 5% of the revenue. The revenue and expenses show that the costs in 2013 were only 0.5% of the total revenue. This is within the goal by a large margin. The largest parts of the costs are unavoidable banking costs. That is an exceptionally frugal charity; lots of charity monitoring sites seem to think that over 80% is doing well.
    - noir_lord 12y ago
      Incredible, I don't use Vim very much (once in a while) but I think I'll make a donation when I get paid just for the times when I do.
imron 12y ago

pherocity_ 12y ago

I can't help but feel, since many of the same arguments against neovim could be said of the rewrite from vi to vim, that this is the natural order of things and the point of open source.

DontGiveTwoFlux 12y ago
Wasn't vi closed source until Bram came along? Then the name just got changed to vim because of the additions along the way?
- stsp 12y ago
  vi history in BSD goes back to 1980 Sources are at http://svnweb.freebsd.org/csrg/usr.bin/ex/ http://svnweb.freebsd.org/csrg/usr.bin/ex/
  - cpach 12y ago
    It’s pretty amazing to browse code repos that go back over 25 years. Does anyone know which version control system they (BSD) used back then? SCCS?
    - oblio 12y ago
      More likely a file server somewhere, email and patches. After all Linux didn't use a SCM until quite late.
      - the_why_of_y 12y ago
        That's because Linus had the fairly unique position that CVS et al. are actually worse than not using a SCM at all. The BSDs have been using CVS for a long time so it's plausible they used something like RCS or SCCS before CVS was available. FreeBSD repo goes back to 1993: https://svnweb.freebsd.org/base?view=revision&revision=2 https://svnweb.freebsd.org/base?view=revision&revision=2
    - makomk 12y ago

adambenayoun 12y ago

If you liked this interview - make sure to check the other podcasts we recorded: http://www.binpress.com/blog/category/podcast/ http://www.binpress.com/blog/category/podcast/

andyl 12y ago

It's unfortunate that Bram isn't more enthusiastic about NeoVim - it looks to me like they have made great progress and gathering momentum. NeoVim's support for Lua, Ruby and Python plugins, embeddable core would be a big step forward.

coldtea 12y ago

>No idea. Some of the basic choices seem odd and irrelevant for the main goals. Such as dropping support for some systems and not being backwards compatible. The goals could just as well been implemented without that. How are those steps "odd and irrelevant"? Dropping support for BS OS makes the code leaner and cleaner, and easier to update.

hyp0 12y ago

persistent undo seems pretty cool! enable with :set undofile in .vimrc NB: if you want to specify a dir for it, you need to create it yourself, or it silently won't work. eg mkdir ~/.vim/undodir, then in .vimrc :set undodir=~/.vim/undodir I also love the idea of undotree, with branches etc, but found it too confusing in practice. Could the UI be more git-like, I wonder?

hf 12y ago
As with many of Vim's questionable but ultimately effective interface decisions, I have found 'chronological undo' to alleviate all my undo-tree-related pains: Step through the undo tree sequentially with 'g+' and 'g-' until you've found what you're looking for.
- hyp0 12y ago
  whoa, just tried it, works and makes sense! It just undoes everything, including undos; but not g-/g+ themselves (which are purely browsing). Nice SO ans: http://stackoverflow.com/questions/1088864/how-is-vims-undo-tree-used http://stackoverflow.com/questions/1088864/how-is-vims-undo-...
certainly_not 12y ago
undotree only becomes usable once you install https://github.com/sjl/gundo.vim https://github.com/sjl/gundo.vim It's a lifesaver after that.
- thebelal 12y ago
  Completely agree with this. I actually think vims undo tree might be the most useful feature in vim for me. You can basically use it as version control lite with automatic commits.
- alwillis 12y ago
  You took the words right out of my mouth. Gundo is great.
12y ago

tempodox 12y ago

Spoiler alert: I won't say anything about NeoVim. From the article: Write nice code. Use white space properly, use good names for methods, add comments to explain anything that isn’t obvious... I do wish more people subscribed to that notion, even if it doesn't sound like the magic recipe to become the next rockstar ninja. (Edit: Cloning the Zombie of Obscure Comment Formatting)

unfunco 12y ago

My favourite question and answer from this is the last one. Q: "What does the future hold for Vim?" – A: "Nothing spectacular." That's quite a refreshing view, I don't think a person exists that has mastered Vim absolutely, who knows the most efficient way to achieve everything they need to. It probably takes just as long to master Vim than it has for Vim to be developed to where it is, and it's good to see that there's a focus on improving the existing functionality than extending it further.

segmondy 12y ago
Just because you haven't doesn't mean others haven't. You will be surprised.
- Bjartr 12y ago
  I think his statement there is more an observation about how every time a discussion about some less used vim feature comes up there is invariably at least one person to say "I've been using vim for x decades and never knew this".

alwillis 12y ago

We as developers and open source advocates have to get over this "thou shall not ever remove code" no matter how old and useless it may be. What the NeoVim team is doing sounds a whole lot like what the libressl team did when they forked OpenSSL, which also had tons of code for obsolete operating systems. At the point of this presentation[1], they removed 90,000 lines of code; it's probably more now. Unlike system software like OpenSSL, Vim is something I (and many developers) spend many hours each day using. In 2014, there's no good reason why it shouldn't be as responsive and flexible as possible. Sometimes when my projects get large and have lots of files open and Vim starts to slowdown just a little, you can almost feel the decades of technical debt taking its toll. As someone mentioned previously, the function that waits for user input [2] is 400 lines long and has more the 41 ifdefs, many for operating systems that have been long dead. Interestingly enough, it's because of the growing popularity of Vim that this is becoming more of an issue. I live in the Boston area and have visited many startups; Vim is quite popular among them. Yes, it's a little hipster, but in a good way. ;-) We have lots of seasoned developers at our Vim meetup [3] of course, but there are way more younger people who've discovered Vim. The room is usually packed. 1. http://www.openbsd.org/papers/bsdcan14-libressl/mgp00026.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00026.htm... 2. https://github.com/b4winckler/macvim/blob/master/src/os_unix.c#L5222 https://github.com/b4winckler/macvim/blob/master/src/os_unix... 3. http://www.meetup.com/The-Boston-Vim-Meetup/ http://www.meetup.com/The-Boston-Vim-Meetup/