Works similar to ex <f-args>. It only splits the arguments if the
command has more than one posible argument. In cases were the command
can only have 1 argument opts.fargs = { opts.args }
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.
