Problem: using "C" and 've=all' set, doesn't include composing chars
when changing a line, keeps the composing chars for whatever
is typed afterwards.
Solution: Use mb_head_off() and mb_ptr2len() instead of mb_tail_off().
(zeertzjq)
closes: #14083
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: buffer-completion code too complicated and does not always
find all matches (irisjae)
Solution: do not try to anchor pattern to beginning of line or
directory-separator, always return all matches
Note: we are considering the non-fuzzy buffer-matching here.
Currently, the buffer-completion code makes 2 attempts to match a
pattern against the list of available patterns. First try is to match
the pattern and anchor it to either the beginning of the file name or
at a directory-separator (// or \\).
When a match is found, Vim returns the matching buffers and does not try
to find a match anywhere within a buffer name. So if you have opened two
buffers like /tmp/Foobar.c and /tmp/MyFoobar.c using `:b Foo` will only
complete to the first filename, but not the second (the same happens
with `getcompletion('Foo', 'buffer')`).
It may make sense, that completion priorities buffer names at directory
boundaries, but it inconsistent, may cause confusion why a certain
buffer name is not completed when typing `:b Foo<C-D>` which returns
only a single file name and then pressing Enter (to switch to that
buffer), Vim will error with 'E93: More than one match for Foo').
Similar things may happen when wiping the /tmp/Foobar.c pattern and
afterwards the completion starts completing other buffers.
So let's simplify the code and always match the pattern anywhere in the
buffer name, do not try to favor matches at directory boundaries. This
is also simplifies the code a bit, we do not need to run over the list
of buffers several times, but only twice.
fixes#13894closes: #14082
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: heap-use-after-free in win_splitmove if Enter/Leave
autocommands from win_split_ins immediately closes "wp".
Solution: check that "wp" is valid after win_split_ins.
(Sean Dewar)
closes: #14078
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: win_gotoid() checks for textlock and other things when switching
to a window that is already current (after v9.1.0119)
Solution: return early with success when attempting to switch to curwin
(Sean Dewar)
Other potential causes of E565 from win_gotoid after v9.1.0119 should be
correct. Plugins can consider using win_execute() instead if they wish to
temporarily switch windows during textlock.
fixes: #14073closes: #14074
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Internal error when passing mark in another buffer to
getregion().
Solution: Don't allow marks in another buffer (zeertzjq)
closes: #14076
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Internal error when passing mark in another buffer to getregion()
Problem: Virtual text with text_align 'right'/'below' wasn't being
used when a non-virtual text property overlaps with the end of
the line. This was because the non-virtual text property had a
higher priority, preventing the virtual text from being used.
Solution: Fix the sorting of text properties so virtual text properties
have a higher priority than non-virtual text properties.
(Dylan Thacker-Smith)
related: #14063
Signed-off-by: Dylan Thacker-Smith <dylan.ah.smith@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: infinite loop in win_update with 'smoothscroll' set when
window width is equal to textoff, or signed integer overflow
if smaller.
Solution: don't revalidate wp->w_skipcol in that case, as no buffer text
is being shown. (Sean Dewar)
Don't instead reset w_skipcol; that would lose the scroll position
within the line, which may be undesirable if the window is made wider
later.
Also include changes from the splitmove PR #14042 that I (in my infinite
Git wisdom) forgot to commit. This includes a change to
Test_window_split_no_room to ensure it doesn't fail for some screen
sizes.
Move Test_smoothscroll_in_zero_width_window to test_scroll_opt.vim, as
that file feels more appropriate.
closes: #14068
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: hard to get visual region using Vim script
Solution: Add getregion() Vim script function
(Shougo Matsushita, Jakub Łuczyński)
closes: #13998closes: #11579
Co-authored-by: =?UTF-8?q?Jakub=20=C5=81uczy=C5=84ski?= <doubleloop@o2.pl>
Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Signed-off-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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: 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>
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>
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>
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: '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: 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>
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>
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: 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: 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: Visual hl wrong when it ends before multibyte 'showbreak'.
(lacygoil)
Solution: Use vcol_sbr instead of adding n_extra.
(zeertzjq)
fixes: #11272closes: #13996
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
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>
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: #13745fixes: #13959closes: #13962
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: LineNrAbove and LineNrBelow background wrong on wrapped lines.
Solution: Update number column also for wrapped part of a line.
(zeertzjq)
closes: #13974
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: insert completion not correct when adding new leader
Solution: Reset compl_curr_match to compl_shown_match
(glepnir)
closes: #13957
Co-authored-by: glepnir <glephunter@gmail.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: #4241closes: #12321
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
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>
Problem: Segfault with CompleteChanged autocommand
(markonm )
Solution: Test match->cp_prev for being NULL before accessing it
closes: #13929
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No Wayland support
Solution: Add Wayland UI support
(lilydjwg)
closes: #9639
Signed-off-by: lilydjwg <lilydjwg@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: GTK code can be improved
Solution: Improve GTK code for initial Wayland support
(lilydjwg)
related: #9639
Signed-off-by: lilydjwg <lilydjwg@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Internal error when :luado/perldo/pydo etc delete lines
Solution: Test that the line is still valid line number
(zeertzjq)
closes: #13931
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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.
closes: #13663
related: vim/colorschemes#250
Signed-off-by: Christian Brabandt <cb@256bit.org>
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: #13916closes: #13925
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No event is triggered before creating a window.
(Sergey Vlasov)
Solution: Add the WinNewPre event (Sergey Vlasov)
fixes: #10635closes: #12761
Signed-off-by: Sergey Vlasov <sergey@vlasov.me>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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.
```vimrc
if has('gui_gtk')
nnoremap <D-z> u
nnoremap <D-S-Z> <C-r>
vnoremap <D-x> "+d
vnoremap <D-c> "+y
cnoremap <D-v> <C-R>+
inoremap <D-v> <C-o>"+gP
nnoremap <D-v> "+P
vnoremap <D-v> "-d"+P
nnoremap <D-s> :w<CR>
inoremap <D-s> <C-o>:w<CR>
nnoremap <D-w> :q<CR>
nnoremap <D-q> :qa<CR>
nnoremap <D-t> :tabe<CR>
nnoremap <D-S-T> :vs#<CR><C-w>T
nnoremap <D-a> ggVG
vnoremap <D-a> <ESC>ggVG
inoremap <D-a> <ESC>ggVG
nnoremap <D-f> /
nnoremap <D-g> n
nnoremap <D-S-G> N
vnoremap <D-x> "+x
endif
```
closes: #12698
Signed-off-by: Casey Tucker <dctucker@hotmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
