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.
Problem: completion: 'autocomplete' cannot be enabled per buffer
(Tomasz N)
Solution: Make 'autocomplete' global or local to buffer (Girish Palya)
fixes: vim/vim#18320closes: vim/vim#183330208b3e80a
Co-authored-by: Girish Palya <girishji@gmail.com>
Problem: complete: some redraw issues with 'autocomplete'
Solution: Fix the issues (Girish Palya)
This commit contains the following changes:
* Fix that wildtrigger() might leave opened popupmenu around vim/vim#18298
* Remove blinking message on the command line when a menu item from a loaded
buffer is selected during 'autocomplete'
* Add a test for PR vim/vim#18265 to demonstrate why the PR is required for correct
'autocomplete' behavior
fixes: vim/vim#18298closes: vim/vim#18328ee9a2f0512
Co-authored-by: Girish Palya <girishji@gmail.com>
Problem: When the popup menu (PUM) occupies more than half the screen
height, it flickers whenever a character is typed or erased.
This happens because the PUM is cleared and the screen is
redrawn before a new PUM is rendered. The extra redraw between
menu updates causes visible flicker.
Solution: A complete, non-hacky fix would require removing the
CmdlineChanged event from the loop and letting autocompletion
manage the process end-to-end. This is because screen redraws
after any cmdline change are necessary for other features to
work.
This change modifies wildtrigger() so that the next typed
character defers the screen update instead of redrawing
immediately. This removes the intermediate redraw, eliminating
flicker and making cmdline autocompletion feel smooth
(Girish Palya).
Trade-offs:
This behavior change in wildtrigger() is tailored specifically for
:h cmdline-autocompletion. wildtrigger() now has no general-purpose use
outside this scenario.
closes: vim/vim#17932da9c966893
Use pum_check_clear() instead of update_screen().
Cherry-pick Test_wildtrigger_update_screen() change from patch 9.1.1682.
Co-authored-by: Girish Palya <girishji@gmail.com>
The vim._extui.messages module uses multiple timers that last 2 or 4
seconds. If these timers aren't finished when a test ends, there will
be a 2-second delay on exit with ASAN or TSAN.
