Problem
Similar to https://github.com/neovim/neovim/pull/33257, but for the date
component. When timezone is behind UTC the epoch date of individual
components mismatch causing the test to fail.
Solution
The `epoch` variable is created using `os.date` with a `!`, which means
format the date in UTC instead of local timezone:
https://www.lua.org/manual/5.1/manual.html#pdf-os.date.
Since the individual components like year, month, and day are expected
to match `epoch` they should all be created using a `!` as well.
Problem:
Popup menu cannot have a border.
Solution:
Support 'pumborder' option.
Generalize `win_redr_border` to `grid_redr_border`,
which redraws border for window grid and pum grid.
Problem: Window may have wrong height if resized from another tabpage.
Solution: Improve check for whether a tabline has been added (zeertzjq).
fixes: vim/vim#18518closes: vim/vim#18519bd3b958027
Problem: after #35601, nvim_open_win incorrectly attempts to set the size of a
split window to 0 if it wasn't specified.
Solution: only attempt to set the size again if it was actually specified. This has the effect of defaulting to half the size of the parent window (or it may be equalized with other windows to make room), like before.
Fix#36080
Problem: popup: there are some position logic bugs
Solution: Refactor position logic and fix a few bugs
(Girish Palya).
This change does the following:
- Simplified and rewrote horizontal positioning logic (was overly
complex).
- Split horizontal and vertical positioning into separate functions.
- Fixed missing truncation marker (e.g. `>`) when items were truncated
and `pummaxwidth` was not set.
- Fixed occasional extra space being added to menu items.
- Update tests
closes: vim/vim#18441e3ed5584ed
Cherry-pick pum_display_{rtl,ltr}_text() changes from patch 9.1.1835.
Co-authored-by: Girish Palya <girishji@gmail.com>
Problem: 'cursorlineopt' "screenline" isn't redrawn when moving cursor
and then using line("w0") and :retab that does nothing.
Solution: Call redraw_for_cursorcolumn() when setting a valid w_virtcol
(zeertzjq).
closes: vim/vim#18506a084914361
Remove WM_LIST, which was previously added in #7110, but now statusline
and messages no longer interfere with each other thanks to the message
grid, etc., and terminal refreshing no longer calls update_screen()
directly since #9883.
Tests from #7110 and #10107 still pass.
Problem: If plugin was intended to install but there were errors (like
if there is a typo in `src`), lockfile still includes its entry.
This leads to all source of problems (like not correct `get()` output,
not working `update()`, etc.).
Solution: Explicitly account for plugins that were not installed.
Alternative solution might be to write a safe
`lock_set(plug, field, value)` wrapper (which sets field for a correct
`plugins` entry in the lockfile Lua table) and use it after install
to detect the change in `version`. However, this always requires
an extra pass through plugins on every startup, which is suboptimal.
Optimizing for the "happy path" should be a priority in `add()`.
Problem: vertical separator of 'winfixwidth' windows may remain if they
become right-most windows from closing windows to the right.
Solution: Don't implicitly rely on frame_new_width to fix vseps, as the
call may be skipped for 'winfixwidth' windows to preserve
their width; do it explicitly in winframe_remove (Sean Dewar).
Note that I prefer win_new_width here over setting w_width directly, which
would've previously been done by win_split_ins after frame_add_vsep, as this
wasn't true for winframe_remove.
Though the equivalent issue of bottom 'winfixheight' windows leaving stray
statuslines with &ls=0 doesn't seem to exist, test it anyway.
closes: vim/vim#18481620c655677
Nvim: calling win_new_width over setting w_width directly is especially
important in making sure stuff like w_view_width is correct here.
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
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: requested window size passed to nvim_open_win for splits may be ignored
by win_split_ins if it decides to forcefully equalize window sizes instead (e.g:
in an attempt to make room for the new window).
Solution: try to set the size again if it differs from what was requested.
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Problem: completion: some issues with 'acl' when "preinsert" and
"longest" is in 'completeopt' (musonius, after v9.1.1638)
Solution: Fix various issues (see details below) (Girish Palya)
This commit addresses multiple issues in the 'autocompletedelay' behavior with
"preinsert" and "longest":
- Prevents spurious characters from being inserted.
- Ensures the completion menu is not shown until `autocompletedelay` has
expired.
- Shows the "preinsert" effect immediately.
- Keeps the "preinsert" effect visible even when a character is deleted.
fixes: vim/vim#18443closes: vim/vim#18460f77c187277
Co-authored-by: Girish Palya <girishji@gmail.com>
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.
**Problem(?):** Buffers that (for whatever reason) aren't meant to have
a final newline are still parsed with a final newline in `treesitter.c`.
**Solution:** Don't add the newline to the last buffer line if it
shouldn't be there. (This more closely matches the approach of
`read_buffer_into()`.)
This allows us to, say, use a scratch buffer with `noeol` and `nofixeol`
behind the scenes in `get_string_parser()`.
...which would allow us to track injection trees with extmarks in that
case.
...which would allow us to not drop previous trees after reparsing a
different range with `get_parser():parse()`.
...which would prevent flickering when editing a buffer that has 2+
windows to it in view at a time.
...which would allow us to keep our sanity!!!
(one step at a time...)
Problem: Marks are lost after `:bdelete` because `ignore_buf()` filters
out unlisted buffers during shada mark processing.
Solution: Revert to original buffer checks for mark operations, avoiding
`!buf->b_p_bl` condition that incorrectly ignores deleted buffers.
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#18387c05335082a
Co-authored-by: Girish Palya <girishji@gmail.com>
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.
Problem: update command does not write new buffers that have
filenames but no corresponding file on disk, even when using ++p flag.
Solution: allow update to write when buffer has filename but file
doesn't exist.
Problem: Wrong display with 'smoothscroll' and long wrapped virtual
text at EOL.
Solution: Handle w_skipcol inside long wrapped virtual text at EOL
(zeertzjq).
closes: vim/vim#18408d9318acc02
Before functional/testnvim.lua was moved from functional/testutil.lua in
052498ed42, it was explicitly preloaded,
but now it is preloaded implicitly via functional/ui/screen.lua.
Also fix warnings about unused variables in other preload.lua files.
- Remove "state" directory after each test, so that a failure in one
test won't interfere with later tests.
- Still make sure the trust file is empty at the end of each test.
Use only a single clear() call in some test/functional/vimscript/ test
files whose test cases have very little side effect.
A downside of using a single clear() is that if a crash happens in one
test case, all following test cases in the same file will also fail, but
these functionalities and tests don't change very often.
