| Age | Commit message (Collapse) | Author | Files |
|---|
|
This reverts commit 3f238b39cfdf27657b2d9452c6ffd28f8209c95f.
|
|
- Remove:
- uninitialized_clients
- active_clients
- all_buffer_active_clients
- Add:
- all_clients
- Use `lsp.get_clients()` to get buffer clients.
|
|
|
|
Problem: Not enough tests for the slice() function.
Solution: Test with multibyte chars, and in both Legacy and Vim9 script.
Update docs to be clearer about how it treats composing chars.
(zeertzjq)
closes: vim/vim#14275
https://github.com/vim/vim/commit/ad38769030b5fa86aa0e8f1f0b4266690dfad4c9
|
|
continuation of https://github.com/neovim/neovim/pull/24013
|
|
Problem: Vento files are not recognized.
Solution: Recognize *.vto files as filetype "vento" (wrapperup)
Vento is a templating engine https://vento.js.org/
closes: vim/vim#14229
https://github.com/vim/vim/commit/9f26e5a9bcedb3caef26e9d77849ea37a3626bbf
Co-authored-by: wrapperup <wrapperup4@gmail.com>
|
|
Problem:
`TSNode:_rawquery()` is complicated, has known issues and the Lua and
C code is awkwardly coupled (see logic with `active`).
Solution:
- Add `TSQueryCursor` and `TSQueryMatch` bindings.
- Replace `TSNode:_rawquery()` with `TSQueryCursor:next_capture()` and `TSQueryCursor:next_match()`
- Do more stuff in Lua
- API for `Query:iter_captures()` and `Query:iter_matches()` remains the same.
- `treesitter.c` no longer contains any logic related to predicates.
- Add `match_limit` option to `iter_matches()`. Default is still 256.
|
|
Problem: Dafny files are not recognized.
Solution: Recognize *.dfy files as filetype "dafny" (zeertzjq).
Ref: https://dafny.org/
Ref: https://github.com/mlr-msft/vim-loves-dafny
closes: vim/vim#14226
https://github.com/vim/vim/commit/4e334d0443f28f4e749dbef38d686d0dd19122de
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
|
Fixes #27895
|
|
|
|
|
|
fix(snippet): correct indent with newline
|
|
Problem: no overflow check for string formatting
Solution: Check message formatting function for overflow.
(Chris van Willegen)
closes: vim/vim#13799
https://github.com/vim/vim/commit/c35fc03dbd47582b256776fb11f11d8ceb24f8f0
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
|
|
reverts https://github.com/neovim/neovim/commit/c855eee919f2d4edc9b9fa91b277454290fbabfe
This setting introduces constant CI failures on macos
(see https://github.com/neovim/neovim/issues/23762).
|
|
|
|
`on_line_impl` doesn't highlight single lines, so using pattern indexes
to offset priority doesn't work.
|
|
Problem: winframe functions incorrectly recompute window positions if
the altframe wasn't adjacent to the closed frame, which is
possible if adjacent windows had 'winfix{width,height}' set.
Solution: recompute for windows within the parent of the altframe and
closed frame. Skip this (as before) if the altframe was
top/left, but only if adjacent to the closed frame, as
positions won't change in that case. Also correct the return
value documentation for win_screenpos. (Sean Dewar)
The issue revealed itself after removing the win_comp_pos call below
winframe_restore in win_splitmove. Similarly, wrong positions could result from
windows closed in other tabpages, as win_free_mem uses winframe_remove (at least
until it is entered later, where enter_tabpage calls win_comp_pos).
NOTE: As win_comp_pos handles only curtab, it's possible via other means for
positions in non-current tabpages to be wrong (e.g: after changing 'laststatus',
'showtabline', etc.). Given enter_tabpage recomputes it, maybe it's intentional
as an optimization? Should probably be documented in win_screenpos then, but I
won't address that here.
closes: vim/vim#14191
Nvim: don't reuse "wp" for "topleft" in winframe_remove, so the change
integrates better with the call to winframe_find_altwin before it.
https://github.com/vim/vim/commit/5866bc3a0f54115d5982fdc09bdbe4c45069265a
|
|
vim-patch:9.1.{0169,0170,0171,9a660d2883f9}
|
|
runtime(doc): add reference to matchbufline() at :h search()
related: vim/vim#14173
https://github.com/vim/vim/commit/9a660d2883f92b3a3761c964dc14363a8f70c8d8
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: more places exist where curwin == prevwin, and it may even be
expected in some cases.
Solution: revert v9.1.0001, but document that it's possible instead.
(Sean Dewar)
I've had a change of heart for the following reasons:
- A quick 'n dirty [GitHub code search](https://github.com/search?q=%2F%28winnr%5C%28%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%7Cwinnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5C%29%29%2F&type=code)
reveals some cases where it's expected in the wild.
Particularly, it made me aware `winnr() == winnr('#')` is possible when curwin
is changed temporarily during the evaluation of a &statusline expression item
(`%{...}`), and is used to show something different on the statusline
belonging to the previous window; that behaviour wasn't changed in v9.1.0001,
but it means curwin == prevwin makes sense in some cases.
- The definition and call sites of back_to_prevwin imply some expectation that
prevwin == wp (== curwin) is possible, as it's used to skip entering the
prevwin in that case.
- Prior to v9.1.0001, `:wincmd p` would not beep in the case that was patched in
v9.1.0001, but now does. That resulted in vim/vim#14047 being opened, as it affected
the CtrlP plugin.
I find it odd that `:wincmd p` had cases where it wouldn't beep despite doing
nothing, but it may be preferable to keep things that way (or instead also
beep if curwin == prevwin, if that's preferred).
- After more digging, I found cases in win_free_mem, enter_tabpage,
aucmd_restbuf and qf_open_new_cwindow where curwin == prevwin is possible
(many of them from autocommands). Others probably exist too, especially in
places where curwin is changed temporarily.
fixes: vim/vim#14047
closes: vim/vim#14186
https://github.com/vim/vim/commit/d64801e913314d2e19dbb38f60e6d285238debff
|
|
Using -1 as the initial value can cause the pattern offset to become
negative, which in turn results in a negative subpriority, which fails
validation in nvim_buf_set_extmark.
|
|
Tree-sitter queries can add URLs to a capture using the `#set!`
directive, e.g.
(inline_link
(link_text) @text.reference
(link_destination) @text.uri
(#set! @text.reference "url" @text.uri))
The pattern above is included by default in the `markdown_inline`
highlight query so that users with supporting terminals will see
hyperlinks. For now, this creates a hyperlink for *all* Markdown URLs of
the pattern [link text](link url), even if `link url` does not contain
a valid protocol (e.g. if `link url` is a path to a file). We may wish to
change this in the future to only linkify when the URL has a valid
protocol scheme, but for now we delegate handling this to the terminal
emulator.
In order to support directives which reference other nodes, the
highlighter must be updated to use `iter_matches` rather than
`iter_captures`. The former provides the `match` table which maps
capture IDs to nodes. However, this has its own challenges:
- `iter_matches` does not guarantee the order in which patterns are
iterated matches the order in the query file. So we must enforce
ordering manually using "subpriorities" (#27131). The pattern index of
each match dictates the extmark's subpriority.
- When injections are used, the highlighter contains multiple trees. The
pattern indices of each tree must be offset relative to the maximum
pattern index from all previous trees to ensure that extmarks appear
in the correct order.
- The `iter_captures` implementation currently has a bug where the
"match" table is only returned for the first capture within a pattern
(see #27274). This bug means that `#set!` directives in a query
apply only to the first capture within a pattern. Unfortunately, many
queries in the wild have come to depend on this behavior.
`iter_matches` does not share this flaw, so switching to
`iter_matches` exposed bugs in existing highlight queries. These
queries have been updated in this repo, but may still need to be
updated by users. The `#set!` directive applies to the _entire_ query
pattern when used without a capture argument. To make `#set!`
apply only to a single capture, the capture must be given as an
argument.
|
|
Fixes issue reported in the original PR:
https://github.com/neovim/neovim/pull/27810
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
|
|
Co-authored-by: C.D. MacEachern <craig.daniel.maceachern@gmail.com>
Co-authored-by: Ynda Jas <yndajas@gmail.com>
Co-authored-by: Owen Hines <TheOdd@users.noreply.github.com>
Co-authored-by: Wanten <41904684+WantenMN@users.noreply.github.com>
Co-authored-by: lukasvrenner <118417051+lukasvrenner@users.noreply.github.com>
Co-authored-by: cuinix <915115094@qq.com>
|
|
runtime(doc): improve 'winfixbuf' docs (vim/vim#14180)
- Make it not sound like a buffer option.
- "!" is called a modifier, not an option.
https://github.com/vim/vim/commit/0049a495c8d4a597773587f622d8cc8573c2eb75
|
|
- Add :h fswatch-limitations that notifies user about default inotify
limitations on linux and how to adjust them
- Check for Event queue overflow message from fswatch and refer user to
new documentation
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
|
|
Problem: Cannot keep a buffer focused in a window
(Amit Levy)
Solution: Add the 'winfixbuf' window-local option
(Colin Kennedy)
fixes: vim/vim#6445
closes: vim/vim#13903
https://github.com/vim/vim/commit/215703563757a4464907ead6fb9edaeb7f430bea
N/A patch:
vim-patch:58f1e5c0893a
|
|
|
|
|
|
|
|
fix(api): various window-related function fixes
This is a big one!
|
|
- Tags are now created with `[tag]()`
- References are now created with `[tag]`
- Code spans are no longer wrapped
|
|
|
|
WinNewPre autocommands
Problem: win_splitmove fires WinNewPre and possibly WinNew when moving
windows, even though no new windows are created.
Solution: don't fire WinNew and WinNewPre when inserting an existing
window, even if it isn't the current window. Improve the
accuracy of related documentation. (Sean Dewar)
https://github.com/vim/vim/commit/96cc4aef3d47d0fd70e68908af3d48a0dce8ea70
Partial as WinNewPre has not been ported yet (it currently has problems anyway).
|
|
Problem: nvim_open_win blocking all win_set_buf autocommands when !enter &&
!noautocmd is too aggressive.
Solution: temporarily block WinEnter/Leave and BufEnter/Leave events when
setting the buffer. Delegate the firing of BufWinEnter back to win_set_buf,
which also has the advantage of keeping the timing consistent (e.g: before the
epilogue in enter_buffer, which also handles restoring the cursor position if
autocommands didn't change it, among other things). Reword the documentation for
noautocmd a bit.
I pondered modifying do_buffer and callees to allow for BufEnter/Leave being
conditionally disabled, but it seems too invasive (and potentially error-prone,
especially if new code paths to BufEnter/Leave are added in the future).
Unfortunately, doing this has the drawback of blocking ALL such events for the
duration, which also means blocking unrelated such events; like if window
switching occurs in a ++nested autocmd fired by win_set_buf. If this turns out
to be a problem in practice, a different solution specialized for nvim_open_win
could be considered. :-)
|
|
Problem: currently, for splits, nvim_win_set_config accepts win without any of
split or vertical set, which has little effect and seems error-prone.
Solution: require at least one of split or vertical to also be set for splits.
Also, update nvim_win_set_config docs, as it's no longer limited to just
floating and external windows.
|
|
Problem: shm=F not respected when reloading buffer with 'autoread'
Solution: Check SHM_FILEINFO in buf_check_timestamp()
(Shougo Matsushita)
closes: vim/vim#14144
https://github.com/vim/vim/commit/9db39b0ec90600bb41faec3a12b934b17c298b1f
Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
|
|
Problem: Duplicate assignment in f_getregion().
Solution: Remove the duplicate assignment. Also improve getregion()
docs wording and fix an unrelated typo (zeertzjq)
closes: vim/vim#14154
https://github.com/vim/vim/commit/0df8f93bdaea77a1afb9f4eca94fe67ec73e6df2
|
|
|
|
|
|
Problem: can only call getregion() for current buffer
Solution: Allow to retrieve selections from different buffers
(Shougo Matsushita)
closes: vim/vim#14131
https://github.com/vim/vim/commit/84bf6e658da51126bdd2e50af1f40cabd149343f
Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #27318
|
|
Resolves #27713
Co-authored-by: Tomasz N <przepompownia@users.noreply.github.com>
|
|
No need to run a full iteration of the table. Simply return false when
the next key isn't what we expect.
|
|
|
