| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
fix(decorations): do not apply sign highlight id as range attr id
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: ml_get error when scrolling after delete
Solution: mark topline to be validated in main_loop
if it is larger than current buffers line
count
reset_lnums() is called after e.g. TextChanged autocommands and it may
accidentally cause curwin->w_topline to become invalid, e.g. if the
autocommand has deleted some lines.
So verify that curwin->w_topline points to a valid line and if not, mark
the window to have w_topline recalculated in main_loop() in
update_topline() after reset_lnums() returns.
fixes: vim/vim#13568
fixes: vim/vim#13578
https://github.com/vim/vim/commit/c4ffeddfe5bd1824650e9b911ed9245bf56c69e3
The error doesn't happen in Nvim because Nvim triggers TextChanged after
calling update_topline().
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
| |
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#13588
https://github.com/vim/vim/commit/fcaeb3d42b228e73c669b2fce78f1d3fe112769f
|
| | |
|
| |
|
|
|
|
| |
Problem: Signcolumn width does not increase when ranged sign does not
start at sentinel line.
Solution: Handle paired range of added sign when checking signcols.
|
| |\
| |
| | |
feat(decoration): allow conceal_char to be a composing char
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Problem: Cannot detect overstrike mode in Cmdline mode
Solution: Make mode() return "cr" for overstrike
closes: vim/vim#13569
https://github.com/vim/vim/commit/d1c3ef1f47c87d1da056c56564e1985fe6f2931d
|
| |/
|
|
|
|
|
|
|
|
| |
Problem: not all nushell files detected
Solution: use *.nu to detect nushell files
closes: vim/vim#13586
https://github.com/vim/vim/commit/b9efc72c2432f2d2a633c12d3a5b9fc3efb7b6e7
Co-authored-by: Daniel Buch Hansen <boogiewasthere@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
When parsing with a range, languagetree looks up injections and adds
them if needed. This explicitly invalidates parser, making `is_valid`
report `false` both when including and excluding children.
This is an attempt to describe desired behaviour of `is_valid` in tests,
with what ended up being a single line change to satisfy them.
|
| | |
|
| |
|
|
|
|
|
| |
`vim.wait()` cannot be called in a fast callback since the main loop
cannot be run in that context as it is not reentrant
Fixes #26122
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add syntax and filetype plugins for SWIG (Simplified Wrapper Interface
Generator) description files.
The default syntax for .i files highlights comments in a reverse
color scheme which doesn't look well. This syntax builds
on vim's c++ syntax by adding highlighting for common swig
directives and user defined directives. For an alternative
syntax, see vimscript vim/vim#1247 (which I found after writing this).
closes: vim/vim#13562
https://github.com/vim/vim/commit/2e31065a650015892179e520038bf2083a9519b6
Co-authored-by: Julien Marrec <julien.marrec@gmail.com>
Co-authored-by: Matěj Cepl <mcepl@cepl.eu>
|
| |\
| |
| | |
fix(oldtest): always use a 64-bit int for swapfile block number
|
| | |
| |
| |
| | |
09d4133 changed blocknr_T from long to int64_t, so pe_bnum is now always 64-bit. This was an incompatible change in the swapfile format for 32-bit systems, but there have been no complaints in the past 9 years so just adjust the test.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Problem: Unused assignments when checking the value of 'listchars'.
Solution: Loop only once when just checking the value. Add a test to
check that this change doesn't cause double-free.
closes: vim/vim#13559
https://github.com/vim/vim/commit/00624a2fa08d04bdded240d474e9cfdc193dbe10
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem: File info disappears immediately when 'cmdheight' has just
decreased due to switching tabpage and 'shortmess' doesn't
contain 'o' or 'O'.
Solution: Make sure msg_row isn't smaller than cmdline_row.
fixes: vim/vim#13560
closes: vim/vim#13561
https://github.com/vim/vim/commit/40ed6711bd385051021691980e8ce16375b4b510
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: [security]: use-after-free in ex_substitute
Solution: always allocate memory
closes: vim/vim#13552
A recursive :substitute command could cause a heap-use-after free in Vim
(CVE-2023-48706).
The whole reproducible test is a bit tricky, I can only reproduce this
reliably when no previous substitution command has been used yet
(which is the reason, the test needs to run as first one in the
test_substitute.vim file) and as a combination of the `:~` command
together with a :s command that contains the special substitution atom `~\=`
which will make use of a sub-replace special atom and calls a vim script
function.
There was a comment in the existing :s code, that already makes the
`sub` variable allocate memory so that a recursive :s call won't be able
to cause any issues here, so this was known as a potential problem
already. But for the current test-case that one does not work, because
the substitution does not start with `\=` but with `~\=` (and since
there does not yet exist a previous substitution atom, Vim will simply
increment the `sub` pointer (which then was not allocated dynamically)
and later one happily use a sub-replace special expression (which could
then free the `sub` var).
The following commit fixes this, by making the sub var always using
allocated memory, which also means we need to free the pointer whenever
we leave the function. Since sub is now always an allocated variable,
we also do no longer need the sub_copy variable anymore, since this one
was used to indicated when sub pointed to allocated memory (and had
therefore to be freed on exit) and when not.
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-c8qm-x72m-q53q
https://github.com/vim/vim/commit/26c11c56888d01e298cd8044caf860f3c26f57bb
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
| |
Problem: Unable to identify legacy signs when fetching extmarks with
`nvim_buf_get_extmarks()`.
Solution: Add "sign_name" to the extmark detail array.
Add some misc. changes as follow-up to #25724
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the monolithic Decoration struct. Before this change, each extmark
could either represent just a hl_id + priority value as a inline
decoration, or it would take a pointer to this monolitic 112 byte struct
which has to be allocated.
This change separates the decorations into two pieces: DecorSignHighlight
for signs, highlights and simple set-flag decorations (like spell,
ui-watched), and DecorVirtText for virtual text and lines.
The main separation here is whether they are expected to allocate more
memory. Currently this is not really true as sign text has to be an
allocated string, but the plan is to get rid of this eventually (it can
just be an array of two schar_T:s). Further refactors are expected to
improve the representation of each decoration kind individually. The
goal of this particular PR is to get things started by cutting the
Gordian knot which was the monolithic struct Decoration.
Now, each extmark can either contain chained indicies/pointers to
these kinds of objects, or it can fit a subset of DecorSignHighlight
inline.
The point of this change is not only to make decorations smaller in
memory. In fact, the main motivation is to later allow them to grow
_larger_, but on a dynamic, on demand fashion. As a simple example, it
would be possible to augment highlights to take a list of multiple
`hl_group`:s, which then would trivially map to a chain of multiple
DecorSignHighlight entries.
One small feature improvement included with this refactor itself, is
that the restriction that extmarks cannot be removed inside a decoration
provider has been lifted. These are instead safely lifetime extended
on a "to free" list until the current iteration of screen drawing is done.
NB: flags is a mess. but DecorLevel is useless, this slightly less so
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Problem: No test for defining sign without attribute
Solution: Add test for defining sign without attributes
closes: vim/vim#13544
https://github.com/vim/vim/commit/e670d17342ea05af253b0452afb980397fa143be
|
| |
|
|
|
|
|
|
|
| |
Quick fix as follow up to https://github.com/neovim/neovim/pull/26108
kqueue only reports events on a watched folder itself, not for files
created or deleted within. So the approach the PR took doesn't work on FreeBSD.
We'll either need to bring back polling for it, combine watching with manual
file tracking, or disable LSP file watching on FreeBSD
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Should help with https://github.com/neovim/neovim/issues/23291
On linux `new_fs_event` doesn't support recursive watching, but we can
still use it to watch folders.
The downside of this approach is that we may end up sending some false
`Deleted` events. For example, if you save a file named `foo` there will
be a intermediate `foo~` due to the save mechanism of neovim.
The events we get from vim.uv in that case are:
- rename: foo~
- rename: foo~
- rename: foo
- rename: foo
- change: foo
- change: foo
The mechanism in this PR uses a debounce to reduce this to:
- deleted: foo~
- changed: foo
`foo~` will be the false positive.
I suspect that for the LSP case this is good enough. If not, we may need
to follow up on this and keep a table in memory that tracks available
files.
|
| |\
| |
| | |
refactor(sign): move legacy signs to extmarks
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
The test is for the case without 'termsync' because libvterm doesn't
support synchronized output, and it passes without this PR.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: [security]: Use-after-free in win_close()
Solution: Check window is valid, before accessing it
If the current window structure is no longer valid (because a previous
autocommand has already freed this window), fail and return before
attempting to set win->w_closing variable.
Add a test to trigger ASAN in CI
https://github.com/vim/vim/commit/25aabc2b8ee1e19ced6f4da9d866cf9378fc4c5a
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: [security] use-after-free from buf_contents_changed()
Solution: block autocommands
https://github.com/vim/vim/commit/41e6f7d6ba67b61d911f9b1d76325cd79224753d
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: segfault in exmode when redrawing
Solution: skip gui_scroll when exmode_active
https://github.com/vim/vim/commit/20d161ace307e28690229b68584f2d84556f8960
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: buffer-overflow in trunc_string()
Solution: Add NULL at end of buffer
Currently trunc_string() assumes that when the string is too long,
buf[e-1] will always be writeable. But that assumption may not always be
true. The condition currently looks like this
else if (e + 3 < buflen)
[...]
else
{
// can't fit in the "...", just truncate it
buf[e - 1] = NUL;
}
but this means, we may run into the last else clause with e still being
larger than buflen. So a buffer overflow occurs.
So instead of using `buf[e - 1]`, let's just always
truncate at `buf[buflen - 1]` which should always be writable.
https://github.com/vim/vim/commit/3bd7fa12e146c6051490d048a4acbfba974eeb04
vim-patch:9.0.2004: Missing test file
Problem: Missing test file
Solution: git-add the file to the repo
closes: vim/vim#13305
https://github.com/vim/vim/commit/d4afbdd0715c722cfc73d3a8ab9e578667615faa
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Trailing white space in tests
Solution: Delete it
This causes test_codestyle to fail, so we need to remove it again.
Hopefully that makes the CI green again.
Note: I will start using annotated tags from now on.
https://github.com/vim/vim/commit/da200c2f78ef3c91557a2b484d284eb0c1c62776
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
