| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
Problem: Two unrelated things are tested by a single test.
Solution: Split it into two, restoring the old Test_brace_single_line().
Add missing cleanup to some tests.
(zeertzjq)
closes: vim/vim#14323
https://github.com/vim/vim/commit/ad493ef3ea9ef7f2b0badcd2298883b5ab6e4ef4
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Page-wise scrolling with Ctrl-D/Ctrl-U implements
it's own logic to change the topline and cursor.
More logic than necessary for scrolling with Ctrl-F/Ctrl-B
was removed in patch 9.1.0211.
Solution: Re-use the logic from Ctrl-E/Ctrl-Y/Ctrl-F/Ctrl-B while
staying backward compatible as much as possible.
Restore some of the logic that determined how many lines will
be scrolled (Luuk van Baal)
https://github.com/vim/vim/commit/5a2e3ec9ac72b6e644fea4ebba7e632498296e2f
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Page-wise scrolling with Ctrl-F/Ctrl-B implements
it's own logic to change the topline and cursor.
In doing so, skipcol is not handled properly for
'smoothscroll', and virtual lines.
Solution: Re-use the logic from Ctrl-E/Ctrl-Y while staying
backward compatible as much as possible.
https://github.com/vim/vim/commit/b9f5b95b7bec2414a5a96010514702d99afea18e
|
|
|
|
|
|
|
|
|
| |
Co-authored-by: ite-usagi <77563904+ite-usagi@users.noreply.github.com>
Co-authored-by: v-sim <56476039+v-sim@users.noreply.github.com>
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Quico Augustijn <quico.public@gmail.com>
Co-authored-by: nhld <nahnera@gmail.com>
Co-authored-by: francisco souza <108725+fsouza@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
runtime(doc): Update options.txt
closes: vim/vim#14295
https://github.com/vim/vim/commit/ab01adf7c65b4ee350b402ab3ef1e7dfa5e074f1
Co-authored-by: Song-Tianxiang <149415622+Song-Tianxiang@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
| |
- Tags are now created with `[tag]()`
- References are now created with `[tag]`
- Code spans are no longer wrapped
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added `@inlinedoc` so single use Lua types can be inlined into the
functions docs. E.g.
```lua
--- @class myopts
--- @inlinedoc
---
--- Documentation for some field
--- @field somefield integer
--- @param opts myOpts
function foo(opts)
end
```
Will be rendered as
```
foo(opts)
Parameters:
- {opts} (table) Object with the fields:
- somefield (integer) Documentation
for some field
```
- Marked many classes with with `@nodoc` or `(private)`.
We can eventually introduce these when we want to.
|
|
|
| |
Follow-up to #27397
|
|
|
|
|
|
|
|
|
| |
runtime(doc): some improvements to getregion() docs (vim/vim#14122)
- Mention the default selection behavior
- Remove useless sentence
- Correct description about space padding
https://github.com/vim/vim/commit/87410ab3f556121dfb3b30515f40c5f079edd004
|
|
|
|
|
|
| |
Problem: getline and indent function missing string type in param.
Solution: add string type in eval gen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: getregion() can be improved (after v9.1.120)
Solution: change getregion() implementation to use pos as lists and
one optional {opt} dictionary (Shougo Matsushita)
Note: The following is a breaking change!
Currently, the getregion() function (included as of patch v9.1.120) takes
3 arguments: the first 2 arguments are strings, describing a position,
arg3 is the type string.
However, that is slightly inflexible, there is no way to specify
additional arguments. So let's instead change the function signature to:
getregion(pos1, pos2 [, {Dict}]) where both pos1 and pos2 are lists.
This is slightly cleaner, and gives us the flexibility to specify
additional arguments as key/value pairs to the optional Dict arg.
Now it supports the "type" key to specify the selection type
(characterwise, blockwise or linewise) and now in addition one can also
define the selection type, independently of what the 'selection' option
actually is.
Technically, this is a breaking change, but since the getregion()
Vimscript function is still quite new, this should be fine.
closes: vim/vim#14090
https://github.com/vim/vim/commit/19b718828d8d5fab52d94c6cdba694641879ab38
Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The documentation flow (`gen_vimdoc.py`) has several issues:
- it's not very versatile
- depends on doxygen
- doesn't work well with Lua code as it requires an awkward filter script to convert it into pseudo-C.
- The intermediate XML files and filters makes it too much like a rube goldberg machine.
Solution:
Re-implement the flow using Lua, LPEG and treesitter.
- `gen_vimdoc.py` is now replaced with `gen_vimdoc.lua` and replicates a portion of the logic.
- `lua2dox.lua` is gone!
- No more XML files.
- Doxygen is now longer used and instead we now use:
- LPEG for comment parsing (see `scripts/luacats_grammar.lua` and `scripts/cdoc_grammar.lua`).
- LPEG for C parsing (see `scripts/cdoc_parser.lua`)
- Lua patterns for Lua parsing (see `scripts/luacats_parser.lua`).
- Treesitter for Markdown parsing (see `scripts/text_utils.lua`).
- The generated `runtime/doc/*.mpack` files have been removed.
- `scripts/gen_eval_files.lua` now instead uses `scripts/cdoc_parser.lua` directly.
- Text wrapping is implemented in `scripts/text_utils.lua` and appears to produce more consistent results (the main contributer to the diff of this change).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
runtime(doc) Update help text for matchbufline() and matchstrlist()
closes: vim/vim#14080
https://github.com/vim/vim/commit/a35235e824bb77df0cebdb2bd290e13f1201b292
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Internal error when passing mark in another buffer to
getregion().
Solution: Don't allow marks in another buffer (zeertzjq)
closes: vim/vim#14076
Internal error when passing mark in another buffer to getregion()
https://github.com/vim/vim/commit/421b597470c118871c7081de00dd065e0e000b7e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: hard to get visual region using Vim script
Solution: Add getregion() Vim script function
(Shougo Matsushita, Jakub Łuczyński)
closes: vim/vim#13998
closes: vim/vim#11579
https://github.com/vim/vim/commit/3f905ab3c4f66562f4a224bf00f49d98a0b0da91
Cherry-pick changes from patch 9.1.0122, with :echom instead of :echow.
Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Co-authored-by: Jakub Łuczyński <doubleloop@o2.pl>
|
|
|
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
|
|
|
|
|
|
|
|
|
| |
(#27558)
To align the output of `nvim_get_hl` with its documentation -- which
points to `nvim_set_hl`, remove mentions of the keys `foreground`,
`background` and `special`.
The long keys are are still supported (via fallback checks inside
`dict2hlattrs`), but the `fg`, `bg` and `sp` keys are preferenced.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/neovim/neovim/pull/27428 changed the semantics of
callbacks passed to nvim_create_autocmd such that any truthy value will
delete the autocommand (rather than just the literal boolean value
`true`). Update the documentation accordingly and add an entry to
`news.txt`.
The behavior is now consistent between nvim_create_autocmd and
nvim_buf_attach.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Per :help sign_getplaced():
- Parameter {dict}: lnum also accepts integer as well as string
- Return value: item has field bufnr, not buf
|
| |
|
|
|
|
|
|
|
| |
When "q" is set in 'shortmess' it now fully hides the "recording @a" message
when you are recording a macro instead of just shortening to "recording". This
removes duplication when using reg_recording() in the statusline.
Related #19193
|
|
|
|
|
| |
`FloatConfig` is no longer used only for floats, so the name is counterintuitive.
Followup to #25550
|
|
|
|
|
|
|
|
|
|
|
| |
Getting current channel info was kind of annoying via RPC. Two
functions had to be called:
1. `nvim_get_api_info` which returns `[channel_id, meta_data]`.
- This results in `channel_id = api.nvim_get_api_info()[0]`.
- Here the meta_data is sent but never used.
2. Finally call `nvim_get_chan_info(channel_id)`.
This commit reduces the need for `nvim_get_api_info` as passing 0
returns current channel info.
|