Todo List for Vim

https://vimhelp.org/todo.txt.html

by jhoechtl • 5 years ago

70 53 5 years ago

vimhelp.org

DrinkWater• 5 years ago

ok, i did not expect it to be THAT long.

fouc• 5 years ago

the downside of vim docs

letientai299• 5 years ago

Me neither. That show how good vim/neovim is. I hardly see any issue with vim (and a bunch of plugins) during my daily usage.

ducktective3• 5 years ago

Remember vim's first release date is 1991. What other ~30 year-old non-niche software do you know that has managed to remain relevant and having people actively developing for it?

https://en.wikipedia.org/wiki/Vim_(text_editor)#History

_se• 5 years ago

Emacs. :)

bluenose69• 5 years ago

What's the impact on neovim?

pensatoio• 5 years ago

Imagine if more people were allowed to contribute. Neovim is the horse to back, now.

monkin5• 5 years ago

What are you talking about? Everyone is allowed to contribute. Did I miss something?

djoldman2• 5 years ago

I think what parent is implying is that it is difficult to get a commit past Bram Moolenaar.

folago• 5 years ago

Well neovim folks forked vim bacause they were not allowed to clean up the code and fix vimscript among other things IIRC.

It is very unfortunate that they could not find an agreement.

lr1970• 5 years ago

Well, The Vim's BDFL is not that benevolent after all, hence the neovim fork.

vonwoodson2• 5 years ago

TL;DR; neovim is garbage and the maintainers are arrogant. It’s a project that can’t die soon enough.

If you’re actually proficient with vim and you’ve tried neovim, than you know that the “shiny” is quickly overcome by the lack of core functions and system integration that makes vim a power tool to begin with.

If you want to use neovim, then you don’t understand what makes vim great in the first place. Here’s a hint: it’s not the key bindings.

And, the maintainers don’t care. They refuse to fix years-old bugs and feature requests. I believe it’s because they’ve painted themselves into a corner with their inexperience and lack of pragmatism.

Because it’s worth giving an example of its glaring mistakes, open up neovim in the terminal and “:!python” ... huh, doesn’t work ... that’s because neovim doesn’t have shell IO from processes it launches. When I googled the issue I found a feature request from 2013-ish. I can’t say anything now, because when I bumped the issue I was told that “ThIS ISn’T a cOre FeatURe, gvim diDn’T haVe THIs uNTil ...” and they closed the feature request at that. No fix, just a “f-u-very much” and the door. I had already posted a few other bug reports / feature requests, but promptly deleted them after that response. I’m done with neovim, except for recommendations that nobody use it.

Use real vim. Donate to help Uganda. https://iccf.nl/news.html

dsissitka• 5 years ago

I found your issue and that's not at all how it went down. I don't think they were the ones being arrogant.

https://github.com/neovim/neovim/issues/1496

Edit: I missed the hidden comment the first time around. For those that can't log in:

https://imgur.com/a/ysEiIkL

djoldman2• 5 years ago

I believe your example will be fixed in nvim 0.5: https://github.com/neovim/neovim/pull/10842

jedimastert• 5 years ago

I just realized that, even though I use vim every day and work on open-source software for a living, I have no idea what vim's open source model looks like. It's been such an out-of-the-way tool for me that I treat it like a pencil. It's just there, waiting for me to use it.

Nuts.

JNRowe2• 5 years ago

Pretty much my experience too. Every few months my distro collects up a bag of patches, then I receive a new build. Once every couple of years I get to go through a version${new}.txt help file, often receiving a few new goodies.

My only real interaction was a few years ago when I opened a doc typo PR, and received a quick response from Bram. Then it faded away again.

wodenokoto• 5 years ago

I know the feeling. I was surprised to hear that new versions of bash are being released, by real people to boot!

Bash is like something that just materialize itself into existence everywhere.

tambourine_man• 5 years ago

That’s some scary list. I’m glad I’m not a maintainer, the amount of work is paralyzing

simias2• 5 years ago

Note that many of these entries seem pretty old and are probably "wontfix" in practice. This one stood out to me:

Re-write the code so that the highlighting isn't changed multiple times when doing a ":hi clear". The color changes happen three or more times currently. This is very obvious on a 66Mhz 486.

While it wouldn't surprise me if some people were still using Vim on 66Mhz 486 machines I would be surprised if anybody bothered to implement this optimization for such a niche use case.

gbrown_3• 5 years ago

I'm really not a fan of the decision to overhaul Vim script. It seems this is driven from a desire for Vim script to be faster [1]. I've not needed Vim script to be "faster" but I don't use very complex plugins. That said a lot of Vim script is written in sub-optimally. Using a more functional approach is faster (though still not "fast"), e.g.

    $ cat loop.vim
    let sum = 0
    for i in range(1, 2999999)
      let sum += i
    endfor
    quit
    
    $ cat fold.vim
    call eval(join(range(1, 2999999), '+'))
    quit
    
    $ time vim -u NONE -S loop.vim
    vim -u NONE -S loop.vim  7.08s user 0.09s system 99% cpu 7.198 total
    
    $ time vim -u NONE -S fold.vim
    vim -u NONE -S fold.vim  2.03s user 0.13s system 99% cpu 2.166 total

I think its cryptic reputation comes form the use of normal mode commands and regex within scripts. There certainly are warts, like the user's 'ignorecase' setting permeating to many places in the runtime. Which I'd love to see fixed and whilst may also represent a breaking change for some scripts would be far more easily adoptable.

[1] https://github.com/brammool/vim9/blob/master/README.md

chrismorgan3• 5 years ago

