But I do test things out, by virtue of often running the tip of master branch and submitting bug reports. But I cannot test every mention in the NEWS, so on that part you are right.
Deprecating :vc + :load-path without expressing why is a curious oversight. And "portability issues" is all fine and good, but why embed custom git clone + build grammar code in the treesit.el file if VC checkout portability is a concern? Surely VC is better at it than a bunch of brittle string concat code in treesit.el I do not understand why one part works and another supposedly does not.
The change is especially infuriating as for most of us it actually worked fine, and user-lisp directory does not solve the retrieval and setup problem, which `use-package` for all its flaws at least standardises.
Most users probably do care about discoverability of related packages, existing user or not. But that's in the eye of the beholder.
`package-review-policy` is security kabuki theatre. Someone who wants to harm an Emacs user can find many other ways of doing so with or without this flag.
The portability issues of `package-vc-install-from-checkout' are due to issues with symlinks not being portable, which is what that function relied on. None of this is related to tree-sitter. That is the function that the combination of :vc and :load-path would use, which just had to be transitively deprecated due to the mistake in `package-vc-install-from-checkout'. Critically `package-vc-install-from-checkout' _does not_ do any retrieval, the checkout of the package had to already exist beforehand, which use-package did not take care of. The function just made sure that package.el would activate the linked directory. User Lisp provides this same functionality. Do not confuse it with the :vc keyword that invokes `package-vc-install', which actually retrieves a checkout of some repository and prepares to do be loaded by package.el.
This is the kind of research that I would expect an article like yours to make. It is totally fair to contact the people who worked on this, instead of being smug about it and caricaturing the Emacs maintainers as conservative.
Comments
But I do test things out, by virtue of often running the tip of master branch and submitting bug reports. But I cannot test every mention in the NEWS, so on that part you are right.
Deprecating :vc + :load-path without expressing why is a curious oversight. And "portability issues" is all fine and good, but why embed custom git clone + build grammar code in the treesit.el file if VC checkout portability is a concern? Surely VC is better at it than a bunch of brittle string concat code in treesit.el I do not understand why one part works and another supposedly does not.
The change is especially infuriating as for most of us it actually worked fine, and user-lisp directory does not solve the retrieval and setup problem, which `use-package` for all its flaws at least standardises.
Most users probably do care about discoverability of related packages, existing user or not. But that's in the eye of the beholder.
`package-review-policy` is security kabuki theatre. Someone who wants to harm an Emacs user can find many other ways of doing so with or without this flag.
The portability issues of `package-vc-install-from-checkout' are due to issues with symlinks not being portable, which is what that function relied on. None of this is related to tree-sitter. That is the function that the combination of :vc and :load-path would use, which just had to be transitively deprecated due to the mistake in `package-vc-install-from-checkout'. Critically `package-vc-install-from-checkout' _does not_ do any retrieval, the checkout of the package had to already exist beforehand, which use-package did not take care of. The function just made sure that package.el would activate the linked directory. User Lisp provides this same functionality. Do not confuse it with the :vc keyword that invokes `package-vc-install', which actually retrieves a checkout of some repository and prepares to do be loaded by package.el.
This is the kind of research that I would expect an article like yours to make. It is totally fair to contact the people who worked on this, instead of being smug about it and caricaturing the Emacs maintainers as conservative.