The latter was mostly relevant with the past char_u madness.
NOTE: STRCAT also functioned as a counterfeit "NOLINT" for clint
apparently. But NOLINT-ing every usecase is just the same as disabling
the check entirely.
Problem: Legacy :sign API still allows placing signs beyond the end of
the buffer. This is unaccounted for by the signcolumn tracking
logic and is disallowed in general for the extmark API which
implements it now.
Solution: Clamp legacy sign line number to the length of the buffer.
`nvim_get_option_value` throws a warning if both `scope` and `buf`
options are used at the same time. This is because using `buf` always
implies `scope` is local, and is therefore not needed. There's however
no need to error if `scope` is already set "local" as it's the correct
value.
Problem: Inconsistencies between functions for option flags.
Solution: Consistently use "unsigned int" as return type and rename
get_bkc_value() to get_bkc_flags() (zeertzjq).
closes: vim/vim#14925aa925eeb97
It's a function to perform operations in their own sealed context,
similar to pythons `with`. This helps ease operations where you need to
perform an operation in a specific context, and then restore the
context.
Marked as private for now as it's not ready for public use. The current
plan is to start using this internally so we can discover and fix any
problems. Once this is ready to be exposed it will be renamed to
`vim.with`.
Usage:
```lua
local ret = vim._with({context = val}, function()
return "hello"
end)
```
, where `context` is any combination of:
- `buf`
- `emsg_silent`
- `hide`
- `horizontal`
- `keepalt`
- `keepjumps`
- `keepmarks`
- `keeppatterns`
- `lockmarks`
- `noautocmd`
- `options`
- `sandbox`
- `silent`
- `unsilent`
- `win`
(except for `win` and `buf` which can't be used at the same time). This
list will most likely be expanded in the future.
Work on https://github.com/neovim/neovim/issues/19832.
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
If you like it you shouldn't put a ring on it.
This is what _every_ consumer of RStream used anyway, either by calling
rbuffer_reset, or rbuffer_consumed_compact (same as rbuffer_reset
without needing a scratch buffer), or by consuming everything in
each stream_read_cb call directly.
Problem: Cannot have buffer-local value for 'completeopt'
(Nick Jensen).
Solution: Make 'completeopt' global-local (zeertzjq).
Also for some reason test Test_ColonEight_MultiByte seems to be failing
sporadically now. Let's mark it as flaky.
fixes: vim/vim#5487closes: vim/vim#14922529b9ad62a
We currently check $COLORTERM in the TUI process to determine if the
terminal supports 24 bit color (truecolor). If $COLORTERM is "truecolor"
or "24bit" then we automatically assume that the terminal supports
truecolor, but if $COLORTERM is set to any other value we still query
the terminal.
The `rgb` flag of the UI struct is a boolean which only indicates
whether the UI supports truecolor, but does not have a 3rd state that we
can use to represent "we don't know if the UI supports truecolor". We
currently use `rgb=false` to represent this "we don't know" state, and
we use XTGETTCAP and DECRQSS queries to determine at runtime if the
terminal supports truecolor. However, if $COLORTERM is set to a value
besides "truecolor" or "24bit" (e.g. "256" or "16) that is a clear
indication that the terminal _does not_ support truecolor, so it is
incorrect to treat `rgb=false` as "we don't know" in that case.
Instead, in the TUI process we only check for the terminfo capabilities.
This must be done in the TUI process because we do not have access to
this information in the core Neovim process when `_defaults.lua` runs.
If the TUI cannot determine truecolor support from terminfo alone, we
set `rgb=false` to indicate "we don't know if the terminal supports
truecolor yet, keep checking". When we get to `_defaults.lua`, we can
then check $COLORTERM and only query the terminal if it is unset.
This means that users can explicitly opt out of truecolor determination
by setting `COLORTERM=256` (or similar) in their environment.
Problem: no fuzzy-matching support for insert-completion
Solution: enable insert-mode completion with fuzzy-matching
using :set completopt+=fuzzy (glepnir).
closes: vim/vim#14878a218cc6cda
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: Unsetting global variables earlier in #28578 to avoid
recursiveness, caused superfluous or even unlimited
showmode().
Solution: Partly revert #28578 so that the globals are unset at the end
of showmode(), and avoid recursiveness for ext UI by adding a
recursive function guard to each generated UI call that may
call a Lua callback.
Problem: no whitespace padding in commentstring option in ftplugins
Solution: Change default to include whitespace padding, update
existing filetype plugins with the new default value
(Riley Bruins)
closes: vim/vim#148430a0830624a
Co-authored-by: Riley Bruins <ribru17@hotmail.com>
Problem: too many strlen() calls in drawline.c
Solution: Refactor code to avoid strlen()
(John Marriott)
closes: vim/vim#14890f51ff96532
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: Coverity complains about division by zero
Solution: Check explicitly for sw_val being zero
Shouldn't happen, since tabstop value should always be larger than zero.
So just add this as a safety measure.
7737ce519b
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Text properties wrong when tabs and spaces are exchanged.
Solution: Take text properties into account. (Nobuhiro Takasaki,
closesvim/vim#5427)
5cb0b93d52
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Left shift is incorrect with vartabstop and shiftwidth=0
Solution: make tabstop_at() function aware of shift direction
(Gary Johnson)
The problem was that with 'vartabstop' set and 'shiftwidth' equal 0,
left shifts using << were shifting the line to the wrong column. The
tabstop to the right of the first character in the line was being used
as the shift amount instead of the tabstop to the left of that first
character.
The reason was that the tabstop_at() function always returned the value
of the tabstop to the right of the given column and was not accounting
for the direction of the shift.
The solution was to make tabstop_at() aware of the direction of the
shift and to choose the tabtop accordingly.
A test was added to check this behavior and make sure it doesn't
regress.
While at it, also fix a few indentation/alignment issues.
fixes: vim/vim#14864closes: vim/vim#1488788d4f255b7
Co-authored-by: Gary Johnson <garyjohn@spocom.com>
Problem: Numberwidth may depend on number of signs with text in the
buffer and is not handled correctly for extmark signs.
Solution: Move legacy sign code for changed numberwidth so that it is
handled properly for legacy and extmark signs alike.
Since paste data is handled via a separate channel, the data processed via `input_buffer` is typically just explicit keys as typed in by the user. Therefore it should be fine to use `memmove()` to always put the remaining data in front when refilling the buffer.
This is a structural refactor with no logical changes, yet. Done in
preparation for simplifying rstream/rbuffer which will require more
state inline in RStream.
The initial idea was to have RStream and WStream as sub-types
symetrically but that doesn't work, as sockets are both reading and
writing. Also there is very little write-specific state to start with,
so the benefit of a separate WStream struct is a lot smaller. Just
document what fields in `Stream` are write specific.
Problem: No test for escaping '<' with shellescape()
Solution: Add a test. Use memcpy() in code to make it easier to
understand. Fix a typo (zeertzjq).
closes: vim/vim#1487688c8c547d5
Problem: MS-Windows: Compiler warnings
Solution: Resolve size_t to int warnings
closes: vim/vim#14874
A couple of warnings in ex_docmd.c have been resolved by modifying their
function argument types, followed by some changes in various function
call sites. This also allowed removal of some casts to cope with
size_t/int conversion.
51024bbc1a
Co-authored-by: Mike Williams <mrmrdubya@gmail.com>
Using a ring buffer for buffered synchronous fileio is just unnecessary
complexity.
- when reading, we always consume the _entire_ buffer before getting
into syscalls. Thus we reset the buffer to its initial position before
when we actually read.
- when writing and buffer is full, we always flush the entire buffer
before starting to buffer again. So we can reset the buffer to its
initial state.
Also no static buffers are needed for writing and skipping. Needing an
extra copy for each write completely defeated the purpose of
a ring buffer (if there had been one)
`FileDescriptor` is already a wrapper around an fd and a buffer.
By allowing to just use the buffer without an fd, it can
already handle in-memory reads.
FileDescriptor is used to buffer togheter many small writes to fewer
syscalls. if the data to write already is in a single buffer, it is
perfectly fine to just use os_write directly (which will take care of
the reverse problem: splitting a too big write into many syscalls)
