Problem: noautocmd is confusing; despite its name, it doesn't block all
autocommands (instead it blocks only those related to setting the buffer), and
is commonly used by plugins to open windows while producing minimal
side-effects.
Solution: be consistent and block all autocommands when noautocmd is set.
This includes WinNew (again), plus autocommands from entering the window (if
enter is set) like WinEnter, WinLeave, TabEnter, .etc.
See the discussion at https://github.com/neovim/neovim/pull/14659#issuecomment-2040029517
for more information.
Remove win_set_buf's noautocmd argument, as it's no longer needed.
NOTE: pum_create_float_preview sets noautocmd for win_set_buf, but all its
callers already use block_autocmds.
Despite that, pum_create_float_preview doesn't actually properly handle
autocommands (it has no checks for whether those from win_enter or
nvim_create_buf free the window).
For now, ensure autocommands are blocked within it for correctness (in case it's
ever called outside of a block_autocmds context; the function seems to have been
refactored in #26739 anyway).
Problem: Wrong cursor position after using setcellwidths().
Solution: Invalidate cursor position in addition to redrawing.
(zeertzjq)
closes: vim/vim#1454505aacec6ab
Reorder functions in test_utf8.vim to match upstream.
Add more filters so that LuaJIT can parse headers on macOS 14.
The system headers use a style of enum introduced in C++11 (and allowed
as an extension in C by clang) of the form:
enum Name : Type {
The system headers also use bitfields in the mach_vm_range_recipe* types:
struct Foo { int bar : 32; }
Neither of these constructs can be parsed by LuaJIT, so filter the lines
out. Neither of these declarations are used by neovim's unittests.
There is a (now closed) issue about bitfields for LuaJIT:
https://github.com/LuaJIT/LuaJIT/issues/951Fixes#26145.
runtime(vim): Update base-syntax, add legacy header folding
Allow for syntax-based folding of Vim9 script legacy header regions.
This is enabled with the "H" flag of the g:vimsyn_folding config variable.
closes: vim/vim#14530ce06493aeb
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: Crash when using heredoc with comment in command block.
Solution: Handle a newline more like the end of the line, fix coverity
warning (zeertzjq).
closes: vim/vim#145351f5175d9af
runtime(i3config): Line continuation is not detected for 'set' command (vim/vim#14531)
Problem: Valid i3config syntax is highlighted as error.
Solution: Skip over line-breaks correctly.
5392970921
Co-authored-by: julio-b <julio.bacel@gmail.com>
runtime(go): fix highlighting import string followed by some comment (vim/vim#14538)
122d068585
Co-authored-by: Linda_pp <rhysd@users.noreply.github.com>
Problem:
The `:terminal` auto-close logic does not support `&shell` that has
arguments, e.g., `/bin/bash -O globstar`.
Solution:
Join `argv` and match `&shell`. This is not perfect since `&shell` may
contain irregular spaces and quotes, but it seems to be good enough.
If the filename passed to vim_FullName() is a relative directory, and
does not exist, it is appended to the current working directory. Since
the return value of append_path() was ignored, and if the buffer length
was too small to fit getcwd() + dirname(filename), it would still try to
append the basename(filename).
This was manifesting as a failure in test/unit/path_spec.lua in:
itp('fails and uses filename if given filename contains non-existing directory', ..
This failure occurs when running the tests from directory with a short
path such as: /work/src/nv
test/unit/path_spec.lua:420: Expected objects to be the same.
Passed in:
(string) '/work/src/nv/test.file'
Expected:
(string) 'non_existing_dir/test.file'
This return value for the second call to append_path() to append
basename(filename) was checked, and this is where it would fail for
normal / longer getcwd()s.
This reverts commit 4382d2ed56.
The story for this feature was left in an incomplete state. It was never
the intention to unilaterally fold all information, only the ones that
did not contain relevant information. This feature does more harm than
good in its incomplete state.
Problem: POSIX function name in exarg struct causes issues
on OpenVMS
Solution: Rename getline member in exarg struct to ea_getline,
remove isinf() workaround for VMS
There are compilers that do not treat well POSIX functions - like
getline - usage in the structs.
Older VMS compilers could digest this... but the newer OpenVMS compilers
( like VSI C x86-64 X7.4-843 (GEM 50XB9) ) cannot deal with these
structs. This could be limited to getline() that is defined via
getdelim() and might not affect all POSIX functions in general - but
avoiding POSIX function names usage in the structs is a "safe side"
practice without compromising the functionality or the code readability.
The previous OpenVMS X86 port used a workaround limiting the compiler
capabilities using __CRTL_VER_OVERRIDE=80400000
In order to make the OpenVMS port future proof, this pull request
proposes a possible solution.
closes: vim/vim#137046fdb628082
Co-authored-by: Zoltan Arpadffy <zoltan.arpadffy@gmail.com>
LuaJIT does not handle -0.0 correctly in 'dual number mode' (which is
the default, and only supported mode for LuaJIT arm64). If LuaJIT is
forced to use 'dual number mode' on X64 (where the default is single),
this test will fail in the same manner.
Fix this by using tonumber("-0.0") instead of a -0.0 literal.
See: https://github.com/LuaJIT/LuaJIT/issues/858
Problem: filetype: some history files are not recognized
Solution: Add some history patterns to filetype.vim
(Wu, Zhenyu)
closes: vim/vim#14513da70feabea
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: xilinx files are not recognized
Solution: Add a few xilinx specific file patterns,
inspect lpr files for being xml/pascal
(Wu, Zhenyu)
closes: vim/vim#14454614691ceef
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: some TeX files are not recognized
Solution: Add more patterns for TeX files and inspect
a few more files for being TeX files
(Wu, Zhenyu)
closes: vim/vim#1445661ee833a50
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
