We may mention them in `:help news-breaking` for visibility, but that's only because I don't care about pedantry. API breakage != UI changes (e.g. mappings).
When problems get solved, the remaining problems become more salient. The most salient feedback we get in the last 3+ years is that the "getting started" UX has too much friction. (And this affects old users too, whenever I install Nvim on a new machine without my bag-of-tricks, I notice where friction is.)
For most users that want LSP, or even just to try Nvim for 2 minutes to see what it can do, it's not acceptable that our intro docs have to say "go here or there to install this or that plugin manager, and read their docs, then come back...".
Being able to say "add vim.pack.add(http://...) to your config, then :restart", is a complete answer.
vim.pack is relatively tiny (low maintenance), and zero performance cost for users that don't use it. Not bloat.
It's the opposite of bloat, because it allows us to more often choose "runtime-dependencies", instead of "shipping the universe" in the default build. That's a very welcome "release valve".
- Example of "shipping the universe": Vim's 1000+ builtin syntax files, ftplugins, etc.
- Example of "runtime-dependencies": nvim-lspconfig, treesitter parsers.
> The only users who need to do that are the ones who have already found a plugin that they want to install,
You skipped some steps.
> automatic dependency management
None of the existing plugin managers do that, except luarocks.
Nvim 0.12 (prerelease) also has ghost text with the "textDocument/inlineCompletion" LSP server capability[1]. Currently supported by the "copilot" config[2], but any LS that supports "textDocument/inlineCompletion" can be used (and the config[2] shows optional QoL improvements).
> Each user runs their own node completely independently. Everyone using Urbit OS owns their own identity and data. ... over an encrypted and authenticated network.
Interesting note about OS 1 in particular:
> One really critical thing about OS 1 is the pattern of ‘groups sharing modules’. This pattern makes it perfectly clear how a virtual computer can outcompete a bunch of different services. ... quickly outruns the messy, disconnected world we’re currently stuck in.
Do you have a primary source for that? This sounds like a cancel-culture rumor intended to attach negative ideas to a person in order to discredit them.
- libmpack serialization/deserialization API is callback-based, making it simple to serialize/deserialize directly from/to application-specific objects
- libmpack does no allocation at all, and provides some helpers to simplify dynamic allocation by the user, if required.
> In a city with 10+ million people you don't fall over each other when walking down the street. Usually the city is just big enough to compensate for high population.
I guess you haven't visited Tokyo. The streets are teeming with (non-tourist) people.
Indeed. "No price signal[1]" is very different from "no cost". It will cost plenty. Any service priced at zero simply has no back-pressure mechanism to respond to demand, nor to forecast demand, nor to measure demand in relation to alternative transportation options.