Problem:
There is a lot of overlap between terminal and prompt buffer, but no
easy way to limit the number of lines kept above the prompt to prevent
performance and other issues. This is desirable for both example
use cases in current documentation, chat UI and repl/shell plugins.
Solution:
Use existing 'scrollback' option to limit prompt-buffer lines
as well.
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem:
When using prompt_appendbuf with multi-element list,
the first item is concated and rest replace the prompt instead of
inserting the lines before the prompt.
Solution:
Concat first element with replace_buf and insert the rest of the list
with set_buffer_lines.
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
Problem: evalvars_init() copies each vimvar's name into di_key at
startup and runtime-checks that the name fits in
DICTITEM16_KEY_LEN, even though all names are known at
compile time.
Solution: Embed the name in di_key via the VV_NAME macro so the
initialization happens at compile time. Drop the
runtime length check and the STRCPY loop (John Marriott).
closes: vim/vim#201851b65cfbac5
Co-authored-by: John Marriott <basilisk@internode.on.net>
CI currently uses clang-tidy 20, but this affects local builds
and CI is going to be upgraded sooner or later.
Some remaining systematic issues:
- clang-tidy warns agains any atoi() or atol() usage (because of no
error handling)
- functions which takes (char *fmt, char *only_string_arg) and expect
fmt to contain exactly one "%s" usage.
- error: initializing non-local variable with non-const expression depending on
uninitialized non-local variable (cppcoreguidelines-interfaces-global-init)
This is a much worse problem in C++ (hence C++ core guidelines) where
initialization is intermingled with arbitrary code execution. I
"think" in plain C, the linker will either resolve all these
deterministically or barf an error. But with some restructuring
we could make all static initialization actually static..
Problem: some functions can be run from the sandbox
Solution: Block them, so they are not accessible from a modeline
(q1uf3ng)
closes: vim/vim#19975fcc4276db3
Co-authored-by: q1uf3ng <q1uf3ng@protone.me>
Problem:
When showing the :connect menu, it is useful to know which servers
are most-recently active. But we don't have a good way to detect that.
Solution:
- Introduce `v:useractive`.
- Include this timestamp in `serverlist({info=true})`.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com>
Problem:
`gx` relies on `exepath` to get the fullpath of `cmd.exe`,
and that path must use `\`; otherwise, luv's spawn will fail.
Solution:
Revert `slash_adjust` in `exepath`, so that it still respects 'shellslash'
Problem:
followup to 55ceb314ca#39478
`:oldfiles` and swapfile `:recover` do not delegate to `vim.ui.select`.
Solution:
- Delegate to `vim.ui.select`.
- Fix a long-standing `recover_names` bug where `concat_fnames(dir_name,
files[i], true)` produced malformed `<dir>//<dir>/<file>` paths (also
fixes `swapfilelist()`).
Problem:
On Windows, path separators may become inconsistent for various reasons,
which makes normalization quite painful.
Solution:
Normalize paths to `/` at the entry boundaries and always use it
internally, converting back only in rare cases where `\` is really
needed (e.g. cmd.exe/bat scripts?).
This is the first commit in a series of incremental steps.
Note:
* some funcs won't respect shellslash. e.g. `expand/fnamemodify`
* some funcs still respect shellslash, but will be updated in a follow
PR. e.g. `ex_pwd/f_chdir/f_getcwd`
* uv's built-in funcs always return `\`. e.g. `uv.cwd/uv.exepath`
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
- The `ZR` feature makes it more obvious that we need some sort of flag so that
an `ExitPre` / `QuitPre` / `VimLeave` handler can handle restarts differently
than a normal exit. For example, it's common that users want `:mksession` on
restart, but perhaps not on a normal exit.
- Nvim has no way to report its "uptime".
Solution:
- Introduce `v:starttime`
- Introduce `v:exitreason`
Problem: too many strlen() calls when adding strings to dicts
Solution: Refactor code to use string_T, use dict_add_string_len()
instead of dict_add_string() (John Marriott)
Additionally:
- In textprop.c, in function prop_fill_dict() use a string_T to store
local variable text_align.
- In popupwin.c, use a string_T to store struct member pp_name in struct
poppos_entry_T.
- In mark.c, refactor function add_mark() to pass in the length of
argument mname.
- In insexpand.c:
->Use a string_T to store the elements of static array
ctrl_x_mode_names.
->Refactor function trigger_complete_done_event():
->->change type of argument char_u *word to string_T *word.
->->make one access of array ctrl_x_mode_names instead of two.
->Refactor function ins_compl_mode() to accept a string_T to return the
resulting string.
- In fileio.c:
->Refactor function getftypewfd() to accept a string_T to return the
resulting string.
->In function create_readdirex_item() use a string_T to store local
variable q.
- In cmdexpand.c, store global cmdline_orig as a string_T.
- In autocmd.c, in function f_autocmd_get() use a string_T to store local
variables event_name and group_name. Measure their lengths once when
they are assigned so they are not remeasured on each call to
dict_add_string() in the subsequent for loop.
- In channel.c, in function channel_part_info() drop local variable status
and use s instead. Make s a string_T.
closes: vim/vim#19999c13232699d
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: Using execute() to define a lambda doesn't work. (Ernie Rael)
Solution: Put the getline function in evalarg. (closesvim/vim#10375)
a7583c42cd
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: return value of winrestcmd() cannot be executed.
Solution: Put colons before each range. (closesvim/vim#7571)
285b15fce1
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem:
Too much boilerplate needed to use Lua to impl an excmd or f_xx
function.
Solution:
- Add `nlua_call_vimfn` which takes the args typval, executes
Lua, and returns a typval.
- refactor(excmd): lua impl for :log, :lsp
Problem:
- Builtin "Vimscript" functions (f_xx) are mostly implemented in C.
Partly that's because there is some boilerplate required to call out
to Lua.
- Calls to `vim.fn.foo()` always marshall over the Lua <=> Vimscript
("typval") bridge, even if `fn.foo()` is implemented entirely in Lua:
```
Lua => typval => Object => Lua => Object => typval => Lua.
```
Solution:
Functions declared in eval.lua with `func_lua` are implemented in
entirely in Lua (`_core/vimfn.lua`).
- `gen_eval.lua` wires `func_lua` entries to `lua_wrapper`, which handles
the typval conversion for Vimscript callers (slow path).
- `nlua_call()` detects `func_lua` functions and calls the Lua
implementation directly. This eliminates all conversion overhead for
Lua callers (fast path).
- Validate at build-time that `func`, `func_float`, and `func_lua` are
mutually exclusive.
- Migrate `hostname()` as a toy example, to show the idea.
Problem: repeat_string() can be improved
Solution: Replace the for() loop by an exponential growing while loop
(Yasuhiro Matsumoto)
closes: vim/vim#19977bfa46a52f6
Cherry-pick f_repeat() refactor from patch 9.1.1232.
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Problem: 'linebreak' may lead to wrong Visual block highlighting when
end char occupies multiple cells (after 7.4.467).
Solution: Exclude 'linebreak' from the ending column instead of setting
'virtualedit' temporarily (zeertzjq).
fixes: vim/vim#19898closes: vim/vim#1990023be1889d1
Problem:
The "restart" event has some problems:
- all UI clients must implement a somewhat complex set of setups
- UI must be on the same machine as the server
- only works for the "current" UI
- race/edge case: If the user config has errors / waiting for input, are
all UIs able to attach while Nvim is waiting for input?
Solution:
- Perform the restart on the server, not the client.
- Pass listen address (instead of CLI args) in the UI event.
- Simplifies UI logic: they only need to attach to new address.
- Opens the door for more enhancements in the future, such as allowing
all UIs to reattach instead of only the "current" UI.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: unnecessary restrictions for defining dictionary function
names
Solution: Allow defining dict function with bracket key that is not a
valid identifier (thinca)
In Vim script, "function obj.func()" and "function obj['func']()" both
define a dictionary function. However, the bracket form required the
key to match function naming rules (eval_isnamec), so
"function obj['foo-bar']()" failed with E475.
Assigning and calling already work: "let obj['foo-bar'] = obj.func"
and "call obj['foo-bar']()" are valid. Only the definition was
incorrectly restricted.
Skip the identifier check when the name comes from fd_newkey (i.e. the
key was given in bracket notation). Dictionary keys may be any string.
Supported by AI
closes: vim/vim#19833f89662722d
Co-authored-by: thinca <thinca@gmail.com>
Problem:
Currently, we recommend always inserting text above prompt-line in
prompt-buffer. This can be done using the `:` mark. However, although
we recommend it this way it can sometimes get confusing how to do it
best.
Solution:
Provide an api to append text to prompt buffer. This is a common
use-case for things using prompt-buffer.
Problem:
The 'android' and 'termux' feature flags have been shipped in the
downstream neovim/neovim-nightly package for 5+ years but were never
properly documented in the downstream patch.
Solution:
Upstream the 'android' and 'termux' feature flags into Neovim as
decoupled feature flags, this enables the 'android' feature in
particular to be available independently of the 'termux' feature
for builds of Neovim against the Android NDK, but not including
the Termux NDK patchset.
Co-authored-by: Lethal Lisa <43791059+lethal-lisa@users.noreply.github.com>
Co-authored-by: shadmansaleh <13149513+shadmansaleh@users.noreply.github.com>
Problem: concatenating strings is slow
Solution: Use grow_string_tv() to grow the existing string buffer in
place when possible (Yasuhiro Matsumoto).
closes: vim/vim#1964216d421a4d9
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Problem: blob: concatenation can be improved
Solution: Use ga_grow() to allocate space once and mch_memmove() to copy
the blob data as a single block and fall back to the previous
byte by byte append (Yasuhiro Matsumoto).
closes: vim/vim#1964567deae3b77
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Problem: String handling can be improved
Solution: Pass string length where it is known to avoid strlen() calls,
do a few minor refactors (John Marriott).
This commit changes some calls to function `set_vim_var_string()` to pass
the string length where it is known or can be easily calculated.
In addition:
In `evalvars.c`:
* In function `set_reg_var()` turn variable `regname` into a C string
because that is how it used.
* Small cosmetics.
In `option.c`:
* Slightly refactor function `apply_optionset_autocmd()` to move some
variables closer to where they are used.
In `getchar.c`:
* Slightly refactor function `do_key_input_pre()`:
-> change call to `dict_add_string()` to `dict_add_string_len()` and
pass it the length of `buf`.
-> only call `get_vim_var_string()` once.
In `message.c`:
* Use a `string_T` to store local variable `p`.
In `normal.c`:
* Move some variables closer to where they are used.
closes: vim/vim#19618727f6e2686
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: The has() function is slow because it performs a linear scan
of the feature list for every call.
Solution: Move common runtime checks and the patch-version parser to the
beginning of the f_has() function (Yasuhiro Matsumoto).
closes: vim/vim#19550327e0e34c9
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Problem: Inefficient use of list_append_string()
Solution: Pass string length to list_append_string() where it is known
(John Marriott).
closes: vim/vim#19491455d62e38a
N/A patches:
vim-patch:9.2.0063: memory leak in type_name_list_or_dict()
vim-patch:9.2.0065: memory leak in invoke_sync_listeners()
vim-patch:9.2.0066: memory leak in build_drop_cmd()
vim-patch:9.2.0067: memory leak in dict_extend_func()
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem:
- `:args` and `argv()` can change after startup.
- `v:arg` includes options/commands, not just files.
- Plugins (e.g. Oil) may rewrite directory args.
Solution:
- New read-only var `v:argf`: snapshot of file/dir args at startup.
- Unaffected by `:args` or plugins.
- Unlike `v:argv`, excludes options/commands.
- Paths are resolved to absolute paths when possible
Example:
nvim file1.txt dir1 file2.txt
:echo v:argf
" ['/home/user/project/file1.txt', '/home/user/project/dir1', '/home/user/project/file2.txt']
Problem: Inefficient use of ga_concat()
Solution: Use ga_concat_len() when the length is already known to avoid
use of strlen() (John Marriott).
closes: vim/vim#19422ed202035b1
Co-authored-by: John Marriott <basilisk@internode.on.net>
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem:
TUI does not support several standard SGR text attributes:
- dim/faint (SGR 2)
- blink (SGR 5)
- conceal (SGR 8)
- overline (SGR 53)
This means that when a program running in the embedded terminal emits
one of these escape codes, we drop it and don't surface it to the
outer terminal.
Solution:
- Add support for those attributes.
- Also add corresponding flags to `nvim_set_hl` opts, so users can set
these attributes in highlight groups.
- refactor(highlight): widen `HlAttrFlags` from `int16_t` to `int32_t`
Widen the `rgb_ae_attr` and `cterm_ae_attr` fields in HlAttrs from
int16_t to int32_t to make room for new highlight attribute flags,
since there was only one spare bit left.
- The C flag is named HL_CONCEALED to avoid colliding with the
existing HL_CONCEAL in syntax.h (which is a syntax group flag, not
an SGR attribute).
- Also note that libvterm doesn't currently support the dim and overline
attributes, so e.g. `printf '\e[2mThis should be dim\n'` and `printf
'\e[53mThis should have an overline\n'` are still not rendered
correctly when run from the embedded terminal.
When running out of memory in a libuv callback, try_to_free_memory()
will call mf_release_all(). In this case, mf_sync() cannot call
os_breakcheck() as it'll run the libuv loop recursively, so check
main_loop.recursive to prevent that.
Also fix another possible problem that a terminal buffer may have a
swapfile when encountering an OOM in e.g. terminal_alloc().
Problem: undoing after the prompt is changed breaks it (and causes init_prompt
to abort it and append a new one), as the undo history contains the old prompt.
Solution: like submitting, clear the undo buffer. Don't do it in init_prompt if
the line was empty; that may not result in a new prompt, and causes commands
like "S" to lose the history.
As u_save, etc. wasn't being called by prompt_setprompt, undoing after it fixes
the prompt usually gave undesirable results anyway.
Remove the added undo_spec.lua test, as its approach no longer works as a repro,
and finding a new one seems fiddly.
Problem: prompt_setprompt adjusted cursor col may be negative (<=0 when
1-based), and doesn't check the col of ':
Solution: avoid negative col and adjust correctly if ': col differs from old
prompt's length.
Problem: prompt_setprompt memory leak/other issues when fixing prompt line for
unloaded buffer, or when ': line number is zero.
Solution: don't fix prompt line for unloaded buffer. Clamp ': lnum above zero.
Problem: Strange behavior when opening terminal on unloaded buffer.
Solution: For nvim_open_term() ensure the buffer is loaded as it needs
to be read into the terminal. For jobstart() just open the
memfile as the file content isn't needed.
Not going to make nvim_open_term() pass stdin to the terminal when stdin
isn't read into a buffer yet, as other APIs don't read stdin on unloaded
buffer either. There are also other problems with loading buffer before
reading stdin, so it's better to address those in another PR.