## Description
<!-- Describe the big picture of your changes to communicate to the
maintainers
why we should accept this pull request. -->
This PR just fixes a few typos :)
`dont => don't`
## Related Issue(s)
<!--
If this PR fixes any issues, please link to the issue here.
- Fixes #<issue_number>
-->
## Screenshots
<!-- Add screenshots of the changes if applicable. -->
Problem: Command completion doesn't work if the command name isn't
written in full
Solution: Use vim.startswith to check if the command is a prefix of
'Lazy'
Fixes#1758
Adds the new `winfixbuf` to the window options of the lazy window. This makes the buffer "sticky", preventing accidentally switching to another buffer while in that window, e.g. via `:edit`. See the PR at nvim core https://github.com/neovim/neovim/issues/12517
`winfixbuf` is only available on newer nvim versions, so adding the option is wrapped in a condition checking whether it is supported.
## Description
When passing the `--dev` flag to `luarocks`, it will prioritise `dev`
versions when resolving dependencies (treating `dev` or `scm` as greater
than a SemVer version) if the rockspec doesn't specify an upper version
constraint (which is often the case).
Dev packages are often unstable and may cause more problems, especially
for Windows users (an example I've seen is git for windows trying and
failing to checkout submodules).
For now , a good compromise between too many retries and not retrying at
all could be to try `luarocks install` from the root manifest first, but
to keep the `--dev` flag in `luarocks make`.
If that still causes problems, it might be better to fall back to
`luarocks make` without `--dev` first, and then to try `luarocks ---dev
make` as a last resort.
In rocks.nvim, we only fall back to adding the `--dev` flag if the
install error message contains the string `"No results matching query
were found"`; assuming that stable non-dev packages shouldn't depend on
dev packages.
## Description
`package.cpath` is missing the `lib64` directory for plugins that have
luarocks dependencies.
## Context
I found this issue when I was working on my new Neovim plugin on my
Fedora 39 machine. I added the `luasockets` dependency to rockspec file
in my plugin like so:
```
rockspec_format = "3.0"
package = "typeracer.nvim"
version = "scm-1"
source = {
url = "git+https://github.com/carbon-steel/typeracer.nvim",
}
dependencies = {
"luasocket",
}
test_dependencies = {
"nlua",
}
build = {
type = "builtin",
copy_directories = {},
}
```
I found that the dynamic libraries from the `luasockets` dependency were
installed like so:
`/home/username/.local/share/nvim/lazy-rocks/typeracer.nvim/lib64/lua/5.1/socket/core.so`.
However, the only entry related to my plugin `typeracer.nvim` was:
`/home/glyph/.local/share/nvim/lazy-rocks/typeracer.nvim/lib/lua/5.1/?.so`.
The issue is that we only have the plugin's `lib` directory in
`package.cpath` and not `lib64`.
I looked through `lazy.nvim`'s code and I think adding the `lib64`
directory should fix the issue. I don't know if we also want to worry
about `lib32` as well, but so far, this change works for me.
## Description
In the issue (#1707) I was confused by the description of `dev.path`. I
thought functions must also return the general directory for local
plugins, but it must be the plugin directory.
## Related Issue(s)
#1707
## Description
On plugins update it fails with following error for any plugin.
```
~/.local/share/nvim/lazy/lazy.nvim/manage/task/plugin.lua:95: Vim:E150: Not a directory: ~/.local/share/nvim/lazy/gitsigns.nvim/doc/
```
## Description
After a discussion on Slack we noticed that the description of the sync
command is a bit vague. Some people, including myself, assumed
`clean`/`install`/`update` referred to build steps being performed per
plugin.
Another person mentioned they thought it referred to the Lazy commands,
which does make more sense.
They also noticed that the order of the commands do not match the source
code.
So this PR corrects the order, assuming it was meant to be ordered, and
mentions that those are commands for clarity.
## Description
The lockfile currently does not end with a newline at EOF. Text files
should [end with a newline](https://unix.stackexchange.com/a/18789).
This also lets you manually edit the lockfile in vim without 'fixeol'
creating a spurious change for the added newline.
This change however will create a change in users' lockfiles adding a
newline upon updating, but since the lockfile would be changing anyways
to update lazy.nvim itself, this is likely acceptable.
## Related Issue(s)
*none*
## Screenshots
*N/A*
Chris Grieser
github-actions[bot]
Folke Lemaitre
Lorenzo Zabot
Luna Saphie Mittelbach
Marc Jakobi
Roger Kim
Christoph Zirkelbach
github-actions[bot]
Alexander Grebennik
Gert Burger
Ethan Wu