Problem: No way to granularly operate on plugins when inside
confirmation buffer.
Solution: Implement code actions for in-process LSP that act on "plugin
at cursor":
- Update (if has updates).
- Skip updating (if has updates).
- Delete.
Activate via default `gra` or `vim.lsp.buf.code_action()`.
Problem: :trust is executed even when inside false condition.
Solution: Make skip_cmd() return true for CMD_trust, as ex_trust() does
not handle eap->skip itself.
Problem: Installing plugin always pulls latest `version` changes
(usually from the default branch or "latest version tag"). It is more
robust to prefer initial installation to use the latest recorded
(i.e. "working") revision.
Solution: Prefer using revision from the lockfile (if present) during
install. The extra `update()` will pull the latest changes.
Problem: Running `update()` by default doesn't include not active
plugins, because there was no way to get relevant `version` to get
updates from. This might be a problem in presence of lazy loaded
plugins, i.e. ones that can be "not *yet* active" but still needed to
be updated.
Solution: Include not active plugins by default since their `version` is
tracked via lockfile.
Problem: The revision data is returned behind `opts.info` flag because
it required extra Git calls. With lockfile it is not the case.
Solution: Use lockfile to always set `rev` field in output of `get()`.
Problem: `get()` doesn't return `spec.version` about not-yet-active
plugins (because there was no way to know that without `add()`).
Solution: Use lockfile data to set `spec.version` of non-active plugins.
Problem: Some use cases require or benefit from persistent on disk
storage of plugin data (a.k.a. "lockfile"):
1. Allow `update()` to act on not-yet-active plugins. Currently if
`add()` is not yet called, then plugin's version is unknown
and `update()` can't decide where to look for changes.
2. Efficiently know plugin's dependencies without having to read
'pkg.json' files on every load for every plugin. This is for the
future, after there is `packspec` support (or other declaration of
dependencies on plugin's side).
3. Allow initial install to check out the exact latest "working" state
for a reproducible setup. Currently it pulls the latest available
`version.`
4. Ensure that all declared plugins are installed, even if lazy loaded.
So that later `add()` does not trigger auto-install (when there
might be no Internet connection, for example) and there is no issues
with knowing which plugins are used in the config (so even never
loaded rare plugins are still installed and can be updated).
5. Allow `add()` to detect if plugin's spec has changed between
Nvim sessions and act accordingly. I.e. either set new `src` as
origin or enforce `version.` This is not critical and can be done
during `update()`, but it might be nice to have.
Solution: Add lockfile in JSON format that tracks (adds, updtes,
removes) necessary data for described use cases. Here are the required
data that enables each point:
1. `name` -> `version` map.
2. `name` -> `dependencies` map.
3. `name` -> `rev` map. Probably also requires `name` -> `src` map
to ensure that commit comes from correct origin.
4. `name` -> `src` map. It would be good to also track the order,
but that might be too many complications and redundant together
with point 2.
5. Map from `name` to all relevant spec fields. I.e. `name` -> `src`
and `name` -> `version` for now. Storing data might be too much,
but can be discussed, of course.
This commit only adds lockfile tracking without implementing actual
use cases. It is stored in user's config directory and is suggested to
be tracked via version control.
Example of a lockfile:
```json
{
# Extra nesting to more future proof.
"plugins": {
"plug-a": {
"ref": "abcdef1"
"src": "https://github.com/user/plug-a",
# No `version` means it was `nil` (infer default branch later)
},
"plug-b": {
"dependencies": ["plugin-a", "plug-c"],
"src": "https://github.com/user/plug-b",
"ref": "bcdefg2",
# Enclose string `version` in quotes
"version": "'dev'"
},
"plug-c": {
"src": "https://github.com/user/plug-c",
"ref": "cdefgh3",
# Store `vim.version.Range` via its `tostring()` output
"version": ">=0.0.0",
}
}
}
```
Problem: filetype: Not all PKL files are recognized
Solution: Detect *.pcf as pkl filetype, detect using the pkl-lsp://
protocol as pkl filetype, include PKL syntax script
(Jan Claußen)
This adds basic syntax support for the new PKL language by Apple.
What works:
- Shebang support
- Comment support
- Integers (decimal, hex, octal and binary) support
- Floating point support including exponentials
- Basic datatype support
- Unicode escape delimiters
- Escape code support
- String interpolation
- Support up to five pounds for custom delimiters
- Folding of multi-line comments and blocks
What doesn't work:
The language heavily uses parameterized type declarations, which can get
very complex. It is very hard to highlight this properly. There is
official Tree-sitter support for this. Since it is hard to pull this off
in a vim syntax file, I opted for basic support of the data types.
References:
https://github.com/apple/pkl-pantryfixes: vim/vim#18271closes: vim/vim#18274https://github.com/vim/vim/commit/67a8f2945e54def2a9a94aad919e4f489595acb7
Co-authored-by: Jan Claußen <jan.claussen10@web.de>
This commit changes `languagetree.lua` so that it creates a scratch
buffer under the hood when dealing with string parsers. This will make
it much easier to just use extmarks whenever we need to track injection
trees in `languagetree.lua`. This also allows us to remove the
`treesitter.c` code for parsing a string directly.
Note that the string parser's scratch buffer has `set noeol nofixeol` so
that the parsed source exactly matches the passed in string.
Fixes#35884
Problem: Since `once_buf_loaded` might call a callback passed to it at a
later point (which is it's reason to exist) that callback might end up
referring to stale diagnostics in a handler's `show` function. For
example, if we first call `vim.diagnostic.set` for an unloaded buffer,
then call `vim.diagnostic.reset` and only then load the buffer, we might
still see diagnostics from `vim.diagnostic.set` call, which are stale at
this point.
Solution: only keep one autocommand from the most reset `show` call and
delete it when `hide` is called.
The current description (especially the "unlimited width" part) is
inaccurate in several ways:
- The size of virtual text can depend on window width. In particular,
the size of "above" virtual text can be equal to window width.
- A double-width character that doesn't fit adds 1 to the virtual column
of the following characters.
- The size of 'showbreak' and 'breakindent' is counted.
related: vim/vim#5713closes: vim/vim#18447https://github.com/vim/vim/commit/014c731fa50c28c94d56545938b6a05a86234c30
Problem:
Autocmds in inline_completion Completor are not scoped to specific
buffers. When multiple buffers have inline completion enabled, events
(InsertEnter, CursorMovedI, TextChangedP, InsertLeave) in any buffer
trigger callbacks for all Completor instances, causing incorrect
behavior across buffers.
Solution:
Add `buffer = bufnr` parameter to nvim_create_autocmd() calls to make
them buffer-local. Each Completor instance now only responds to events
in its own buffer.
Problem: completion: autocompletion can be improved
Solution: Add support for "longest" and "preinsert" in 'autocomplete';
add preinserted() (Girish Palya)
* Add support for "longest" in 'completeopt' when 'autocomplete'
is enabled. (Note: the cursor position does not change automatically
when 'autocomplete' is enabled.)
* Add support for "preinsert" when 'autocomplete' is enabled. Ensure
"preinsert" works the same with and without 'autocomplete'
* introduce the preinserted() Vim script function, useful for defining
custom key mappings.
fixes: vim/vim#18314closes: vim/vim#18387https://github.com/vim/vim/commit/c05335082adb21d99d96374779856444a3a0688f
Co-authored-by: Girish Palya <girishji@gmail.com>
Problem: 'nowrap' in a modeline may hide malicious code.
Solution: Forcibly use '>' as 'listchars' "extends" if 'nowrap' was set
from a modeline (zeertzjq).
Manual `:setlocal nowrap` disables this behavior. There is a separate
problem with `:set nowrap` that also applies to some other options.
related: vim/vim#18214
related: vim/vim#18399closes: vim/vim#18425https://github.com/vim/vim/commit/9d5208a9313dd8b0d62c97af5485f1715af98a1c
Cherry-pick some test_modeline.vim changes from patches 9.0.{0363,0626}.
Problem: :update should write new file buffers, but previous fix
affected special buffer types (acwrite, nofile, etc.).
Solution: Add bt_nofilename() check to only write new files for
buffers representing real filesystem paths.
Maria Solano