Meanwhile, on a computer that’s benchmarking within 20% of your figures:

• CPython 3.9.1 segfaults on a direct port of fold.vim after a few seconds. (It generates the 22,888,887-character `1+2+3+…+2999999` string in mostly under a second, then hits a stack overflow in the eval() call, presumably in parsing.)

• CPython 3.9.1 completes it with a loop in under a second;

• CPython 3.9.1 completes it with functools.reduce in half a second;

• CPython 3.9.1 completes it using sum() in about 150ms;

• Node.js 15.6.0 completes it with a loop in about 150ms;

• Node.js 15.6.0 with --jitless completes it with a loop within 300ms;

• Perl 5.32 completes it with a C-style loop in under 300ms;

• Perl 5.32 completes it with a foreach loop on a range in about 160ms;

• Perl 5.32 completes it with List::Util::sum in about 600ms.

(I didn’t try porting fold.vim to JavaScript because it lacks the primitives to make that a sane operation; or Perl, because my Perl skills are rusty enough that it would take a few minutes to sort it out, and I was lazy.)

So yeah, other scripting languages’ alternatives are pretty much just 5–20× as fast across the board, and often even more than that—and worse still, the performance pitfalls in Vimscript are often not what someone familiar with performance might expect—few would expect your fold.vim to be faster than your loop.vim.

Vimscript is routinely painfully slow to the point that it can easily be a serious bottleneck on anything involved, e.g. a fancy indent script, or some script that you use to process a file.

ajfjrbfbf• 5 years ago

I know nothing about Vim script, but since they're overhauling it, wouldn't it be a better option to rely on python scripting by providing a plugin API? Of course there's backwards compatibility, but they could always support both for a few years. Having to support your own language always seemed like a waste of time to me.

gbrown_3• 5 years ago

See the "PHASING OUT INTERFACES" section of the link in my comment for Vim's reasoning of moving away from this. Personally I broadly agree with it as I've seen many people struggle setting up plugins that depend on other things like python.

That said the approach Neovim took of shipping Lua built-in addresses the same portability/ease/reliability of use. In retrospect I think this is a better course of action.

jherdman• 5 years ago

... wouldn't it be a better option to rely on python scripting by providing a plugin API

NeoVim is using Lua for this very reason. It fits the bill nicely, and is quite fast.

lawn• 5 years ago

Overhauling vim script feels forced by Neovim's successful integration of Lua. But instead of adopting a sane language, or adopting Lua so Vim and Neovim can continue to be compatible, he decided to write yet another homebrew language.

gbrown_3• 5 years ago

I'm on the fence about this, I don't think Bram or other Vim devs are malicious towards Neovim. But the repeated implementation of equivalent features with incompatible APIs (terminals, async, and now faster scripting) doesn't look good.

ducktective3• 5 years ago

For anyone who is new to vim and wants a more-or-less OOTB auto-complete, auto-format experience, I recommend https://github.com/neoclide/coc.nvim

As for neovim, personally, I don't find a reason to switch. They say integrated LSP is coming in their next release but I don't see how that approach could be better than CoC's tracking of VSCode as upstream and bringing all the goodies of that high man-hours product.

What makes me consider switching, is a practical exclusive feature like that Tree-Sitter algorithm for syntax-highlighting that neovim team is touting or at least a concrete and reproducible performance benchmark against the regular vim in their usecase scenarios (startup-time, long logs, diffs, binary editing, etc).

ziml77• 5 years ago

Neovim started out as a quite interesting project but now I don't see a reason to use it. Not that I think it was pointless for the project to start in the first place. The competition seemed to motivate Vim devs to make advancements.

ducktective3• 5 years ago

Exactly. Sad thing is, it seems from now on, the projects are diverging so there would be incompatible plugins :(

marcuskaz2• 5 years ago

Ah, it is Vim's todo list, not using Vim as a todo app.

I was looking for more pointers on the later, I wrote a little on using Vim Wiki for managing todo list, always on the look out for more tips.

Here's the TLDR;

- Install Vim wiki plugin

- Convert line to checkboxes using ctrl-space

- Use ctrl-space to mark complete

- Use gln to toggle partial complete (glp for previous)

- gl<Space> to remove checkbox

A little more at: https://mkaz.blog/working-with-vim/vimwiki/

JNRowe2• 5 years ago

Nice doc series. Perhaps consider linking your lines documentation in the todo docs as an example of how to shift items around? Every time vimwiki/todo.txt comes up here people bring up how to move/delete completed items, often because they're unaware of :move and friends.

Note: Your .vimrc link in configuration¹ is broken.

Edit: After re-reading my comment it sounds like a complaint, it wasn't meant that way and I hope it didn't come across that way. I did enjoy reading your series!

¹ https://mkaz.blog/working-with-vim/configuration/

marcuskaz2• 5 years ago

No worries, thanks for the suggestions. I didn't read them as complaints at all.

I updated the link too, I switch back and forth between vim/neovim, the only real difference to me is the location of the config file.

ossusermivami• 5 years ago

vimscript is unfortunately way too limited for this sort of tasks. I wish they had the todo list to replace it with something a bit more elegant, not goign as far as lisp or scheme but even lua or python

w0m• 5 years ago

You can script it in python with the default builds I thought? I say that having not actually tried.

zvr• 5 years ago

You can already use Lua, Python2, Python3, Tcl or Ruby for scripting vim.

akvadrako• 5 years ago

This is pretty neat. I've got an entry on their from 2008:

When a register contains illegal bytes, writing viminfo in utf-8 and reading it back doesn't result in utf-8. (Devin Bayer)

Todo List for Vim

Related Stories