| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
refactor(drawline): avoid xmalloc/xfree cycles on each screenline
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When the given length is exactly the number of bytes to copy, xmemdupz()
makes the intention clearer.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Problem: Not easy to filter the output of maplist().
Solution: Add mode_bits to the dictionary. (Ernie Rael, closes vim/vim#10356)
https://github.com/vim/vim/commit/d8f5f766219273a8579947cc80b92580b6988a4b
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, closes vim/vim#10295)
https://github.com/vim/vim/commit/51d04d16f21e19d6eded98f9530d84089102f925
Co-authored-by: Ernie Rael <errael@raelity.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Problem: Can only get a list of mappings.
Solution: Add the optional {abbr} argument. (Ernie Rael, closes vim/vim#10277)
Rename to maplist(). Rename test file.
https://github.com/vim/vim/commit/09661203ecefbee6a6f09438afcff1843e9dbfb4
Co-authored-by: Ernie Rael <errael@raelity.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Problem: Not simple programmatic way to find a specific mapping.
Solution: Add getmappings(). (Ernie Rael, closes vim/vim#10273)
https://github.com/vim/vim/commit/659c240cf769925ff432b88df8719e7ace4629b0
Co-authored-by: Ernie Rael <errael@raelity.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Problem: maparg() does not indicate the type of script where it was defined.
Solution: Add "scriptversion".
https://github.com/vim/vim/commit/a9528b39a666dbaa026320f73bae4b1628a7fe51
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#13366
closes: vim/vim#13488
https://github.com/vim/vim/commit/6a650bf696f1df3214b3d788947447c5bbf1a77d
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Move default mappings and autocommands into a separate module and add
comments and docstrings to document each of the defaults.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
feat(extmarks): add 'invalidate' property
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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
|
| | |\ \ \ \ \ \
| | |/ / / / /
| |/| | | | | |
refactor(grid): reimplement 'rightleft' as a post-processing step
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
feat(extmarks): add "no_undo_restore" flag to opt out of undo-restoring
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
It is a design goal of extmarks that they allow precise tracking
of changes across undo/redo, including restore the exact positions
after a do/undo or undo/redo cycle. However this behavior is not useful
for all usecases. Many plugins won't keep marks around for long after
text changes, but uses them more like a cache until some external source
(like LSP semantic highlights) has fully updated to changed text and
then will explicitly readjust/replace extmarks as needed.
Add a "undo_restore" flag which is true by default (matches existing
behavior) but can be set to false to opt-out of this behavior.
Delete dead u_extmark_set() code.
|
