Looks like I did an oopsie; although API strings carry a size field, they should
still be usable as C-strings! (even though they may contain embedded NULs)
Problem: Dtrace files are recognized as filetype D.
Solution: Add a pattern for Dtrace files. (Teubel György, closesvim/vim#9841)
Add some more testing.
4d56b971cb
Previously, :hardcopy would only use terminal highlight colours, with a
fixed mapping table, despite internally supporting true colour. This
patch looks at the guifg colour first while coming up with the printing
highlight colours, then falls back to the terminal ones.
I have passed through the modec argument in this change because it was
there before, but it could be deleted and hardcoded to 'c' since nobody
sets it to anything else anywhere.
50250542 failed to consider that the maximum passed to buf_signcols
is window scoped whereas the signcols value is buffer scoped. This can
lead to a bug where the signcolumn becomes incorrect if:
- global signcolumn is set to auto:N
- signcolumn in a window is changed locally to auto:M where M > N
- the buffer has a line with M or greater signs.
Addresses: #12571
- Added the following installers through CMake files:
- Windows NSIS.
- Windows MSI.
- Windows zip.
- MacOs tarball.
- Linux tarball.
- Linux Deb package.
- Tweaked pipeline CPack commands to build using new CMakeLists.txt configuration file.
- Added icons and relevant packaging files.
- Updated notes.md to reflect new installation instructions.
This isn't meant to be the perfect solution, it's simply a first pass at using a
simple packaging system to build Windows installers. A Debian package has also
been added since it's very easy but other packages have been left out due to
limiting the scope. Hopefully we can build further upon this and improve it
over time with code signing, better icons and more user-friendly installation
graphics and so on.
nvim_buf_set_text does not handle negative row numbers correctly: for
example,
nvim_buf_set_text(0, -2, 0, -1, 20, {"Hello", "world"})
should replace the 2nd to last line in the buffer with "Hello" and the
first 20 characters of the last line with "world". Instead, it reports
"start_row out of bounds". This happens because when negative line
numbers are used, they are incremented by one additional number to make
the non-negative line numbers end-exclusive. However, the line numbers
for nvim_buf_set_text should be end-inclusive.
In #15181 we handled this for nvim_buf_get_text by adding a new
parameter to `normalize_index`. We can solve the problem with
nvim_buf_set_text by simply availing ourselves of this new argument.
This is a breaking change, but makes the semantics of negative line
numbers much clearer and more obvious (as well as matching
nvim_buf_get_text).
BREAKING CHANGE: Existing usages of nvim_buf_set_text that use negative
line numbers will be off-by-one.
Update runtime files
944697ae19
Doc changes:
Include remote_*() (even though +clientserver and remote.txt isn't ported yet)
Omit screenpos() (need v8.2.4389)
Other changes are N/A or cannot be directly applied
There are some places that mess with the window layout in preparation for moving
a window to a different split (win_split_ins called with new_wp != NULL).
This means the window layout can change slightly even if win_split_ins fails.
This is why it was still needed to restore the window layout in
aucmd_{prep,rest}buf even if we disallow win_split_ins from making aucmd_win
non-floating by moving it into a split.
We can just skip messing with the layout in such places if we're dealing with
the aucmd_win.
Nvim uses a floating window for the autocmd window, but in certain situations,
it can be made non-floating (`:wincmd J`), which can cause issues due to the
previous setup and cleanup logic for a non-floating aucmd_win being removed from
aucmd_prepbuf and aucmd_restbuf.
This can cause glitchiness and crashes due to the aucmd_win's frame being
invalid after closing its tabpage, for example.
Ensure aucmd_win cannot be made non-floating. The only place this happens is in
win_split_ins if new_wp != NULL.
nvim_buf_get_text is the mirror of nvim_buf_set_text. It differs from
nvim_buf_get_lines in that it allows retrieving only portions of lines.
While this can typically be done easily enough by API clients,
implementing this function provides symmetry between the get/set
text/lines APIs, and also provides a nice convenience that saves API
clients the work of having to slice the result of nvim_buf_get_lines
themselves.
Problem: getchar() may return modifiers if no character is available.
Solution: Do not process modifiers when there is no character. (closesvim/vim#9806)
ad6c45f625
The VS 2019 CMake generator no longer has different generator types for
different architectures. Now, the architecture is specified via CMake's
`-A` switch. However, this requires we also propagate
`${CMAKE_GENERATOR_PLATFORM}` to the bundled deps, so they build for the
same architecture as Nvim.
