One of the major human psychological fallacy is to “naturally” assume that other people are more or less the same as you, just a bit mire weird. This is bullhit. Some of them are way off.

There is something callled a built-in (or native) package manager for Neovim in development. Have you ever tried it?

Notice that this is not just an editor, this is a whole “ancient” tradition (which goes all the way back to hardware terminals and math majors as a synonym for a programmer) with an associated culture, and even religious zealots, which insist on purity, minimalism and even avoidance of plugins (sort of veganism).

So, one naively assumes, that the people who actually write (contribute to) it are at least somehow competent, while, unfortunately, math illiterate. At least they should understand the basics of development process, common practices and most widely used tools.

And, wallah, these people just gave us an interface to get (install) plugins from Github (or any other url) - with the url and version fields of a record.

Have you ever seen how people are using git and github? There are, just as in a structured texts, different levels of “granularity” . Just like in the /mental model of a vi user, there are fine-grained motions between nearby characters (hjkl) and between larger blocks of text (sentences, paragraphs) and code (blocks, functions, etc) .

There is something similar with git (and Github). The “lowest level” – the most specific (less general) abstraction is a rev, while the most general (least specific) is just an url (of a repo) with whatever branch hapens to be on it. Yes, you do not assume anything about the branch at this level of abstraction.

Yes, there are the most commonly used abstractions –an url, a branch, a tag and a rev (there are some more). Yes, one could, in principle, obtain a rev for each of them (the topmost of a branch, or a particular rev for a tag), but this is NOT what most people want.

One should follow the particular process (or practices) that the owner of the repo actually does. An owner may decide to just use a distinct branch, or to tag releases, or something more convoluted. There is no common “best practice” for software versioning using git, leave alone among plugin developers.

Now there is a [rhetoric] question – What the fucking kind of a “developer” you are if you cannot grasp just this much? Don’t you fucking see that at very least, at the level of a first-year college student, what you should have is (in pseudocode)

Url(string) | Branch(string) | Tag(string) | Rev(string)

and, ideally, with distinct types of strings – “url”, “branch”, “tag” and “ref”, so one cannot be passed to the other.

Now the “business logic”: what should happen when one says .update()? Well, if one specified and url one shall pull from whatever happens to be there. When one specified a branch, one presumably wants a pull from that very branch. If, however, one explicitly specified a tag or a rev, one have to stay on these, or, at least, being asked for update if there is a newer tag (but not a newer rev) in the repo.

What you have instad? “version”, where I should specify some string.

Have you noticed that you cannot install nvim-treesitter-textobjects plugin (the absolutely most importing one, if you understand vim, of course). The developer decided to use the main branch to the most recent changes, so it is compatible with the main branch of the nvim-treesitter itself. But you, fucking degenerates, are keeping installing the master and updating to the master branch, because you fucking assume that every repository name the branch “master” .

OK, I am smarter than you – I have cloned the right branch by hand and then I ran the

:lua vim.pack.update()

just as the documentation says…. and a whole clusterfuck of cosmic stupidity suddenly emerged.

## nvim-treesitter-textobjects Path: home/lngnmn2.local/share/nvim/site/pack/core/opt/nvim-treesitter-textobjects Source: https://github.com/nvim-treesitter/nvim-treesitter-textobjects Revision before: ecd03f5811eb5c66d2fa420b79121b866feecd82 Revision after: 5ca4aaa6efdcc59be46b95a3e876300cfead05ef (master)

Pending updates: < ecd03f5 │ fix: range contains(), is_in_range() to use nvim equivalents (#845) (grafted) > 5ca4aaa │ docs: master is frozen …

First of all, it still insist on (master), because the revision it tracks in the nvim-pack-lock.json file belongs to that branch, because it always installs the master branch first, even if I specify vesion='main' (according to the documentation).

But this is only a small, common stupidity. The cosmic one is in using async (and cooperative multitasking – Lua’s green threads) with calling git as external processes.

Async (surprise!) implies non-determinism and thus an unordered, non-sequential events, which means all your naive assumptions are off.

Have you ever though about what could happen to a git “command”? It is not just “network unreachable”, it can be “timed out”, because curl is so fucking smart, it could be a “connection reset by peer”, “http2 framing error” and whatever the fuck out. The most important part, each individual “async task” could fail with a very high probability, and you will end up in a randomly inconsistent state.

But this shit seems to just join them all together and fail as a whole when a single one fails, in a fucking async scenario!

If this is what kind of people wrote modern Neovim I do not want to have anything with it in principle.

I’ve spend days trying to figure out how to do shit just right (and end up doing very little, of course) and other people just cowboy-code (or a cavalier) and ship such a fucking abomination.

I never suspected that everything is so fucking broken in the open source world until then (compared to the golden age of the 80s and 90s, when people tend to understand [first] what they are doing).