Based on feedback from #28324, pass -H and -I to regular grep
(available on all platforms officially supported by Neovim), and
only pass -uu to ripgrep. This makes :grep ignore binary files by
default in both cases.
Problem: String interpolation fails for Dict type
Solution: Support Dict data type properly, also support :put =Dict
(without having to convert it to string() first)
(Yegappan Lakshmanan)
fixes: vim/vim#14529closes: vim/vim#14541f01493c550
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: noautocmd is confusing; despite its name, it doesn't block all
autocommands (instead it blocks only those related to setting the buffer), and
is commonly used by plugins to open windows while producing minimal
side-effects.
Solution: be consistent and block all autocommands when noautocmd is set.
This includes WinNew (again), plus autocommands from entering the window (if
enter is set) like WinEnter, WinLeave, TabEnter, .etc.
See the discussion at https://github.com/neovim/neovim/pull/14659#issuecomment-2040029517
for more information.
Remove win_set_buf's noautocmd argument, as it's no longer needed.
NOTE: pum_create_float_preview sets noautocmd for win_set_buf, but all its
callers already use block_autocmds.
Despite that, pum_create_float_preview doesn't actually properly handle
autocommands (it has no checks for whether those from win_enter or
nvim_create_buf free the window).
For now, ensure autocommands are blocked within it for correctness (in case it's
ever called outside of a block_autocmds context; the function seems to have been
refactored in #26739 anyway).
runtime(doc): Normalise builtin-function optional parameter formatting
These should generally be formatted as func([{arg}]) and referenced as
{arg} in the description.
closes: vim/vim#144389cd9e759ab
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: Dialog for file changed outside of Vim not tested.
Solution: Add a test. Move FileChangedShell test. Add 'L' flag to
feedkeys().
5e66b42aae
Co-authored-by: Bram Moolenaar <Bram@vim.org>
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#14323ad493ef3ea
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)
5a2e3ec9ac
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.
b9f5b95b7b
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#14275ad38769030
Problem: no overflow check for string formatting
Solution: Check message formatting function for overflow.
(Chris van Willegen)
closes: vim/vim#13799c35fc03dbd
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
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.
5866bc3a0f
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#14047closes: vim/vim#14186d64801e913
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)
96cc4aef3d
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: Duplicate assignment in f_getregion().
Solution: Remove the duplicate assignment. Also improve getregion()
docs wording and fix an unrelated typo (zeertzjq)
closes: vim/vim#141540df8f93bda
Problem: can only call getregion() for current buffer
Solution: Allow to retrieve selections from different buffers
(Shougo Matsushita)
closes: vim/vim#1413184bf6e658d
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.
runtime(doc): some improvements to getregion() docs (vim/vim#14122)
- Mention the default selection behavior
- Remove useless sentence
- Correct description about space padding
87410ab3f5
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#1409019b718828d
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#14080a35235e824
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()
421b597470
Problem: hard to get visual region using Vim script
Solution: Add getregion() Vim script function
(Shougo Matsushita, Jakub Łuczyński)
closes: vim/vim#13998closes: vim/vim#115793f905ab3c4
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>
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.
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
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.
The "priority" field of extmarks can be used to set priorities of
extmarks which dictates which highlight group a range will actually have
when there are multiple extmarks applied. However, when multiple
extmarks have the same priority, the only way to enforce an actual
priority is through the order in which the extmarks are set.
It is not always possible or desirable to set extmarks in a specific
order, however, so we add a new "subpriority" field that explicitly
enforces the ordering of extmarks that have the same priority.
For now this will be used only to enforce priority of treesitter
highlights. A single node in a treesitter tree may match multiple
captures, in which case that node will have multiple extmarks set. The
order in which captures are returned from the treesitter API is not
_necessarily_ in the same order they are defined in a query file, so we
use the new subpriority field to force that ordering.
For now subpriorites are not documented and are not meant to be used by
external code, and it only applies to ephemeral extmarks. We indicate
the "private" nature of subpriorities by prefixing the field name with
an "_".
Problem: E95 is possible if a buffer called "[Command Line]" already
exists when opening the cmdwin. This can also happen if the
cmdwin's buffer could not be deleted when closing.
Solution: Un-name the cmdwin buffer, and give it a special name instead,
similar to what's done for quickfix buffers and for unnamed
prompt and scratch buffers. As a result, BufFilePre/Post are
no longer fired when opening the cmdwin. Add a "command" key
to the dictionary returned by getbufinfo() to differentiate
the cmdwin buffer instead. (Sean Dewar)
Cherry-pick test_normal changes from v9.0.0954.
1fb4103206
Problem: Cannot map Super Keys in GTK UI
(Casey Tucker)
Solution: Enable Super Key mappings in GTK using <D-Key>
(Casey Tucker)
As a developer who works in both Mac and Linux using the same keyboard,
it can be frustrating having to remember different key combinations or
having to rely on system utilities to remap keys.
This change allows `<D-z>` `<D-x>` `<D-c>` `<D-v>` etc. to be recognized
by the `map` commands, along with the `<D-S-...>` shifted variants.
```vimrc
if has('gui_gtk')
nnoremap <D-z> u
nnoremap <D-S-Z> <C-r>
vnoremap <D-x> "+d
vnoremap <D-c> "+y
cnoremap <D-v> <C-R>+
inoremap <D-v> <C-o>"+gP
nnoremap <D-v> "+P
vnoremap <D-v> "-d"+P
nnoremap <D-s> :w<CR>
inoremap <D-s> <C-o>:w<CR>
nnoremap <D-w> :q<CR>
nnoremap <D-q> :qa<CR>
nnoremap <D-t> :tabe<CR>
nnoremap <D-S-T> :vs#<CR><C-w>T
nnoremap <D-a> ggVG
vnoremap <D-a> <ESC>ggVG
inoremap <D-a> <ESC>ggVG
nnoremap <D-f> /
nnoremap <D-g> n
nnoremap <D-S-G> N
vnoremap <D-x> "+x
endif
```
closes: vim/vim#1269892e90a1e10
Co-authored-by: Casey Tucker <dctucker@hotmail.com>
Extmarks can contain URLs which can then be drawn in any supporting UI.
In the TUI, for example, URLs are "drawn" by emitting the OSC 8 control
sequence to the TTY. On terminals which support the OSC 8 sequence this
will create clickable hyperlinks.
URLs are treated as inline highlights in the decoration subsystem, so
are included in the `DecorSignHighlight` structure. However, unlike
other inline highlights they use allocated memory which must be freed,
so they set the `ext` flag in `DecorInline` so that their lifetimes are
managed along with other allocated memory like virtual text.
The decoration subsystem then adds the URLs as a new highlight
attribute. The highlight subsystem maintains a set of unique URLs to
avoid duplicating allocations for the same string. To attach a URL to an
existing highlight attribute we call `hl_add_url` which finds the URL in
the set (allocating and adding it if it does not exist) and sets the
`url` highlight attribute to the index of the URL in the set (using an
index helps keep the size of the `HlAttrs` struct small).
This has the potential to lead to an increase in highlight attributes
if a URL is used over a range that contains many different highlight
attributes, because now each existing attribute must be combined with
the URL. In practice, however, URLs typically span a range containing a
single highlight (e.g. link text in Markdown), so this is likely just a
pathological edge case.
When a new highlight attribute is defined with a URL it is copied to all
attached UIs with the `hl_attr_define` UI event. The TUI manages its own
set of URLs (just like the highlight subsystem) to minimize allocations.
The TUI keeps track of which URL is "active" for the cell it is
printing. If no URL is active and a cell containing a URL is printed,
the opening OSC 8 sequence is emitted and that URL becomes the actively
tracked URL. If the cursor is moved while in the middle of a URL span,
we emit the terminating OSC sequence to prevent the hyperlink from
spanning multiple lines.
This does not support nested hyperlinks, but that is a rare (and,
frankly, bizarre) use case. If a valid use case for nested hyperlinks
ever presents itself we can address that issue then.
'foldtext' can be set to an empty string to disable and render the
line with:
- extmark highlight
- syntax highlighting
- search highlighting
- no line wrapping
- spelling
- conceal
- inline virtual text
- respects `fillchars:fold`
Currently normal virtual text is not displayed
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem: too vague errors for 'listchars'/'fillchars'
Solution: Include the field name in error message.
(zeertzjq)
related: #27050closes: vim/vim#138776a8d2e1634
Co-authored-by: Cole Frankenhoff <cole.nhf@gmail.com>
Problem: Vim is missing a foreach() func
Solution: Implement foreach({expr1}, {expr2}) function,
which applies {expr2} for each item in {expr1}
without changing it (Ernie Rael)
closes: vim/vim#12166e79e207760
Partial port as this doesn't handle non-materialized range() lists.
vim-patch:c92b8bed1fa6
runtime(help): delete duplicate help tag E741 (vim/vim#13861)
c92b8bed1f
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: Cannot easily get the list of matches
Solution: Add the matchstrlist() and matchbufline() Vim script
functions (Yegappan Lakshmanan)
closes: vim/vim#13766
Omit CHECK_LIST_MATERIALIZE(): it populates a List with numbers only,
and there is a check for strings below.
f93b1c881a
vim-patch:eb3475df0d92
runtime(doc): Replace non-breaking space with normal space (vim/vim#13868)
eb3475df0d
Co-authored-by: Yegappan Lakshmanan <4298407+yegappan@users.noreply.github.com>
- Add section `VIM.LPEG` and `VIM.RE` to docs/lua.txt.
- Add `_meta/re.lua` which adds luadoc and type annotations, for the
vendored `vim.re` package.
- Fix minor style issues on `_meta/lpeg.lua` luadoc for better vimdocs
generation.
- Fix a bug on `gen_vimdoc` where non-helptags in verbatim code blocks
were parsed as helptags, affecting code examples on `vim.lpeg.Cf`,
etc.
- Also move the `vim.regex` section below so that it can be located
closer to `vim.lpeg` and `vim.re`.
This commit implements a new TermRequest autocommand event and has Neovim
emit this event when children of terminal buffers emit an OSC or DCS sequence
libvterm does not handle.
The TermRequest autocommand event has additional data in the
v:termrequest variable.
Co-authored-by: Gregory Anders <greg@gpanders.com>
Problem: Some lines in the generated vim doc are overflowing, not
correctly wrapped at 78 characters. This happens when docs body contains
several consecutive 'inline' elements generated by doxygen.
Solution: Take into account the current column offset of the last line,
and prepend some padding before doc_wrap().
Problem: Keymap completion is not available
Solution: Add keymap completion (Doug Kearns)
Add keymap completion to the 'keymap' option, user commands and builtin
completion functions.
closes: vim/vim#1369281642d9d6f
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: The maximum 'statuscolumn' width and grow behavior is undocumented.
Solution: Define, use and document the maximum 'statuscolumn' width and grow behavior.
Problem:
Many decoration providers (treesitter injection highlighting, semantic
token highlighting, inlay hint) rely on the correctness of the `botline`
argument of `on_win` callback. However, `botline` can be smaller than
the actual line number of the last displayed line if some lines are
folded. In such cases, some decorations will be missing in the lines not
covered by `botline`.
Solution:
Validate `botline` when invoking `on_win`.
NOTE:
It seems that the old code was deliberately avoiding this presumably due
to performance reasons. However, I haven't experienced noticeable lag
after this change, and I believe the cost of botline computation would
be much smaller than the cost of decoration providers.
Problem:
For function definitions to be included in the vimdoc (formatted) and
to be exported as mpack data (unformatted), we had two internal
representations of the same function/API metadata in duplicate;
one is FunctionDoc (which was previously a dict), and the other is
doxygen XML DOM from which vimdoc (functions sections) was generated.
Solution:
We should have a single path and unified data representation
(i.e. FunctionDoc) that contains all the metadata and information about
function APIs, from which both of mpack export and vimdoc are generated.
I.e., vimdocs are no longer generated directly from doxygen XML nodes,
but generated via:
(XML DOM Nodes) ------------> FunctionDoc ------> mpack (unformatted)
Recursive Internal |
Formatting Metadata +---> vimdoc (formatted)
This refactoring eliminates the hacky and ugly use of `fmt_vimhelp` in
`fmt_node_as_vimhelp()` and all other helper functions! This way,
`fmt_node_as_vimhelp()` can simplified as it no longer needs to handle
generating of function docs, which needs to be done only in the topmost
level of recursion.
Problem: Unable to predict which byte-offset to place virtual text to
make it repeat visually in the wrapped part of a line.
Solution: Add a flag to nvim_buf_set_extmark() that causes virtual
text to repeat in wrapped lines.
Problem: Maximum callback depth is not configurable.
Solution: Revert patch 9.0.2103. Set 'maxfuncdepth' in test.
fixes: vim/vim#13732closes: vim/vim#13736fe583b1e59
Currently, setting &bg at all re-initializes highlights and reloads
the active colorscheme, even if the actual value of &bg has not changed.
With https://github.com/neovim/neovim/pull/26595 this causes a
regression since &bg is set unconditionally based on the value detected
from the terminal.
Instead, only reload the colorscheme if the actual value of &bg has
changed.
runtime(doc): remove deprecation warning for gdefault
Deprecated can be misunderstood as being slated for removal; slightly
change wording to be clearer.
82f19734bf
Co-authored-by: dundargoc <gocdundar@gmail.com>
Problem:
Unlike termopen(), nvim_open_term() PTYs do not carriage-return the
cursor on newline ("\n") input.
nvim --clean
:let chan_id = nvim_open_term(1, {})
:call chansend(chan_id, ["here", "are", "some", "lines"])
Actual behavior:
here
are
some
lines
Expected behaviour:
here
are
some
lines
Solution:
Add `force_crlf` option, and enable it by default.
Enable 'termguicolors' automatically when Nvim can detect that truecolor
is supported by the host terminal.
If $COLORTERM is set to "truecolor" or "24bit", or the terminal's
terminfo entry contains capabilities for Tc, RGB, or setrgbf and
setrgbb, then we assume that the terminal supports truecolor. Otherwise,
the terminal is queried (using both XTGETTCAP and SGR + DECRQSS). If the
terminal's response to these queries (if any) indicates that it supports
truecolor, then 'termguicolors' is enabled.
Problem:
Empty string is a valid JSON key, but json_decode() treats an object
with empty key as ":help msgpack-special-dict". #20757
:echo json_decode('{"": "1"}')
{'_TYPE': [], '_VAL': [['', '1']]}
Note: vim returns `{'': '1'}`.
Solution:
Allow empty string as an object key.
Note that we still (currently) disallow empty keys in object_to_vim() (since 7c01d5ff92):
f64e4b43e1/src/nvim/api/private/converter.c (L333-L334)Fix#20757
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: No test for mode() when executing Ex commands
Solution: Add some test cases and simplify several other test cases.
Also add a few more test cases for ModeChanged.
closes: vim/vim#13588fcaeb3d42b
decor->text.str pointer must go. This removes it for conceal char,
in preparation for a larger PR which will also handle the sign case.
By actually allowing composing chars for a conceal chars, this
becomes a feature and not just a refactor, as a bonus.
runtime(doc): Fix whitespace and formatting of some help files (vim/vim#13549)
596a9f29c8
N/A patch:
vim-patch:aabca259fa48
Co-authored-by: h_east <h.east.727@gmail.com>
Problem: The legacy signlist data structures and associated functions are
redundant since the introduction of extmark signs.
Solution: Store signs defined through the legacy commands in a hashmap, placed
signs in the extmark tree. Replace signlist associated functions.
Usage of the legacy sign commands should yield no change in behavior with the
exception of:
- "orphaned signs" are now always removed when the line it is placed on is
deleted. This used to depend on the value of 'signcolumn'.
- It is no longer possible to place multiple signs with the same identifier
in a single group on multiple lines. This will now move the sign instead.
Moreover, both signs placed through the legacy sign commands and through
|nvim_buf_set_extmark()|:
- Will show up in both |sign-place| and |nvim_buf_get_extmarks()|.
- Are displayed by increasing sign identifier, left to right.
Extmark signs used to be ordered decreasingly as opposed to legacy signs.
Problem: buffer text with composing chars are converted from UTF-8
to an array of up to seven UTF-32 values and then converted back
to UTF-8 strings.
Solution: Convert buffer text directly to UTF-8 based schar_T values.
The limit of the text size is now in schar_T bytes, which is currently
31+1 but easily could be raised as it no longer multiplies the size
of the entire screen grid when not used, the full size is only required
for temporary scratch buffers.
Also does some general cleanup to win_line text handling, which was
unnecessarily complicated due to multibyte rendering being an "opt-in"
feature long ago. Nowadays, a char is just a char, regardless if it consists
of one ASCII byte or multiple bytes.
The 'termsync' option enables a mode (provided the underlying terminal
supports it) where all screen updates during a redraw cycle are buffered
and drawn together when the redraw is complete. This eliminates tearing
or flickering in cases where Nvim redraws slower than the terminal
redraws the screen.
Problem: recursive callback may cause issues on some archs
Solution: Decrease the limit drastically to 20
Recursive callback limit causes problems on some architectures
Since commit 47510f3d6598a1218958c03ed11337a43b73f48d we have a test
that causes a recursive popup callback function to be executed. However
it seems the current limit of 'maxfuncdepth' option value is still too
recursive for some 32bit architectures (e.g. 32bit ARM).
So instead of allowing a default limit of 100 (default value for
'maxfuncdepth'), let's reduce this limit to 20. I don't think there is a
use case where one would need such a high recursive callback limit and a
limit of 20 seems reasonable (although it is currently hard-coded).
closes: vim/vim#13495closes: vim/vim#135022076463e38
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Not easy to filter the output of maplist().
Solution: Add mode_bits to the dictionary. (Ernie Rael, closesvim/vim#10356)
d8f5f76621
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: It is not easy to restore saved mappings.
Solution: Make mapset() accept a dict argument. (Ernie Rael, closesvim/vim#10295)
51d04d16f2
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: Can only get a list of mappings.
Solution: Add the optional {abbr} argument. (Ernie Rael, closesvim/vim#10277)
Rename to maplist(). Rename test file.
09661203ec
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: Not simple programmatic way to find a specific mapping.
Solution: Add getmappings(). (Ernie Rael, closesvim/vim#10273)
659c240cf7
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: maparg() does not indicate the type of script where it was defined.
Solution: Add "scriptversion".
a9528b39a6
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: statusline may look different than expected
Solution: do not check for highlighting of stl and stlnc characters
statusline fillchar may be different than expected
If the highlighting group for the statusline for the current window
|hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared
(or do not differ from each other), than Vim will use the hard-coded
fallback values '^' (for the non-current windows) or '=' (for the
current window). I believe this was done, to make sure the statusline
will always be visible and be distinguishable from the rest of the
window.
However, this may be unexpected, if a user explicitly defined those
fillchar characters just to notice that those values are then not used
by Vim.
So, let's assume users know what they are doing and just always return
the configured stl and stlnc values. And if they want the statusline to
be non-distinguishable from the rest of the window space, so be it. It
is their responsibility and Vim shall not know better what to use.
fixes: vim/vim#13366closes: vim/vim#134886a650bf696
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: No way to have extmarks automatically removed when the range it
is attached to is deleted.
Solution: Add new 'invalidate' property that will hide a mark when the
entirety of its range is deleted. When "undo_restore" is set
to false, delete the mark from the buffer instead.
When the terminal emulator sends an OSC sequence to Nvim (as a response
to another OSC sequence that was first sent by Nvim), populate the OSC
sequence in the v:termresponse variable and fire the TermResponse event.
The escape sequence is also included in the "data" field of the
autocommand callback when the autocommand is defined in Lua.
This makes use of the already documented but unimplemented TermResponse
event. This event exists in Vim but is only fired when Vim receives a
primary device attributes response.
Fixes: https://github.com/neovim/neovim/issues/25856
runtime(doc): all secure options should note this restriction in the documentation (vim/vim#13448)
Problem: Not all secure options document their status
Solution: Describe secure context :set restrictions in each help entry
8ebdbc9e6d
Co-authored-by: dkearns <dougkearns@gmail.com>
Problem: trim(): hard to use default mask (partly revert v9.0.2040)
Solution: use default mask when it is empty
The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.
Currently, an empty 'mask' will make 'trim()' call return 'text' value
that is passed in unmodified. It is unlikely that someone is using it,
so the chances of scripts being broken by this change are low.
Also, this reverts commit 9.0.2040 (which uses v:none for the default
and requires to use an empty string instead).
closes: vim/vim#133588079917447
vim-patch:9.0.2040: trim(): hard to use default mask
Problem: trim(): hard to use default mask
Solution: Use default 'mask' when it is v:none
The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.
'v:none' is already used to mean "use the default argument value" in
user defined functions. See |none-function_argument| in help.
closes: vim/vim#133636e6386716f
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>
Problem: [security] use-after-free with wildmenu
Solution: properly clean up the wildmenu when exiting
Fix wildchar/wildmenu/pum memory corruption with special wildchar's
Currently, using `wildchar=<Esc>` or `wildchar=<C-\>` can lead to a
memory corruption if using wildmenu+pum, or wrong states if only using
wildmenu. This is due to the code only using one single place inside the
cmdline process loop to perform wild menu clean up (by checking
`end_wildmenu`) but there are other odd situations where the loop could
have exited and we need a post-loop clean up just to be sure. If the
clean up was not done you would have a stale popup menu referring to
invalid memory, or if not using popup menu, incorrect status line (if
`laststatus=0`).
For example, if you hit `<Esc>` two times when it's wildchar, there's a
hard-coded behavior to exit command-line as a failsafe for user, and if
you hit `<C-\><C-\><C-N>` it will also exit command-line, but the clean
up code would not have hit because of specialized `<C-\>` handling.
Fix Ctrl-E / Ctrl-Y to not cancel/accept wildmenu if they are also
used for 'wildchar'/'wildcharm'. Currently they don't behave properly,
and also have potentially memory unsafe behavior as the logic is
currently not accounting for this situation and try to do both.
(Previous patch that addressed this: vim/vim#11677)
Also, correctly document Escape key behavior (double-hit it to escape)
in wildchar docs as it's previously undocumented.
In addition, block known invalid chars to be set in `wildchar` option,
such as Ctrl-C and `<CR>`. This is just to make it clear to the user
they shouldn't be set, and is not required for this bug fix.
closes: vim/vim#133618f4fb007e4
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
