Problem: can switch windows while textlocked via f_win_gotoid and
f_win_splitmove (which also allows switching in the cmdwin).
Solution: Check text_or_buf_locked in f_win_splitmove()
(Sean Dewar)
While at it, call text_or_buf_locked() in f_win_gotoid() instead of
testing for cmdwin_type() (which text_buf_locked() does and
in addition will also verify that the buffer is not locked).
closes: #14042
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: saving and restoring all frames to split-move is overkill now
that WinNewPre is not fired when split-moving.
Solution: defer the flattening of frames until win_split_ins begins
reorganising them, and attempt to restore the layout by
undoing our changes. (Sean Dewar)
This also means we no longer must allocate.
related: #14042
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: win_splitmove fires WinNewPre and possibly WinNew when moving
windows, even though no new windows are created.
Solution: don't fire WinNew and WinNewPre when inserting an existing
window, even if it isn't the current window. Improve the
accuracy of related documentation. (Sean Dewar)
Likewise, before this patch, WinClosed was not fired anyway (even for :wincmd
H/J/K/L, which also didn't fire WinNew, but did still fire WinNewPre), despite
documentation saying windows are "closed". Note that :wincmd T actually indeed
works by creating a new window (and closing the old one), unlike the others.
This also fixes issues where WinNewPre is fired when split-moving while curwin
doesn't yet have a frame or entry in the window list, causing many things to not
work (it's not considered valid at that point). This was guaranteed when using
:wincmd H/J/K/L.
Because WinNewPre is no longer fired when split-moving, this makes restoring the
previous window layout on failure easier, as we can be sure that frames are not
resized from WinNewPre autocommands if win_split_ins fails. This allows us to
use a different strategy in the following commit.
--
In my opinion, this leaves questions about the current usefulness of WinNewPre.
A motivation described in #10635 states how creating a new window can steal room
from other windows, and how WinNewPre will be useful for detecting that, but
this is also true when inserting an existing window, which now doesn't fire it.
Maybe the autocommand should be changed to have a better name?
There are also other issues I found with the current implementation of WinNewPre
that need addressing:
- it allows switching windows and tabpages, which can cause incorrect windows to
be split/moved, and big problems when switching tabpages.
- it fires before win_split_ins checks for room, before it makes any changes to
window sizes or before it considers allocating a new window. This should be
changed or documented.
I hope to address some of this stuff in a different PR, if possible.
related: #14038
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: win_split_ins has no check for E36 when moving an existing
window
Solution: check for room and fix the issues in f_win_splitmove()
(Sean Dewar)
win_split_ins has no check for E36 when moving an existing window,
allowing for layouts with many overlapping zero-sized windows to be
created (which may also cause drawing issues with tablines and such).
f_win_splitmove also has some bugs.
So check for room and fix the issues in f_win_splitmove. Handle failure
in the two relevant win_split_ins callers by restoring the original
layout, and factor the common logic into win_splitmove.
Don't check for room when opening an autocommand window, as it's a
temporary window that's rarely interacted with or drawn anyhow, and is
rather important for some autocommands.
Issues fixed in f_win_splitmove:
- Error if splitting is disallowed.
- Fix heap-use-after-frees if autocommands fired from switching to "targetwin"
close "wp" or "oldwin".
- Fix splitting the wrong window if autocommands fired from switching to
"targetwin" switch to a different window.
- Ensure -1 is returned for all errors.
Also handle allocation failure a bit earlier in make_snapshot (callers,
except win_splitmove, don't really care if a snapshot can't be made, so
just ignore the return value).
Note: Test_smoothscroll_in_zero_width_window failed after these changes with
E36, as it was using the previous behaviour to create a zero-width window.
I've fixed the test such that it fails with UBSAN as expected when v9.0.1367 is
reverted (and simplified it too).
related: #14042
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Modula-2 files with a specified priority are not detected.
Solution: Match the priority syntax in module header lines when
performing heuristic content detection.
Disable the :defcompile debug line. This was accidentally left enabled
in commit 68a8947.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
With the arrival of Vim9 classes, the syntax must allow for
_new_ constructors; multiple constructor definitions are
supported for a class, provided distinct suffix-names are
used. Currently, the defined constructors match either
vimCommand or vimFunctionError (for any newBar).
For example:
------------------------------------------------------------
vim9script
class Foo
def new()
enddef
def newBar()
enddef
endclass
------------------------------------------------------------
Since every constructor is required to bear a lower-cased
_new_ prefix name, it should suffice to distinguish them
from functions, and so there are no new highlight or syntax
groups introduced.
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: h-east <h.east.727@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Using freed memory with full tag stack and user data
(Konstantin Khlebnikov)
Solution: Clear the user data pointer of the newest entry.
(zeertzjq, Konstantin Khlebnikov)
fixes: neovim/neovim#27498
closes: #14053
Co-authored-by: Konstantin Khlebnikov koct9i@gmail.com
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Konstantin Khlebnikov koct9i@gmail.com
Signed-off-by: Christian Brabandt <cb@256bit.org>
While at it, also do the unmap only if a specific key has been mapped.
There are some keys that are only selectively mapped and it would cause
an error if we are trying to unmap such a key (e.g. z when your
foldmethod is not manual).
fixes: #14040
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: duplicate code when cleaning undo stack
Solution: refactor undo cleanup into a single public function
related: #13928
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: When the quickfix buffer has been modified an autocommand
may invalidate the undo stack (kawarimidoll)
Solution: When clearing the quickfix buffer, also wipe the undo stack
fixes: #13905closes: #13928
Signed-off-by: Christian Brabandt <cb@256bit.org>
The '*.bats' file type is for Bash Automated Testing System (BATS)
scripts. BATS scripts are Bash with a special '@test' extension but they
otherwise work with Vim's bash filetype.
See https://github.com/bats-core/bats-corecloses: #14039
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The 'Config.in' file type is for Buildroot configuration files.
Buildroot Config.in files use the same Kconfig backend as the Linux
kernel's Kconfig files.
Buildroot also has other filename variants that follow "Config.in.*",
they are used to distinguish multiple Config.in files in the same
directory.
See https://buildroot.org/downloads/manual/manual.html#_literal_config_in_literal_filecloses: #14038
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
These were included with the initial release of the syntax file for Vim
5 and were probably intended to allow for syn-region start/skip/end
patterns with a '!' or '+' delimiter. However, these cases are
currently handled by the vimSynRegPat group.
The removed patterns never match anywhere in the distributed runtime
files and it is believed that this is generally true.
closes: #14035
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Add missing "Last Change:" line.
- The date on this line in vim.vim is updated by update_date.vim at
Make time. (I made a mistake in the file path)
- Remove unnecessary "b:loaded_syntax_vim_ex".
- Remove "Base File Date:" line in vim.vim.base
- Add Doug Kearns as Maintainer
closes: #14031
Signed-off-by: h-east <h.east.727@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: no support for dtso files
Solution: Add detection for *.dtso files as dts file type
(Markus Schneider-Pargmann)
*.dtso files are devicetree overlay files which have the same syntax as dts or dtsi files.
closes: #14026
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: CI: Fix MacOS-14 tests (after 9.1.0070)
Solution: Re-enable sound tests by granting Mic access,
disable Test_diff_screen because of buggy MacOS diff
(non GNU version), re-enable Test_term_gettitle()
(Yee Cheng Chin)
macos-14 runner was turned on in #13943, but it had to turn off a few
tests in order for CI to run. Re-enable them and fix the underlying
issues.
* `Test_diff_screen`: The test failure is due to a bug in Apple's diff
utility. Apple introduced a new diff tool based on FreeBSD in macOS 13
and it has buggy behaviors when using unified diff (`-U0`) and the
diff is on the first line of the file. Simply disable this test for
now if we detect Apple diff (instead of the old GNU diff). Can
re-enable this in the future if Apple fixes the issue.
* `Test_play_event` / `Test_play_silent`: GitHub Actions currently has
an issue with playing sound in CI in macos-14 runners. It for some
reason triggers a microphone permission dialog popup which blocks the
CI action (see https://github.com/actions/runner-images/issues/9330).
To fix this, add a temporary step in macos-14 to manually allow
microphone permissions in the runner.
* `Test_term_gettitle`: I could not reproduce the failure, so I just
turned it on and it seems to run just fine. Maybe it's a timing issue
and whatnot but either way that should be fixed when we can reproduce
the issue.
closes: #14032
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Visual highlight hard to read with 'termguicolors'
(Maxim Kim)
Solution: Set Visual GUI foreground to black (with background=light)
and lightgrey (with background=dark)
(Maxim Kim)
fixes: #14024closes: #14025
Signed-off-by: Maxim Kim <habamax@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Linking fails with -lto because of PERL_CFLAGS
(Zoltan Toth)
Solution: Filter out -flto argument from Perl CFLAGS.
fixes: #14012
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: 'breakindentopt' "min" works incorrectly with 'signcolumn'.
Solution: Use win_col_off() and win_col_off2().
(zeertzjq)
closes: #14014
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: settabvar() may change the last accessed tabpage.
Solution: Save and restore lastused_tabpage.
(zeertzjq)
closes: #14017
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: upper-case of ß should be U+1E9E (CAPITAL LETTER SHARP S)
(fenuks)
Solution: Make gU, ~ and g~ convert the U+00DF LATIN SMALL LETTER SHARP S (ß)
to U+1E9E LATIN CAPITAL LETTER SHARP S (ẞ), update tests
(glepnir)
This is part of Unicode 5.1.0 from April 2008, so should be fairly safe
to use now and since 2017 is part of the German standard orthography,
according to Wikipedia:
https://en.wikipedia.org/wiki/Capital_%E1%BA%9E#cite_note-auto-12
There is however one exception: UnicodeData.txt for U+00DF
LATIN SMALL LETTER SHARP S does NOT define U+1E9E LATIN CAPITAL LETTER
SHARP S as its upper case version. Therefore, toupper() won't be able
to convert from lower sharp s to upper case sharp s (the other way
around however works, since U+00DF is considered the lower case
character of U+1E9E and therefore tolower() works correctly for the
upper case version).
fixes: #5573closes: #14018
Signed-off-by: glepnir <glephunter@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: When undoing with 'spell', redrawWinline() is called after
changed_lines(), while later win_update() sets redraw type to
UPD_NOT_VALID, even though w_redraw_top and w_redraw_bot are
still valid.
Solution: Only set redraw type to UPD_NOT_VALID when inserting/deleting
lines after parts of window has pending redraw, i.e., when
changed_lines() is called after redrawWinline().
(zeertzjq)
closes: #14019
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Not able to use diff() with 'diffexpr'
(rickhowe, after v9.1.0096)
Solution: Use a default context length of 0, update diff() help text,
add a test for using diff() with 'diffexpr'
(Yegappan Lakshmanan)
closes: #14013
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The syntax highlighter is likely to encourage people to use the listed
commands.
But `use-embedded-filename` is a dangerous option that can cause GnuPG
to write arbitrary data to arbitrary files whenever GnuPG encounters
malicious data.
GnuPG upstream explicitly warns against using this option:
https://dev.gnupg.org/T4500https://dev.gnupg.org/T6972
However, since this is a valid option, we cannot just drop it from the
syntax script. Instead, let's mark it with the WarningMsg highlighting
to make it obvious, that this option is different (and should not be
used for security reasons).
closes: #13961
Co-authored-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: CompletionChanged not triggered when new leader added causing
no matching item in the completion menu
Solution: When completion is active but no items matched still trigger
CompletChanged event
(glepnir)
closes: #13982
Signed-off-by: glepnir <glephunter@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: 'breakindent' behaves inconsistently with 'list' and splits.
Solution: Use 'listchars' from the correct window and handle caching
properly. Move cheaper comparisons to the top.
(zeertzjq)
closes: #14008
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- allow comments after :highight commands
- match the bang in a :highlight[!] command
- highlight the bang in :map[!], :menu[!] and :unlet[!] with vimOper
like all other commands
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: diff() function uses 'diffexpr'
(rickhowe)
Solution: Make diff() always use internal diff(), add support for
unified diff context length, sort diff() options in help
(Yegappan Lakshmanan)
fixes: #13989closes: #14010
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: tests: test_restricted() fails
(after: v9.1.0091)
Solution: Add a space before the pipecmd and the actual Vim command to
run
Signed-off-by: Christian Brabandt <cb@256bit.org>
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.
BEFORE:
$ xxd -Ralways -c 256 /etc/passwd
Segmentation fault (core dumped)
AFTER:
$ ./xxd -Ralways -c 256 /etc/passwd
00000000: 726f 6f74 3a78 3a30 3a30 3a72 6f6f 743a 2f72 [...]
To solve this issue I had to increase the size of the buffer
considering for each byte of data 11 further characters for the
color escape sequence.
closes: #14003
Signed-off-by: Goffredo Baroncelli <kreijack@libero.it>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
Problem: Compiler warning for missing type in scroll_event()
(chdiza)
Solution: Declare display_type explicitly as integer
fixes: #14005
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
Problem: Assigning wrong colors when parsing terminal OSC response
Solution: Correctly assign Green and Blue from the terminal response
(Maxim Kim)
closes: #13981
Signed-off-by: Maxim Kim <habamax@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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.
closes: #13980
Signed-off-by: Christian Brabandt <cb@256bit.org>
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)
fixes: #13967closes: #13984
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
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>
