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>
When pasting with OSC 52 some terminals show a prompt to the user asking
for permission to read from the system clipboard. When this prompt
appears, 1s is not long enough to wait.
Increase the timeout to 10s and show a message to the user indicating
how to interrupt the wait after 1s.
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(script.vim): make strace ft check less strict (vim/vim#13482)
Strace output, depending on parameters (-ttf this time), can dump both
times and pid:
1038 07:14:20.959262 execve("./e.py", ["./e.py"], 0x7ffca1422840 /* 51 vars */) = 0 <0.000150>
So loose the regexp matching this, so that the above is matched too.
Fixesvim/vim#13481.
2f54c13292
Co-authored-by: Jiri Slaby <jirislaby@gmail.com>
Co-authored-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
`code_action` used the same parameters for all clients, which led to the
following warning and incorrect start/end column locations if using
clients with mixed encodings:
warning: multiple different client offset_encodings detected for
buffer, this is not supported yet
Problem: Currently there is no way of customizing behavior of
`declaration`, `definition`, `typeDefinition`, and `implementation`
methods in `vim.lsp.buf` when LSP server returns `Location`. Instead,
cursor jumps to that location directly.
Solution: Normalize LSP response to be `Location[]` for those four cases.
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>
The prefix option of the diagnostic virtual text can be a function,
but previously it was only a function of diagnostic.
This function should also have additional parameters index and total,
more consistently and similarily as in the prefix function for
`vim.diagnostic.open_float()`.
These additional parameters will be useful when there are too many
number of diagnostics in a single line.
Problem: objdump files not recognized
Solution: detect *.objdump files, add a filetype plugin
Added the objdump file/text format
closes: vim/vim#1342510407df7a9
Co-authored-by: Colin Kennedy <colinvfx@gmail.com>
Fixes a regression from 5e5f5174e3
Until that commit we had a logic like this:
`local prefix = startbyte and line:sub(startbyte + 1) or line_to_cursor:sub(word_boundary)`
The commit changed the logic and no longer cut off the line at the cursor, resulting in a prefix that included trailing characters
Problem: Janet files are not recognised
Solution: Add filename and shebang detection (without
adding an extra filetype plugin)
Those are used by the Janet language:
http://www.janet-lang.orgcloses: vim/vim#13400c038427d2a
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: not able to detect xkb filetypes
Solution: Detect files below /u/s/X11/xkb as xkb files (without adding
an extra filetype)
Those files are used from the X11 xkb extension
closes: vim/vim#13401ae9021a840
Co-authored-by: Guido Cella <guido@guidocella.xyz>
Fixes https://github.com/neovim/neovim/issues/25177
I initially wanted to split this into a refactor commit to make it more
testable, but it appears that already accidentally fixed the issue by
normalizing lnum/col to 0-indexing
To be more in line with the specification:
> To support the evolution of enumerations the using side of an enumeration shouldn’t fail on an enumeration value it doesn’t know. It should simply ignore it as a value it can use and try to do its best to preserve the value on round trips
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>
Problem:
When enabling diagnostics, there can be diagnostics for unloaded buffer,
but some handlers nevertheless attempt to set extmarks in such buffers.
Solution:
* Exit underline/virtual_text handler if buffer is not loaded.
* Don't require is_loaded as precondition for show(), because handlers
don't necessarily depend on it.
Problem:
If a manpage is opened, its hardwrapped dimensions are not recalculated
after closing then revisiting the same manpage.
Solution:
Unload the manpage when it is hidden. This forces it to be reloaded,
which forces the hard-wrapping to be recalculated when it is revisited.
Fixes: #25457
