221–230 of 272 posts
Earlier quoted context omitted.
I tried that 'jk' thing way back, and I seem to recall it introducing some lag. Like a few milliseconds so it could process and see if you were hitting the followup key. Just enough to be annoying.
The lag thing is due to this: 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
What are some of the advantages of Vim’s domain specific scripting language over, say, providing a Python API?
Earlier quoted context omitted.
I gave up absolute line numbers a few years ago in exchange for `:set rnu` and while my navigation capabilities (at least to anywhere I can see) have gotten a lot faster, the ability to `>>` a handful of lines without having to count has felt a ton more productive
You can also set both relative & absolute line numbers at the same time.
> nnoremap :exe 'set nu!' &nu ? 'rnu!' : ''
Earlier quoted context omitted.
I've been using vi/vim on a near daily basis for 34 years now and this is the only thing I put in ~/.vimrc: set tabstop=4 set expandtab set shiftwidth=4 " or 2 or whatever set shiftround syntax on EDIT: 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 lon…
I have a simple one too-- 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 map q noremap x "_x let &t_ut='' if has("gui_running") :set guifont=Cascadia…
you turn off macro recording? any particular reason why?
Earlier quoted context omitted.
tabstop is how far the cursor moves when you press tab. 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 There's also another setting 'shiftround' (which I only learnt about today in another comment) which makes shifts done with > round themselves to the nearest multiple of shiftwidth.
i've always used 0i\t\t\t\t...\esc to shift. 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.
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.
Earlier quoted context omitted.
Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up. 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…
async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in. 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,…
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.
Long time user of vim as IDE, for over 20 years. I recently migrated to VS Code and I'm feeling satisfied and even more productive. I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
I would be very interested in a write up of why you prefer VSCode, if you can spare the time!
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.
Earlier quoted context omitted.
You mean 'the git way', all GitHub's doing is looking at commit authors (different from commit committers). 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.
Well, the two projects don't follow the same development model so comparing (artificially capped) GitHub-centric lists is not exactly conclusive. One has to dig a little bit deeper.
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.
Earlier quoted context omitted.
Well, Bram is the author of the parent project, he doesn't have any obligation to make it compatible with the derivative.
Vim has been around long enough that I'd argue it's just as much owned by the community at this point.
After neovim, what's the case for using vim?