patch 9.1.0094: xxd: buffer-overflow when writing color output
Problem: xxd: buffer-overflow when writing color output
Solution: properly account for the color escape sequences and
adjust LLEN macro
(Goffredo Baroncelli)
xxd: crash with higer number of column
xxd writes the data into a buffer before printing. Unfortunately
the buffer doesn't consider the space consumed by the escape
sequences used to change the color of the character.
zeertzjq [Sat, 10 Feb 2024 12:24:03 +0000 (13:24 +0100)]
patch 9.1.0093: Still a qsort() comparison function that returns result of subtraction
Problem: Still a qsort() comparison function fuzzy_match_item_compare()
that returns result of subtraction (after 9.1.0089).
Solution: Use an explicit comparison instead of subtraction.
(zeertzjq)
closes: #14004
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0091: Syntax test fails when run with non C locale
Problem: Syntax test fails when run with non C locale
Solution: Run syntax tests with C locale, clean up Xtestscript file,
strip environment variables from GetVimCommand()
(h-east)
closes: #14007
Co-authored-by: h-east <h.east.727@gmail.com> Signed-off-by: h-east <h.east.727@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0089: qsort() comparison functions should be transitive
Problem: qsort() comparison functions should be transitive
Solution: Do not subtract values, but rather use explicit comparisons
Improve qsort() comparison functions
There has been a recent report on qsort() causing out-of-bounds read &
write in glibc for non transitive comparison functions
https://www.qualys.com/2024/01/30/qsort.txt
Even so the bug is in glibc's implementation of the qsort() algorithm,
it's bad style to just use substraction for the comparison functions,
which may cause overflow issues and as hinted at in OpenBSD's manual
page for qsort(): "It is almost always an error to use subtraction to
compute the return value of the comparison function."
So check the qsort() comparison functions and change them to be safe.
patch 9.1.0088: TextChanged not triggered for :norm! commands
Problem: TextChanged not triggered for :norm! commands
(machakann, after v9.0.2031)
Solution: Only reset curbuf->b_last_changedtick if TextChangedI
was triggered in insert mode (and not blocked)
Note: for unknown reasons, the test fails on Windows (but seems to work
fine when running interactively)
glepnir [Fri, 9 Feb 2024 18:30:26 +0000 (19:30 +0100)]
patch 9.1.0087: Restoring lastused_tabpage too early in do_arg_all()
Problem: Restore lastused_tabpage too early in do_arg_all() function it
will change later in the function.
Solution: Restore lastused_tabpage a bit later, when being done with
tabpages (glepnir)
closes: #13992
Signed-off-by: glepnir <glephunter@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
lilydjwg [Fri, 9 Feb 2024 18:24:23 +0000 (19:24 +0100)]
patch 9.1.0086: Problem when scrolling using slow touchpads scroll event
Problem: Problem when scrolling using slow touchpads scroll event
Solution: better ways to determine if a smooth scroll has ended (when
available) (lilydjwg)
related: #13997
Signed-off-by: lilydjwg <lilydjwg@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
lilydjwg [Fri, 9 Feb 2024 18:13:12 +0000 (19:13 +0100)]
patch 9.1.0085: X11 scroll size changes after accessing clipboard
Problem: X11 scroll size changes after accessing clipboard
(Ernie Rael)
Solution: use GDK_SCROLL_MASK for X11 and GDK_SMOOTH_SCROLL_MASK for
Wayland (lilydjwg)
because GDK_SCROLL_SMOOTH events don't work well for x11 (see comments).
fixes #13994
closes: #13997
Signed-off-by: lilydjwg <lilydjwg@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Thu, 8 Feb 2024 10:37:40 +0000 (11:37 +0100)]
patch 9.1.0083: Redrawing can be improved when deleting lines with 'number'
Problem: Redrawing can be improved when inserting/deleting lines with 'number'.
Solution: Only redraw the number column of lines below changed lines.
Add a test as this wasn't previously tested.
(zeertzjq)
closes: #13985
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Thu, 8 Feb 2024 10:34:55 +0000 (11:34 +0100)]
patch 9.1.0082: Redrawing can be improved when deleting lines with 'cursorline'
Problem: Redrawing can be improved when deleting lines with 'cursorline'.
Solution: Use smarter invalidation and adjustment. Remove unnecessary
UPD_VALID as it is already set at the top of the loop. Make
the test for #4862 fail without the fix.
(zeertzjq)
closes: #13986
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
I don't know why, but with GDK_SMOOTH_SCROLL_MASK we get wheel events as
GDK_SCROLL_SMOOTH. What's more, one wheel scroll is counted as 1.5
distance in Wayland but 1.0 in X11.
I failed to find any docs on gtk.org about this.
fixes: #13987
closes: #13991
Signed-off-by: lilydjwg <lilydjwg@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
qeatzy [Wed, 7 Feb 2024 16:52:25 +0000 (17:52 +0100)]
runtime(doc): Clarify list-concatenation a bit more
Make doc list-concatenation more clear as for += and extend().
1. describe `+=` for list-concatenation more accurately
2. add `extend()` example for list-concatenation
3. Fix CI errors for missing helptags reference |+=|
closes: #13983
Signed-off-by: qeatzy <qeatzy@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0080: unexpected error for modifying final list using +=
Problem: unexpected error for modifying final list using += operator
(Ernie Rael)
Solution: Allow List value modification of a final variable using +=
operator
(Yegappan Lakshmanan)
fixes: #13745
fixes: #13959
closes: #13962
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Added a syntax region for command blocks so that the highlighting of
`::` comments in them can be controlled. The `dosbatch_colons_comment`
variable now controls if all `::` comments in a code block are
highlighted as comments or errors. A `::` comment at the end of a
command block is always highlighted as an error.
This re-enables the highlighting of `::` comments in `.bat` files as
requested in #13666, while allowing control of highlighting them in
command blocks requested in #11778 and first attempted in #11980.
related: #11980
fixes: #13666
Co-authored-by: Mike Williams <mikew@globalgraphics.com> Signed-off-by: Mike Williams <mikew@globalgraphics.com> Signed-off-by: mevanlc <mevanlc@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Tue, 6 Feb 2024 09:43:36 +0000 (10:43 +0100)]
patch 9.1.0077: Unnecessary call to redraw_for_cursorline() in nv_mousescroll()
Problem: The call to redraw_for_cursorline() in nv_mousescroll() is
unnecessary because redraw_for_cursorline() only sets redraw
type to UPD_VALID, and all code paths in do_mousescroll()
already set redraw type to at least UPD_VALID.
Solution: Remove call to redraw_for_cursorline() in nv_mousescroll().
(zeertzjq)
closes: #13979
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
runtime(colors): color names in the v:colornames dict should be lower cased
Vim will lookup color names from the v:colornames dictionary by its
lower case color name. So when sourcing the v:colornames dictionary,
make sure to convert upper case color names to lower case.
Also, while at it, mention in the documentation, that the dictionary
should contain lower case names only.
fixes: #13976 Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Sat, 3 Feb 2024 17:04:05 +0000 (18:04 +0100)]
patch 9.1.0073: Looping over modifier_keys_table unnecessarily
Problem: Looping over modifier_keys_table[] unnecessarily with only
MOD_MASK_ALT or MOD_MASK_CMD, as modifier_keys_table[] only
contains MOD_MASK_SHIFT and MOD_MASK_CTRL, and the loop won't
do anything.
Solution: Remove MOD_MASK_ALT and MOD_MASK_CMD from the condition.
(zeertzjq)
closes: #13963
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Need a diff() Vim script function
Solution: Add the diff() Vim script function using the
xdiff internal diff library, add support for
"unified" and "indices" mode.
(Yegappan Lakshmanan)
fixes: #4241
closes: #12321
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
rhysd [Thu, 1 Feb 2024 20:22:14 +0000 (21:22 +0100)]
patch 9.1.0070: CI: testsuite not run on M1 Mac
Problem: CI: testsuite not run on M1 Mac
Solution: Make it run on gh runners for M1, disable failing tests for
now, until we figure the problem with the failings tests out
(rhysd)
closes: #13943
Signed-off-by: rhysd <lin90162@yahoo.co.jp> Signed-off-by: Christian Brabandt <cb@256bit.org>
Olaf Seibert [Thu, 1 Feb 2024 20:11:16 +0000 (21:11 +0100)]
patch 9.1.0069: ScreenLines may not be correctly initialized, causing hang
Problem: ScreenLines may not be correctly initialized, causing hang
(Olaf Seibert, after 9.0.0220)
Solution: always initialize ScreneLines when allocating a screen
(Olaf Seibert)
ScreenLines and related structures could be left uninitialized
causing a screen update to run into an infinite loop when using latin1
encoding.
Partly caused because by patch 9.0.0220, which makes mb_ptr2len return
zero for NUL
related: #12671
closes: #13946
Signed-off-by: Olaf Seibert <rhialto@falu.nl> Signed-off-by: Christian Brabandt <cb@256bit.org>
Maxim Kim [Thu, 1 Feb 2024 20:07:51 +0000 (21:07 +0100)]
patch 9.1.0068: Visual highlighting can still be improved
Problem: Visual highlighting can still be improved
Solution: Update Visual highlighting for 8 color terminals,
use uniform grey highlighting for dark and light bg
(Maxim Kim)
Update terminal Visual
1. Use `ctermbg=Grey ctermfg=Black` for both dark and light
This uniforms Visual highlighting between default dark and light colors
And should work for vim usually detecting light background for terminals
with black/dark background colors.
Previously used `ctermfg=White` leaks `cterm=bold` if available colors
are less than 16.
2. Use `term=reverse cterm=reverse ctermbg=NONE ctermfg=NONE`
for terminals reporting less than 8 colors available
If the terminal has less than 8 colors, grey just doesn't work right
closes: #13940
Signed-off-by: Maxim Kim <habamax@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
D. Ben Knoble [Wed, 31 Jan 2024 19:53:55 +0000 (14:53 -0500)]
runtime(racket): add missing space to b:undo_indent var (#13945)
This copies commit 2a4862a (fixup! indent: only reset some options when
has vim9, 2024-01-31) from https://github.com/benknoble/vim-racket and
fixes 26b0176a9 (runtime(racket): undo some indent options only when
vim9script is available (#13935), 2024-01-30).
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0061: UX of visual highlighting can be improved
Problem: UX of visual highlighting can be improved
Solution: Improve readibility of visual highlighting,
by setting better foreground and background
colors
The default visual highlighting currently is nice in that it overlays
the actual syntax highlighting by using a separate distinct background
color.
However, this can cause hard to read text, because the contrast
between the actual syntax element and the background color is way too
low. That is an issue, that has been bothering colorschemes authors for
quite some time so much, that they are defining the Visual highlighting
group to use a separate foreground and background color, so that the
syntax highlighting vanishes, but the text remains readable (ref:
vim/colorschemes#250)
So this is an attempt to perform the same fix for the default Visual
highlighting and just use a default foreground and background color
instead of using reverse.
I also removed the hard-coded changes to the Visual highlighting in
init_highlight. It's not quite clear to me, why those were there and not
added directly to the highlighting_init_<dark|light> struct.
zeertzjq [Sun, 28 Jan 2024 18:03:00 +0000 (19:03 +0100)]
patch 9.1.0060: Recorded register cannot be translated using keytrans()
Problem: Recorded register cannot be translated using keytrans() when
it involves character search (iddqd505)
Solution: Record a K_IGNORE instead of a K_NOP (zeertzjq)
related: #13916
closes: #13925
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Casey Tucker [Thu, 25 Jan 2024 21:44:00 +0000 (22:44 +0100)]
patch 9.1.0058: Cannot map Super Keys in GTK UI
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.
patch 9.1.0057: MS-Windows: Key event test still fails
Problem: MS-Windows: Key event test still fails
Solution: Skip testing CTRL-C, since it causes an Interrupt
which causes a test failure (after 9.1.0053)
VanaIgr [Thu, 25 Jan 2024 20:50:41 +0000 (21:50 +0100)]
patch 9.1.0056: wrong number of trailing spaces inserted after blockwise put
Problem: Incorrect number of trailing spaces inserted for multibyte
characters when pasting a blockwise register in blockwise visual
mode (VanaIgr)
Solution: Skip over trailing UTF-8 bytes when computing the number of trailing
spaces (VanaIgr)
When pasting in blockwise visual mode, and the register type is <CTRL-V>, Vim
aligns the text after the replaced area by inserting spaces after pasted
lines that are shorter than the longest line. When a shorter line contains
multibyte characters, each trailing UTF-8 byte's width is counted in addition
to the width of the character itself. Each trailing byte counts as being 4
cells wide (since it would be displayed as <xx>).
closes: #13909
Signed-off-by: VanaIgr <vanaigranov@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
kawaii-Code [Thu, 25 Jan 2024 20:40:05 +0000 (21:40 +0100)]
patch 9.1.0055: formatting long lines is slow
Problem: formatting long lines is slow
(kawaii-Code)
Solution: optimize gq (internal_format) for long
lines (kawaii-Code)
Implemented two workarounds that significantly reduce
the amount of pointless calls. Ideally the algorithm
would be rewritten not to be n^2, but it's too complicated
with too many corner cases.
closes: #13914
Signed-off-by: kawaii-Code <nia.personal.0@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
K.Takata [Wed, 24 Jan 2024 19:10:19 +0000 (04:10 +0900)]
runtime(netrw): Don't change global options (#13910)
Originally reported at: https://github.com/vim-jp/issues/issues/1428
'isk' was unintentionally changed by netrw, regression
introduced in Commit: 71badf9547e8f89571b9a095183671cbb333d528
Signed-off-by: Ken Takata <kentkt@csc.jp> Signed-off-by: Christian Brabandt <cb@256bit.org>
Anton Sharonov [Tue, 23 Jan 2024 22:19:02 +0000 (23:19 +0100)]
patch 9.1.0050: Win32 Keyboard handling is sub-optimal
Problem: Win32 Keyboard handling is sub-optimal and has
many issues with international keyboards
(risa2000) (after v8.2.4807)
Solution: soft-rollback the change, allow the user to select
a suitable key-translation strategy
(Anton Sharonov)
Read about the details in the help:
:h w32-experimental-keycode-trans-strategy
fixes: #10615
fixes: #12595
closes: #12752
Signed-off-by: Anton Sharonov <anton.sharonov@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Sean Dewar [Wed, 16 Aug 2023 16:15:05 +0000 (17:15 +0100)]
patch 9.1.0049: Make "[Command Line]" a special buffer name
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)
NOTE: This is technically a breaking change... maybe this needs a different
solution? (Or maybe this issue can be ignored...)
A GitHub search reveals some plugins expect the old behaviour. However, many of
those plugins also do not seem to account for the string being translated, so
they are subtly broken anyway (not withstanding the fact that you can call any
old buffer "[Command Line]" too...)
closes: #12819
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Sean Dewar [Wed, 16 Aug 2023 15:17:31 +0000 (16:17 +0100)]
patch 9.1.0048: Abort opening cmdwin if autocmds screw things up
Problem: Autocmds triggered from opening the cmdwin (in win_split and
do_ecmd) can cause issues such as E199, as the current checks
are insufficient.
Solution: Commands executed from the cmdwin apply to the old curwin/buf,
so they should be kept in a "suspended" state; abort if
they've changed. Also abort if cmdwin/buf was tampered with,
and check that curwin is correct. Try to clean up the cmdwin
buffer (only if hidden and non-current to simplify things; the
same approach is used when closing cmdwin normally), and add a
beep. (Sean Dewar)
It'd be nice to also check that curwin was *really* created by win_split, as
autocommands can change curwin before it returns (so it can't be assumed to be
that of the split); for now, this means that the cmdwin may not be the botwin in
that case, which is probably OK.
closes: #12819
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Sean Dewar [Wed, 16 Aug 2023 13:17:36 +0000 (14:17 +0100)]
patch 9.1.0047: issues with temp curwin/buf while cmdwin is open
Problem: Things that temporarily change/restore curwin/buf (e.g:
win_execute, some autocmds) may break assumptions that
curwin/buf is the cmdwin when "cmdwin_type != 0", causing
issues.
Solution: Expose the cmdwin's real win/buf and check that instead. Also
try to ensure these variables are NULL if "cmdwin_type == 0",
allowing them to be used directly in most cases without
checking cmdwin_type. (Sean Dewar)
Alternatively, we could ban win_execute in the cmdwin and audit all places that
temporarily change/restore curwin/buf, but I didn't notice any problems arising
from allowing this (standard cmdwin restrictions still apply, so things that may
actually break the cmdwin are still forbidden).
closes: #12819
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0045: --remote-* does not ignore `wilidignore`
Problem: --remote-silent applies the wildignore option
to each argument, which may result in "E479: No match"
(hebaronson)
Solution: temporarily reset 'wildignore' setting when building
the :drop command
Johnothan King [Mon, 22 Jan 2024 19:19:54 +0000 (11:19 -0800)]
runtime(sh): Add handling for ksh93 shared-state comsubs and mksh valsubs (#13884)
This commit adds support for ksh93 shared-state command
substitutions (syntax: ${ command; }) and mksh's value
substitutions (syntax: ${|command;}) in the sh syntax script.
Also add a syntax test for ksh subshares with dumps included
to make sure it doesn't regress.
fixes: #9514
Signed-off-by: Johnothan King <johnothanking@protonmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0043: ml_get: invalid lnum when :s replaces visual selection
Problem: ml_get: invalid lnum when :s replaces visual selection
(@ropery)
Solution: substitute may decrement the number of lines in a buffer,
so validate, that the bottom lines of the visual selection
stays within the max buffer line
projects / thirdparty / vim.git / log
