Vim is orphan as his creator Bram Moolenaar, a Dutch engineer born in 1961, passed away last Saturday:
https://groups.google.com/g/vim_announce/c/tWahca9zkt4
See also:
Vim is orphan as his creator Bram Moolenaar, a Dutch engineer born in 1961, passed away last Saturday:
https://groups.google.com/g/vim_announce/c/tWahca9zkt4
See also:
Neovim is a fork of the original Vim codebase that has been under development since 2014. It is 100% backwards compatible with the original Vim and has a number of features of interest.
There is discussion on the vim developer lists on what is needed to keep the project going. I donât think that the original codebase will be unviable anytime soon.
Yes, Iâve been using neovim from many years, it works great. The main reason I use it is because autosave just works when I defocus a terminal, just like VSCode.
Not sure how I missed out on neovim but this is the first Iâve heard of it. Looking at their website it appears you can use several GUIs. Anyone want to recommend one. I presume there is a Modern Fortran plugin for syntax highlighting.
I use neovim from a terminal. I make it a symlink to just vi
, so I type vi some_file.f90
, which has the advantage that if neovim is not installed, it opens up vim, so I donât have to change the habits how to open a file.
Indeed: Editor Integration - fortls
And theoretically there is a tree-sitter, but it seems to be incomplete (see Tree Sitter Fortran in Neovim)
I used Vim for a few years (and I liked it,) but at some point, several years ago, I tried Emacs, which is my Editor/IDE since then. Still, Vim is more than just a respected editor, itâs a symbol in the Unix-like world, and not just because it is vi-like. I tried (just out of curiosity) many editors, some where good, some not. But if ever wanted to change my editor of choice, I would just return to Vim.
I didnât like the fact some people decided Vim wasnât âgood enoughâ and needed a fork (which of course is not charityware as Vim is, and evangelizes Lua.) Some things should not be touched by younger programmers eager to beat a symbolâŚ
The loss of Vimâs creator, is really sad news. The software engineers community is poorer now. Rest in peace Bram Moolenaar. You will be remembered with respect.
I understand your concerns regarding forks.
But itâs not like âyoung people wanted to beat a symbolâ. Vim had some significant problems and patching it wasnât wanted. [1]
The Neovim project was started in 2014, after a patch to Vim supporting multi-threading was rejected
This and the rather complicated syntax of vimscript combined with resistance to change led to a very successful fork of vim, which now has twice as many stars on github as vim (68.5k vs 32k). [2][3]
The success of Neovim shows, that it wasnât just a âdecisionâ of some people that vim had problems, it was a fact.
I am aware of those âsignificant problemsâ. I donât really know the details and the real reasons that made people forking Vim. Do you? I guess only people really involved in the project can tell what exactly happened. From what I have read it sounded like âaccept our patches or elseâ.
Donât get me wrong, Iâm not saying forking is necessarily a bad thing. Iâm not even saying threatening to fork is always a bad thing. The Devuan guys did the same when Debian was about to adopt the crapware called systemd. They did well to threat and to eventually fork Debian, if you ask me, And by the way systemd was also introduced as ânecessaryâ with the excuse it will parallelize booting and make things easier and faster - which it didnât. Nobody said they wanted to make an intrusive wanna-be a second kernel instead of an init system - but thatâs exactly what they did. Thatâs another story, Iâm just using it as an example here.
What Iâm saying is you need to think twice before forking something like Vim. Iâm not sure they did that. Iâm just not sure, thatâs all.
I would not consider stars on⌠GitHub a proof of success. In fact, it might be a negative thing. GitHub is full of unfinished, abandoned, or not even started projects, together with forks of forks of forks - without any change, or where the only change made was to ditch Makefiles in favor of⌠Cmake (and even that wasnât done properly in most cases.)
There are many good projects on GitHub, sure, but it is also a place full of trash. And yes, projects like the ones I mentioned are unavoidable in a platform like GitHub, but we are talking about trash galore here. Everyone can start a project with basically nothing in it and upload it there for the world to see his masterpiece. Think of any known library you wish and make a search on GitHub. You will find literally dozens, if not hundreds, of forks introducing nothing new, or projects claiming the name.
GitHub stars are potentially biased towards users in a particular age group (20-35 maybe?), but donât capture the developers who donât work within the GitHub ecosystem. Iâm not a Vim or Neovim user, but just want to point out there exists a world beyond GitHub. I can imagine many people within the FOSS movement, that try to stay away from GitHub - Give Up GitHub - Software Freedom Conservancy.
Iâm still not sure whatâs the problem of forking. The only downside I can see, is that it can potentially (only if the fork is successful) split the community. But as far as I can tell, they tried to keep neovim as compatible as possible. Therefore, vim plugins work in neovim, too. Additionally, having a competitor increases the pressure to improve, and even Bram acknowledged that.
Just because GitHub is âfull of trashâ doesnât mean that stars are meaningless. But I totally agree, that they are biased, so letâs ignore them. Itâs hard to compare two projects, but maybe GitHub Insights are a more valuable foundation for comparing vim and neovim:
In the last month, July 15 - August 15
Vim:
Excluding merges, 44 authors have pushed 76 commits to master and 76 commits to all branches. On master, 254 files have changed and there have been 5,900 additions and 1,022 deletions.
Neovim
Excluding merges, 63 authors have pushed 197 commits to master and 245 commits to all branches. On master, 346 files have changed and there have been 59,881 additions and 14,636 deletions.
Interestingly, the top contributor of both projects is the same person
Thatâs true and I donât really like GitHub, too. But in this case, both projects are centred on GitHub. Where else would you compare them?
What alternative metrics would people suggest?
My list of Fortran codes on GitHub is continually growing, which is good, but that may make it less manageable for the user. A pipe dream of mine is to have the list on its own site, where users could search by category and some measure of quality. GitHub stars is an obvious metric, but some people here have criticized it. Other criteria I can think of are
I consider GitHub stars rather for the authors than the users of a project. An author is satisfied to have stars as it means some people think his project is interesting.
But if I need to choose a project, my first criteria would be: does it fit my needs? Then is it still maintained? (although concerning Fortran and its time scale, that may be not so important) Or is it easy to install? (FPM?) An important question, because if it is easy it can help answering my first questionâŚ
Ivan, I must admit I have not clearly understood what you mean. Do you mean the young generation is more present as GitHub developers? Or that they put more easily stars?
The first one, the younger generation is âraisedâ to be present on GitHub. Consequently, the Vim star count on GitHub doesnât capture the usage and fandom from people that install it via the Vim source archive or their OS package manager. But your second point may also be true, as one devotes more time to work and family responsibilities, there is less time to explore projects on GitHub or give out stars.
The best metric would be usage and testimonies, but these are generally not obtainable. Companies like to include telemetry in their products (e.g. VS Code), for this purpose.
Yes, for example concerning the traffic (views and clones), only the authors can see it in the Insights tab. And well, of course even the number of clones does not say really how many people really use it. Just how many tried it.
Since this thread is about remembering Bram Moolenaar, some years ago (before COVID) I attended a Fortran programming course at our local computing center, which expected us to use vim for remote editing. I completed the vimtutor
lesson and this was my first encounter with modal editing.
Browsing through the vim webpage, I stumbled upon the Bramâs book recommendation for The Seven Habits book by Steven Covey. At the time I was struggling with my degree work, long commutes, which put strain on my relationships with people close to me. I read the first half of the book, and it helped me to establish the roles I fulfil in my daily life, and accept that I need to set and accept priorities for different tasks.
Edit: if you are not interested in reading the whole book, Wikipedia provides a summary of The 7 habits.
That is true. Although I was rather thinking that older generations could be less prone to give grades/stars. That came with social networks, so rather after the mid 2000âs. I remember a world where nobody would have ever think to grade his Doctor, his dentist, or even a shop or a restaurant. Well, restaurants and hotels could have stars but they were given by professionals.
I have become accustomed to give stars or grades in the computer world, less for things in the physical world (although I of course will use grades to choose something on Google MapsâŚ) Yes, I have become more accustomed but still remember that it was for me something weird or shocking at the beginning.
It seems quite similar to David Allenâs book/method:
Yes, that kind of book can help to organize your life and manage priorities in this modern world.