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: still some issues with term_debug test
Solution: Use WaitForAssert()
closes: vim/vim#1293685c3a5bc26
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: No tests for the termdebug plugin
Solution: Add some simple tests for the termdebug plugin
closes: vim/vim#1292758f39d89a8
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
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 contents of a quickfix buffer are replaced, there is a chance
that deletion of the previous lines fails. This ensures that we don't
get stuck in an infinite loop of retrying.
Fix#25402
This ensures that the read stream never overflows termkey's internal
buffer. This only happens when a large amount of bytes are pushed into
termkey at the same time, which is exactly what happens when we receive
a large OSC 52 response.
This allow distributions and other interested parties to use a system
busted rather than the on neovim bundles by passing the
-D USE_BUNDLED_BUSTED=ON flag to cmake when building.
Closes https://github.com/neovim/neovim/issues/23814.
Python3 provider tests suddenly became extremely flaky on macos for
unknown reasons. For some reason, installing python with the
setup-python action over using the default python fixes the flakiness.
Use this workaround for the time being to unblock CI while we figure out
the root cause.
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
Problem: tests: failure in test_arabic
Solution: adjust the test for the changed arabic keymap
2a94e98792
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(tar): improve the error detection
Do not rely on the fact, that the last line matches warning, error,
inappropriate or unrecognized to determine if an error occurred. It
could also be a file, contains such a keyword.
So make the error detection slightly more strict and only assume an
error occured, if in addition to those 4 keywords, also a space matches
(this assumes the error message contains a space), which luckily on Unix
not many files match by default.
The whole if condition seems however slightly dubious. In case an error
happened, this would probably already be caught in the previous if
statement, since this checks for the return code of the tar program.
There may however be tar implementations, that do not set the exit code
for some kind of error (but print an error message)? But let's keep this
check for now, not many people have noticed this behaviour until now, so
it seems to work reasonably well anyhow.
related: vim/vim#6425fixes: vim/vim#134893d37231437
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(dist): Make dist/vim.vim work properly when lacking vim9script support (vim/vim#13487)
`:return` cannot be used outside of `:function` (or `:def`) in older Vims
lacking Vim9script support or in Neovim, even when evaluation is being skipped
in the dead `:else` branch.
Instead, use the pattern described in `:h vim9-mix`, which uses `:finish` to end
script processing before it reaches the vim9script stuff.
b2a4c110a5
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
runtime(dist): add legacy version for central vim library
Also, enable the zip and gzip plugins by default, unless those variables
were not explicitly set by the user.
related: vim/vim#134134f174f0de9
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(dist): centralize safe executable check and add vim library (vim/vim#13413)
Follow up to 816fbcc26 (patch 9.0.1833: [security] runtime file fixes,
2023-08-31) and f7ac0ef50 (runtime: don't execute external commands when
loading ftplugins, 2023-09-06).
This puts the logic for safe executable checks in a single place, by introducing
a central vim library, so all filetypes benefit from consistency.
Notable changes:
- dist#vim because the (autoload) namespace for a new runtime support
library. Supporting functions should get documentation. It might make
life easier for NeoVim devs to make the documentation a new file
rather than cram it into existing files, though we may want
cross-references to it somewhere…
- The gzip and zip plugins need to be opted into by enabling execution
of those programs (or the global plugin_exec). This needs
documentation or discussion.
- This fixes a bug in the zig plugin: code setting s:tmp_cwd was removed
in f7ac0ef50 (runtime: don't execute external commands when loading
ftplugins, 2023-09-06), but the variable was still referenced. Since
the new function takes care of that automatically, the variable is no
longer needed.
cd8a3eaf53
Co-authored-by: D. Ben Knoble <ben.knoble+github@gmail.com>
We do not have any patches that we use at the moment, so git is not
needed right now. Futhermore, we've become more strict with not adding
patches, which makes it pretty safe to remove this for the time being.
It is enabled with ENABLE_ASAN_UBSAN like other compilers. Technically
it only enables ASAN as UBSAN is not available, meaning to make the
variable names fully correct we'd need to separate it into two checks:
ENABLE_ASAN and ENABLE_UBSAN, but the convenience of combining them into
the same flag outweighs the theoretical correctness.
Also note in CONTRIBUTING.md that debug builds in ASAN is not supported.
Technically it is the debug runtime that is not supported, which cmake
automatically enables when using the debug build type. However, neovim
can't be built with debug builds without linking to the debug runtime
since the third party libraries has likely been linked to the debug
runtime if it was built with debug build type. This technicality is
likely uninteresting to the potential developer and it's easier to just
say to use a release build type.
problem: checks for wp->w_p_rl are all over the place, making simple
things like "advance column one cell" incredibly complicated.
solution: always fill linebuf_char[] using an incrementing counter,
and then mirror the buffer as a post-processing step
This was "easier" that I first feared, because the stupid but simple
workaround for things like keeping linenumbers still left-right,
e.g. "mirror them and them mirror them once more" is more or less
what vim did already. So let's just keep doing that.
long is 32 bits on windows, while it is 64 bits on other architectures.
This makes the type suboptimal for a codebase meant to be
cross-platform. Replace it with more appropriate integer types.
