Vim 9.0(vim.org) |
Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with.
In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.
Not bad reasons in itself, but does it weigh against the tremendous cost for the community of the split? Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? Couldn't they not convince Bram Moolenaar of proposed changes, and if not, doesn't this have a good reason.
I hate NeoVim for the reason they've split, even though I understand it might become even better than Vim in the long run. You need better reasons to fork and divide an ecosystem.
Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668)
> Couldn't they not convince Bram Moolenaar of proposed changes
I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason.
That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript.
But that's how I remember it being started at least, but I could remember it wrong.
Of course I am stretching things a little, I know.
I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.
To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.
Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors.
So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.
Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.
I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.
Then neovim wouldn't have got off the ground.
Once they started building, they wanted to "cut the cruft" and just went from there
Not to mention that there are currently a lot of great plugins written in lua, and I anticipate there will be great plugins written using vim9.
Core maintainer of the Neovim Tjdevries is working on a compatibility layer that would allow vim9 to not only run in Neovim, but likely faster.
I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.
[1] https://insights.stackoverflow.com/survey/2021#section-most-...
Add in that StackOverflow is mostly a tool used by more junior web developers, and I think you’ll see that other demographics (like embedded, firmware, etc) would skew even more heavily in the direction of vim + no SO usage.
Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups.
Out of the different plugins, which would you never operate without?
Go Vim!
Other changes: https://vimhelp.org/version9.txt.html
https://github.com/nvim-treesitter/nvim-treesitter/issues/80...
So it should be possible in theory to use treesitter data to calculate indents, though it seems difficult.
I can see bolting a fallback regex mode for the few languages that have features which ts cannot (yet) accommodate.
And 'niche layered on niche' is -- well, it leaves me wondering how much you've actually used hx. The experience is nominal, the installation is sane, and it was way faster to get to 'genuinely pleasant' than nvim ever was.
As a plus, nix home-manager also handles helix config, which, as a nixos user, puts it over the top for me.
(home-manager also does nvim, but this is mostly mooted by my need for an elaborate (and turing-complete) Packer configuration, which has me using a separate git repo for nvim specifically)
I never really enjoyed having to configure vim. What I like about vim is the idea of modal editing which and the fact it runs and interacts in/with the shell. Still waiting a bit more before making the jump.
I switched a few years ago,and ever since Lua plugin support the Neovim ecosystem is thriving.
So...they make a new language to fix that? Couldn't they just use an existing language?
I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
For me, the most productive environment for writing and reading code is an editor with rich language support. Text editing ergonomics and startup time are completely trivial aspects of the user experience compared to proper language support. Although vim is improving, its plugin system, configuration mechanisms and plugin ecosystem is an afterthought and requires way more fidgeting, setup and hacking to just barely be useful.
When I made the switch, Bram was still vocal about how he regarded the sort of language support plugins I wanted as undesirable or irrelevant, and made no effort to accommodate things like LSP. This has changed, but at this point, it's too late. VS Code supports all the languages I need through a set of plugins it wouldn't even be possible to implement for vim, with no fidgeting required. Although I still love vim's text editing capabilities, they're not nearly enough to tip the scales.
I still use vim for quick text file stuff, and even write commit messages in vim in VS Code's terminal. For actual development though, it'll never be as powerful and low maintenance as VS Code.
I tried neovim-based vscode integration and didn’t find it comfortable enough.
^ I don’t really care of one or another way of formatting, but it messes with my code way too much, cause I’m using hyperscript not jsx. The way these linters format highly hierarchical calls is just stupidly bad.
Vim is sort-of the defacto reality in my life now, but if two or three things around tab expansion and tab-to-space got fixed, I'd stick to nvi compiled and installed from pkg/ports/homebrew over anything else.
A vimrc could revert this to standard behaviour, but that means having to have a vimrc file.
I was disappointed in those decisions.
But most Vim addons seem to be written in Vimscript, and porting them to another language (which?) is a lot of work for little practical gain (for many/most addons).
I've been using LunarVim/Neovim lately, and it is PHENOMENAL. Highly recommended!
Not really; the Python 3 problems were due to incompatibilities in the APIs (e.g. functions returning str previously now returning bytes) that couldn't be automatically converted, not merely due to "being incompatible".
You can safely mix VimScript and Vim9Script; you can even use both in the same file. It's not a problem. I wish people would stop using "Python 3!" on any incompatible change; the details on what is incompatible really do matter.
> I wish he’d have embraced Lua like Neovim
Vim has supported Lua since 2010, and Lua doesn't exactly have the best story on compatibility by the way.
Vim9 script and legacy Vim script can be mixed. There is no requirement to
rewrite old scripts, they keep working as before. You may want to use a few
:def functions for code that needs to be fast.
My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).
set tabstop=4
set expandtab
set shiftwidth=4 " or 2 or whatever
set shiftround
syntax on
Just for some fun archeology, I google searched on the 3rd line, 'set shiftwidth=4 " or 2 or whatever' because I very dimly recall copying most of my standard set (minus the syntax on bit) from someone else a long long time ago. This was the only hit I found:
https://www.perlmonks.org/index.qs1968.pl/perlmonks.org?disp...
set expandtab shiftwidth=4 softtabstop=4 tabstop=4
syntax on
set number
inoremap jk <Esc> set number
setlocal cm=blowfish2
set noswapfile
set nobackup
set nowritebackup
set viminfo=
set tabstop=4
set softtabstop=0 noexpandtab
set shiftwidth=4
set noundofile
set backspace=indent,eol,start
set autoindent
set smartindent
set cindent
autocmd BufRead,BufNewFile *.vue setfiletype html
colorscheme morning
map Q <Nop>
map q <Nop>
noremap x "_x
let &t_ut=''
if has("gui_running")
:set guifont=Cascadia_Mono:h16:cANSI:qDRAFT
endif " My vimrc from 1994 to about 2000
set et
set ts=4
" Added this circa 2000
syntax on
" Added this ~2013
let g:solarized_termcolors=256
set background=light
colorscheme solarizednoremap ; l
noremap l k
noremap k j
noremap j h
- neoterm, for opening a REPL in a split buffer and quickly sending chunks of lines to the REPL (https://github.com/kassio/neoterm)
- fzf for faster buffer and file navigation (https://github.com/junegunn/fzf.vim)
- vim fugitive for good git integration (https://github.com/tpope/vim-fugitive)
- some other tpope plugins (surround, unimpared, commentary, vinegar)
The most important ones lately seem to be the LSP integrations (basically IDE features like autocompletion, go-to-definition etc) and auto-completion managers. But honestly it's been breaking all the time over the last year or so that I code more often in VSCode and maybe it's about time I stop trying to make an ever-improving IDE out of Neovim :(
Neovim project's direction seems to be aligned with making it easier to have IDE-like experience with LSP integration but it's been painful in Neovim. In Vim, it's typically even worse and even harder to set it up.
Overall, I've been using Vim for about 8 years and went from a really simple set-up of "this is just a text editor" down the IDE rabbit hole. I also went for Vim -> Neovim -> Vim -> Neovim and eventual split of the two configs in the end and. I'm thinking about making it much simpler again :D
I have a quite extensive setup (https://github.com/Julian/dotfiles/tree/main/.config/nvim) which I built up over 10+ years, indeed sometimes including sitting there for an hour or two and just investigating plugins or writing some function to make editing easier. I enjoy it, and it means I can do lots of things in my setup that involved time investment.
Others obviously just want to get on with their work.
To me though part of the reason I use vim/neovim is because anytime something annoys me about editing I can automate it, or find a plugin which has done so already.
Every once in awhile I think I might do a fancier setup but then I lose interest. Ditto for checking out neovim. I'm sure I'd get some gains, but I guess I've sort of settled into a decent sweet spot that I haven't left for almost a decade, haha (been using vim for ~25 years total).
Since this editor (and Emacs) are SO extensible, it's hard to find two long-time users with similar configs.
Previously to managing my dotfiles, my .vimrc was usually 4-5 lines, written by hand on each machine I sat at. This was my first 20+ years of vi/vim.
Once I started managing dotfiles across systems (~3 years ago), my .vimrc has grown to be ~700 lines. My .bashrc has also grown to almost as much for reference.
Like most, the work in customizing .vimrc is in configuring plugins and making sure they don't conflict with each other, but also, I've taken care so that I can use the same configs across Linux and Windows, allowing me to use the same tools, plugins and configurations regardless of the underlying OS. Neovim is my tool of choice on both OSes but my configs fallback well to vim or other vi implementations rather gracefully (via bash/pwsh alias trickery) for when needed.
Regarding plugins that I would never operate without (of the many installed): - nerdtree (and friends like nerdtree-git-plugin, vim-nerdtree-syntax, vim-devicons) for decent file nav integration - vim-fugitive (Git integrated into vim, makes interactive commit creation and navigation easy from within vim) - Coc for language server support that works on both sides of the fork and vscode like plugins.
Also, not a plugin, but worth configuring in your environment: neovim-remote. I use this to make "vi <file>" open the file in a new tab, rather than start a nested editor, from within a terminal window within neovim (again with more shell alias trickery dependent upon $NVIM_LISTEN_ADDRESS being set or not). Using it for $EDITOR and $VISUAL when NVIM_LISTEN_ADDRESS is set is also really useful when invoked indirectly by tools being run in a windowed terminal e.g. "git commit" or "kubectl edit".
If you aren't tracking dotfiles, I really suggest you start. It's really cool to be able to sit at a new system, sync some files and get your editor / development environment installed/booted with all the bells and whistles you like installed ready to go. You will find that there is no end to this rabbit hole in the end. I think that's a good thing :)
Vim only has that reputation of needing a lot of config because too many newbies want to skip the learning phase and just jump in between two JIRA tickets. Of course you will need a lot of plugins and pre-baked stuff and hand-holding in that case!
The more sensible path is to learn Vim properly, and configure it as you go. It means that there's never a "take the week-end to configure Vim for React" moment: it's one line here, two lines there and it never really stops because you work with new languages and libs, etc.
As far as plugins. I can use Vim just fine without plugins or without my config but half of the plugins I use are written by me and tailored around my own needs so I guess those are the ones I need the most for my daily use.
One of the issues I found was that every plugin seemed to reference other plugins and you need to figure out how to make them play nicely together yourself. Most of the best info is just buried in GitHub issues and neovim was such a moving target that everything needed more digging into to get working correctly.
For me now essentials include; Telescope, Trouble, Cmp and a good LSP setup.
$ du -s -h .vim
22M .vim
Specific plugins I use all the time: bufexplorer (though I've mostly rewritten it), ctrlp, colorizer, syntastic, vim-commentary, vim-projectroot, vim-surround, zeavim (Zeal integration, similar to Dash on macos).
The plugin that I find myself using all the time is vim-surround with a couple of minor language-specific tweaks.
The editing plugins I use most heavily are probably vim-surround and vim-commentary. My development would definitely slow down without them.
I would say that the plugins I could not do without are:
- vim-polyglot
- syntastic
- nerdtree
- coc.vim
However, I use Emacs and VS Code for more involved editing, and mostly use vim as a light remote editor via SSH, so my priorities may be very different.
- https://qa.debian.org/popcon.php?package=vim
- https://qa.debian.org/popcon.php?package=neovim
- https://qa.debian.org/popcon.php?package=nano
(nano for the control group)
So lots of neovim growth, but still small in absolute numbers. Then again, vim-tiny is installed by default. Normal vim is a better indicator. And it won't grow as much, because Debian's userbase grows slowly.
Personally I'm happy with the default Vim config (I'll enable features if I need them, such as line numbers) and prefer the minimalism.
I tried neovim but there were more bells and whistles by default, and I didn't want to waste time configuring (and I work on a bunch of machines when wearing my sysadnin hat). For plugins, I only use a debugger.
94000 installs for vim
4000 installs for neovim
I see the neovim community holding up lua as a holy grail, rewriting entire vimrc configs just for the sake of it (even though a vimscript vimrc is much easier to read than a lua one) and rewriting rock solid existing vim plugins in lua, resulting often in a less stable and less feature complete plugin. But hey, it's now written in lua so it MUST be better!
https://news.ycombinator.com/item?id=31908731
A few highlights:
* "If it ain't broke, don't fix it"
* People don't like Lua (or just simply prefer VimScript)
* Divergence over time means that they are not still compatible.
Lua is not my favourite language, but I'd sure take it over vimscript.
:shock:
Who doesn't like Lua? That is right up there next to disliking kittens and puppies...
Really surprised to see /Debian/ of all things pick Neovim, especially years ago when it was even newer, as a default over Vim and would love to see the discussion around it. It would have been ~v0.2 for Stretch and ~0.3 for Buster, and only a year old during Jesse.
You can see here that there are more people with 5+ years experience than less:
https://survey.stackoverflow.co/2022/#section-experience-yea...
For what it's worth I prefer NeoVim and I've programmed since 2001, I don't think experience or anything has much to do with this preference.
I also think that anyone who doesn't Google stuff (and let's be honest, you'll probably end up on a Stack Exchange sub-domain when you do) for their hobby or professional programming is likely very stagnant and probably way worse and less experienced than they ought to be, since they're probably just doing the same old stuff all the time.
P.S. It's trivial to find default installations that don't have Vim, I don't get how anyone who's installed desktop or server distros at this point can not remember being surprised about the absence of Vim and having to install either it or NeoVim. I remember it being almost a regular occurrence when setting up machines.
Lots of embedded and BSD systems only have old vi, not vim, out of the box though.
Much of that is "just" the runtime files (things that define language syntax, etc), which are x-compatible (broadly) between nvim and vim. Seems it would be foolhardy to just re-write all that in lua, "just because".
https://github.com/vim/vim/graphs/contributors
https://github.com/neovim/neovim/graphs/contributors
Here are contributor lists I've gathered a few years ago from `:help versionX.txt`: https://gist.github.com/romainl/7b17317cc26a30116e51a3759022...
That's 600+ non-Bram contributors up to the fork that the Neovim team made disappear from their project when they removed the relevant files.
A checked in file with a list of names is not the way to record that, I don't blame Neovim for removing it since that's basically useless anyway.
That's what I mean by niche layered on niche- the editor itself is a niche project that leverages another niche project (tree-sitter) to do indentation, and when contributions on either aren't up to par it kind of falls apart.
I have used the editor a decent amount and it's quite nice when it works. I don't even mind the lack of plugin extensibility because there's not really anything I needed that wasn't built in.
I'd like to point out that the editor is barely a year old and I'm working on it entirely during my free time. It takes time to sort out all the issues and provide excellent support for all languages. I primarily write Rust and Go so those are guaranteed to work well.
It's hard to do tree-sitter query based indentation with space based languages, because the indent has semantic meaning and the AST node is invalid until indentation is typed out. We do have a potential solution (https://github.com/helix-editor/helix/issues/763#issuecommen...), it just needs someone to go and implement it.
I don't consider tree-sitter niche though. Outside of VSCode it's widely adopted, but yes it's probably too soon to only rely on tree-sitter with no fallback. Of course we do implement fallback behaviours too: we try to use tree-sitter first, then provide a simpler fallback for cases where there's no grammar available (or like in this case, it's not a great fit).
Edit: this has prompted me to switch python to the fallback algorithm for now https://github.com/helix-editor/helix/commit/9ae70cc410bd042...
To be honest I don't know how Brad keeps up with it all. And even has enough left over to add a new bespoke scripting language with Vim 9...
Okay, I did a quick grep through the documentation of my distros current vim installation and came up with support for Lua, MzScheme, Perl, Python, Ruby and tcl.
So yeah, there are lots of interfaces to chose from.
Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way?
There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.
Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim.
This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.
This seems more like an inexperienced developer getting frustrated with the process. I absolutely would expect that new contributors will have to go through multiple revisions before they can get anything merged.
When I started working as a junior dev my first merge request had more comments from seniors requesting changes than lines of code. It can be absolutely brutal but that something everyone needs to go through.
If he had tried for years he might have had a point but just because it took months does not mean Bram was not interested in the patch at all. Otherwise he wouldn't have suggested any fixes.
Lua, on the other hand, won't give me an error if I mistype a variable name, and the ecosystem doesn't really have good static analysis tools to catch these kind of silly errors. There's some other things I don't like either, like how "arrays" are really just hashmaps, as well as some other things. The whole versioning story wrt. compatibility is also annoying (it's basically a Python 2/3 story with every single Lua version).
It's not Lua is horrible, but the fawning over it from some Neovim people is something I always found curious, like it's a fantastic brilliant language. Meh, I found it quite average overall, at best. And if I look at some Lua vimrcs or plugins then it's all a lot more verbose and awkward than VimScript.
Not that VimScript is perfect by any means, but overall I find it's quite a decent DSL for an editor.
Through the use of metatables you can improve the undeclared global situation[2], through I admit it's kludgy.
We use luacheck for static analysis, but I'll admit it's far from perfect. The language doesn't lend itself well to static analysis.
I think what lua mostly has is a really good embedding story. It's a tiny C library with broad compatibility and a permissive license; and with LuaJIT it's also very fast (though less portable). This means it's used everywhere and a lot of people are at least passingly familiar with it. Vimscript on the other hand is fairly alien.
[1] https://luajit.org/extensions.html
[2] https://github.com/CorsixTH/CorsixTH/blob/master/CorsixTH/Lu...
Lua has pretty good lsp server and it gives me good warnings and completions.
set autoindent
set copyindent
set preserveindent
% vim Makefile
:verbose set expandtab?
noexpandtab
Last set from /usr/share/vim/vim90/ftplugin/make.vim line 15
% vim file.c
:verbose set expandtab?
noexpandtab
Last set from ~/.vim/vimrc line 56
autocmd FileType go,make,sh set noexpandtab
autocmd FileType js,json set sw=2 ts=2
filetype plugin indent onMy read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):
You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*
Bram,
I happy to see there is still some hope for this patch getting merged.
Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.
Bram replied (in part):
It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.
As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.
FWIW, my takeaway was the exact opposite. How the original async authors were treated was a disgrace. It showed, to me, that there were deep problems with the vim dev community. Forking off neovim was the best thing that could happen. I'm so glad someone had the energy to do so.
That said, I'm super grateful for Brams work on vim. It was my tool of choice for many years.
So, who forked neovim and what does this timers patch have to do with forking if the patch authors weren't the ones forking neovim.
https://groups.google.com/g/vim_dev/c/65jjGqS1_VQ/m/fFiFrrIB...
He had a separate interest in async but never actually asked for anything to be merged. You'll notice that it is advertised by Thiago as a proof of concept. One of the authors of the previous patch showed up to give a fairly inaccurate summarize of the previous thread, seemingly attempting to dissuade Thiago from continuing. The characterization of Thiago trying to get something added and being stymied seems to have come from the author of that original thread in a comment here:
https://news.ycombinator.com/item?id=7279358
In Thiago's words, the inspiration for forking seems to have come from the opportunities that were cataloged by Marc Weber. About two weeks after forking he did add the message_T changes to neovim. To say that his goal with that patch was simply to get async support into vim though is to disagree with Thiago's own words on the thread. He was upfront that he wanted to refactor the vim architecture around a different paradigm that he describes as a message loop.
But he went about it in a way that certainly looked petty.
Bram's been developing Vim for 30 years [0]. Just think about that for a second. An open source project that's been running for longer than the age of probably 50% of the readership on hackers news. It's ways of working and values have been developed over a long period of time.
Vim favours being available on multiple platforms, alignment with Unix tradition and stability:
> Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems. (https://www.vim.org/about.php)
Neovim is built by people who value fullness of features, who see multi-platform as 'legacy platforms' and are happy to break backwards compatiblity for the value of making something more complete by contemporary standards.
The easiest summary is - Bram's comparison is Vi, Neovim teams' comparison is VS Code.
I love many of the NeoVim's new features and capabilities.
But, I think it's possible to like Neovim while also understanding the positive value of Vim and why their approach is different. There's something in the human condition about turning everything into a winner and loser, a hero or a villain - but it's just not true.
As a project that's been running for 30 years Bram and that community have an approach that they are comfortable with. There's a way of working, and a rhythm to the project that has worked over the long-term. They're evaluation of changes is against their own internal values - those values are different to the people that are working on Neovim. Personally, to me 30 years of effort and contribution to providing something totally free is unbelievable.
The divergence and incompatibility is unfortunate though, especially since some of it just seems petty. Made moreso, because it isn't possible to truly polyfill functionality from one in the other (native commands and functions are effectively in a separate namespace than user-defined ones).
It is fully open source.
Open source does not mean the maintainer is under the obligation to add features, or integrate PRs.
He suggests neovim (and vim, emacs etc) fall into a category between text editor and IDE.
The term he uses is PDE (personalised development environment). In short, you have lots of power to customise your setup; you can give it some IDE-like behaviour but the way you do it tends to be by making personal choices of plugins and config.
It's not just a text editor, it's definitely not 'integrated'. I'm inclined to agree with him.
So the idea is Neovim by itself isn't an IDE. But it does enable you to build an IDE using configuration and plugins, or even embedding it in a GUI.
If you type `j` in insert mode, it waits to see if there's a possible `k` following. That's the lag.
There's a setting for how long it waits.
> set timeout timeoutlen=3000 ttimeoutlen=100
you turn off macro recording? any particular reason why?
Seriously, you don’t have to love Neovim, but credit where it’s due.
shiftwidth([{col}]) shiftwidth() Returns the effective value of 'shiftwidth'. This is the 'shiftwidth' value unless it is zero, in which case it is the 'tabstop' value. This function was introduced with patch 7.3.694 in 2012, everybody should have it by now (however it did not allow for the optional {col} argument until 8.1.542).
When there is one argument {col} this is used as column number
for which to return the 'shiftwidth' value. This matters for the
'vartabstop' feature. If the 'vartabstop' setting is enabled and
no {col} argument is given, column 1 will be assumed.
Can also be used as a |method|: >
GetColumn()->shiftwidth()
[0] https://github.com/weiss/original-bsd/commit/3effe8f62d3c7b5...
shiftwidth is how far text moves when you shift it with >> or <<
Normally you'd set them both to the same value so that indenting blocks of code with >> or << shifts them by the same amount as the tabstop.
There's also another setting 'shiftround' (which I only learnt about today in another comment) which makes shifts done with << and >> round themselves to the nearest multiple of shiftwidth.
They're both valid options and it's just about preference.
I might be wrong, but I think math favors different starting indices based on the subject matter. I've seen Analysis textbooks favor 0 as the starting index. I don't think there's a clear argument for cultural transference from math.
I'm opposed to starting index from 1 because I think departure from very mainstream programming tradition should have a strong reason beyond preference, even if the de facto tradition appears equally capricious.
Aesthetically, it is repulsive, but when actually writing code in Lua, it was not much of a problem. I felt much stronger about "do"/"then" and "end" versus curly braces for delimiting blocks.
~= instead of !=
# instead of len()
Default declaration to global
-- for comments
Dereferencing something that doesn't exist returns nil
That's not accurate. It's also pruning from the resulting list the commit authors for which GitHub is unable to associate a GitHub account with a given contributor; it simply doesn't attempt to represent contributors who are not (known) GitHub users.
(That isn't to say there's any significance here to Vim; the Vim repo does genuinely obscure patch authors by not using the appropriate fields to capture that information—most commits, going by Git metadata, are attributed to Bram using that method. But the statement "all GitHub's doing is looking at commit authors", strictly speaking, is not true.)
Previously: GitHub's "Contributors" graphs are unreliable for working out who really works on a given repo. <https://news.ycombinator.com/item?id=31421107>
If I did it with `git shortlog -s` it's also going to omit the contributors from the .. I don't even know what centric way you say vim did it, and over-report commits for those who were allowed to have their names recorded properly but against commits actually authored by someone else.
It's just totally non-standard against the grain git usage.
The parent set the context of this thread by providing links to GitHub pages, that's for the "GitHub-centric", and the GitHub UI caps many of its listings to 100 items (100 pages of search results, etc.) so you only get to see the 100 first contributors, that's for the "artificially capped".
> If I did it with `git shortlog -s`
You would use an inappropriate measurement method that doesn't take into account the nature and history of the subject of your study and thus get meaningless data.
> It's just totally non-standard against the grain git usage.
There is no such thing as "standard" git usage, especially when factoring GitHub into the discussion. There are "modern" expectations, though, that the Vim project doesn't meet because it is much older than those expectations. Maybe you don't like it but it matters when discussing metrics.
FWIW, the move to Git of "the kernel" also dropped more than a decade of pre-2005/pre-git history so `git shortlog -s` won't give you the full picture there either.
Speaking of message-loop design. This is a typical design in the vast majority of GUI software where the center of the program is a message loop. I never realized the original vim didn't have that kind of design. What is it's design?
many of the systems it supports haven't received updates in decades and have essentially no users. The old versions work just fine on them, and require no changes because those systems aren't changing. There's no reason why _new_ versions of vim have to be held back by the need to work on ancient platforms.
I'm not even sure it's human nature to put it as winners and losers. Our current culture is obsessed with seeing it in this way, very much influenced by "the economy" of the wide-area societies we live in, but I'm not sure it's universal.
never occurred to me to use >>. probably because the three keystroke savings didn't register with me. but that's what I mean, once I learn the basics, the rest are just gravy that don't stick in my memory.
> i've always used 0i\t\t\t\t...\esc to shift.
Also consider I instead of 0i (it's not quite identical, but should serve the same purpose).
If I'm working in any other language it's == (for a single line), or = after marking a region in visual mode, or magg=G'a to just re-indent the whole file.
I haven't used vim as a daily driver in ~14 years; it's weird how the muscle memory of things like magg=G'a or gqip stay in your fingertips.
Says who? There are many free software projects, with public source code and free licenses, that are not developed openly. For example, lua itself (on which neovim is based). The lua team are adamant on not accepting external patches. And that is perfectly alright, and not contradictory with neither the letter nor the spirit of free software.
"Open source not open contribution" is increasingly seen, and people don't seem to mind, and the attitude described with regard to vim development seem less "thanks, bit no thanks" than that, so I don't imagine any majority have an issue with it.
If I finally get around to making and releasing some stuff I plan, "not open contribution" is where I'll be. These things are my toys, they'll go my way, though the source is there so feel free to fork if you need/want something I'm not planning to do or not planning to do soon enough (I'll even link to your efforts so people wanting the same know where to find it). Unless you want to pay for my time to maintain and support your feature going forward, of course!
Both development models are OK, and plenty of people are comfortable with both. I'd actually argue that most early/not-"modern" FOSS software have had the model of "you're welcome to contribute, but we ultimately own the codebase and therefore decides what goes in. If you're unhappy, feel free to fork", and it's not until lately, that some projects have decided to merge almost whatever people contribute.
Some projects even go as far as giving people direct write-access as soon as someone has got a PR merged, but I don't think that's very common, neither is the "merge without strict review" model you seem to referring to.
I am very comfortable with this model.
Saying the "the zeroth element" is just... weird and slightly nonsensical.
1 is something and it fits very well for the first position... outside of programming :-)
In 0-based indexing, the index of an item is the number of items you've already seen, excluding the one you're looking at.
if $WORK_COMPUTER
set number
endif
> nnoremap <C-n> :exe 'set nu!' &nu ? 'rnu!' : ''
:set nu!
Are you still using goto's ?
'<,'>w !xclip -selection clipboard
pbcopy
While I'm here, on Wayland substitute wl-copy (or whatever you use).
But now you've said it maybe I'll remember if I need it today, and.. well I'll see.