| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: fuzzy string matching executed when not needed
Solution: when no leader is available, can skip fuzzy logic, so return
early (glepnir)
closes: vim/vim#14986
https://github.com/vim/vim/commit/1c296026627d7ac8195e803b4c2393c21ae659b4
Co-authored-by: glepnir <glephunter@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: fuzzy_match_str_with_pos() does unnecessary list operations.
Solution: Use fuzzy_match() directly (zeertzjq).
closes: vim/vim#14987
https://github.com/vim/vim/commit/2f95ca9fcef8495d60e298ac2cd6d702b90bfb18
N/A patch:
vim-patch:9.1.0478: potential deref of NULL pointer in fuzzy_match_str_with_pos
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Cannot see matched text in popup menu
Solution: Introduce 2 new highlighting groups: PmenuMatch and
PmenuMatchSel (glepnir)
closes: vim/vim#14694
https://github.com/vim/vim/commit/40c1c3317d92f8c2adadf744fab72e4458e2a9fa
Co-authored-by: glepnir <glephunter@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Problem: Sorting of completeopt+=fuzzy is not stable.
Solution: Compare original indexes when scores are the same.
(zeertzjq)
closes: vim/vim#14988
https://github.com/vim/vim/commit/8e56747fd26b3b040b6fcbfb6be41b7d5922c6b5
|
|\
| |
| | |
refactor(shada): use msgpack_sbuffer less
|
| |
| |
| |
| |
| |
| |
| | |
Work towards getting rid of libmsgpack depedency eventually.
msgpack_sbuffer is just a string buffer, we can use our own
String type.
|
| |
| |
| |
| |
| | |
revert: "refactor: use S_LEN(s) instead of s, n (#29219)"
This reverts commit c37695a5d5f2e8914fff86f3581bed70b4c85d3c.
|
| |
| |
| |
| |
| |
| |
| |
| | |
virtcol() (vim/vim#14981)
These are different from line() and getpos().
https://github.com/vim/vim/commit/d353d2782032b91498601afefee4256592f48074
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move the main description to getpos() and link to that from the other
functions.
closes: vim/vim#14970
https://github.com/vim/vim/commit/02f3ebacfbfa1f892347d7532278f24620e68300
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The ui_rgb_attached function determines if any UI is attached which
supports RGB (truecolor). We determine if the TUI supports RGB via the
'termguicolors' option which is checked at the beginning of this
function. If the TUI does not support RGB ('termguicolors' is unset), we
check to see if any _other_ UI is attached which supports RGB.
Normally, the TUI's "rgb" flag and the 'termguicolors' option are the
same. However, they may differ during startup when the "rgb" flag is set
by tui/tui.c to indicate to the core that the terminal emulator supports
truecolor. The 'termguicolors' option is not actually set until
_defaults.lua runs.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
These highlight groups are used for the statusline in :terminal windows.
By default they link to StatusLine and StatusLineNC (respectively), so
there is no visual difference unless a colorscheme defines these groups
separately.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
line() (#29296)
Problem: the previous documentation falsely states that "v" always
refers to the start of a visual area. In fact, the reference of "v" and
"." complement each other. If the cursor is at the start of
a (characterwise) visual area, then "v" refers to the end of the area.
Solution: be more verbose and explicit about the connection between "."
and "v" and also refer to |v_o| which many vim users will be familiar
with for visual areas.
https://github.com/vim/vim/commit/210b39c2d686d875e2464ca1f42131453dc6bd41
Co-authored-by: Peter Aronoff <peter@aronoff.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(#29117)
When libvterm receives the OSC 52 escape sequence it ignores it because
Nvim does not set any selection callbacks. Install selection callbacks
that forward to the clipboard provider, so that setting the clipboard
with OSC 52 in the embedded terminal writes to the system clipboard
using the configured clipboard provider.
|
|\ \
| | |
| | | |
refactor(memory): use builtin strcat() instead of STRCAT()
|
| |/
| |
| |
| |
| |
| |
| |
| | |
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: Some vim.fn have no type annotations.
Solution: Add type annotations.
|
|/ |
|
|
|
|
|
|
|
|
| |
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#14925
https://github.com/vim/vim/commit/aa925eeb97bd294d4a5253a3194949a37cbc8365
|
|
|
|
| |
DynamicBuffer at home: KVÄCK
|
|\
| |
| | |
refactor(io): make rstream use a linear buffer
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
| |
Copies characters in-places instead. Related #27827
|
|
|
|
| |
ref https://github.com/neovim/neovim/pull/28432
ref https://github.com/neovim/neovim/issues/28469
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Co-authored-by: Danymat <d.danymat@gmail.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Jakub Okoński <jakub@okonski.org>
Co-authored-by: John L. Villalovos <john@sodarock.com>
Co-authored-by: Maria José Solano <majosolano99@gmail.com>
Co-authored-by: Michaili K <git@michaili.dev>
Co-authored-by: TheLeoP <eugenio2305@hotmail.com>
Co-authored-by: Tobias Schmitz <tobiasschmitz2001@gmail.com>
Co-authored-by: W20MC <157727813+W20MC@users.noreply.github.com>
Co-authored-by: Will Hopkins <willothyh@gmail.com>
Co-authored-by: Yifan Hu <141280278+b0ae989c@users.noreply.github.com>
Co-authored-by: glepnir <glephunter@gmail.com>
Co-authored-by: prljav <74116121+prljav@users.noreply.github.com>
|
|
|
|
|
|
| |
fixes #29186 (likely)
fixup for #29093 064483a2b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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#5487
closes: vim/vim#14922
https://github.com/vim/vim/commit/529b9ad62a0e843ee56ef609aef7e51b7dc8a4c8
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: typos in some comments
(after v9.1.0466)
Solution: fix comments
(zeertzjq)
closes: vim/vim#14919
https://github.com/vim/vim/commit/551d8c372e49ed630fd95c6422a0ee62d00902c5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Missing comments for fuzzy completion (after 9.1.0463)
Solution: Add more comments, adjust indentation slightly
(glepnir)
closes: vim/vim#14910
https://github.com/vim/vim/commit/dca57fb54200530a0874c90fab799a689c00c597
Co-authored-by: glepnir <glephunter@gmail.com>
|
|
|
|
|
|
|
|
| |
related: vim/vim#14912
https://github.com/vim/vim/commit/2a2c4fffd7e04f74b316209404767f128684a9e1
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: no fuzzy-matching support for insert-completion
Solution: enable insert-mode completion with fuzzy-matching
using :set completopt+=fuzzy (glepnir).
closes: vim/vim#14878
https://github.com/vim/vim/commit/a218cc6cdabae1113647b817c4eefc2b60a6902f
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#14843
https://github.com/vim/vim/commit/0a0830624a260660c7fa692ecb7e6e5de09114ba
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#14890
https://github.com/vim/vim/commit/f51ff96532ab8f97f779b44d17dccdda9d8ce566
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.
https://github.com/vim/vim/commit/7737ce519b9cba8ef135154d76b69f715b1a0b4d
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
|\
| |
| | |
refactor(input): don't use a ring for input
|
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Corrupted text properties when expanding spaces.
Solution: Reallocate the line. (Nobuhiro Takasaki, closes vim/vim#5457)
https://github.com/vim/vim/commit/ac15fd8c6761763c8feedef1a2fbd8309f0a823c
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Text properties wrong when tabs and spaces are exchanged.
Solution: Take text properties into account. (Nobuhiro Takasaki,
closes vim/vim#5427)
https://github.com/vim/vim/commit/5cb0b93d52fa5c12ca50a18509947ee6459bb7a8
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|