| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
| |
- Introduce TRY_WRAP() until we have an *architectural* solution.
- TODO: bfredl idea: prepare error-handling at "top level" (nv_event).
- nvim_paste(): Revert luaeval() hack (see parent commit).
- With TRY_WRAP() in nvim_put(), 'nomodifiable' error now correctly
"bubbles up".
|
|
|
|
|
|
|
|
| |
- nvim_paste(): Marshal through luaeval() instead of nvim_execute_lua()
because the latter seems to hide some errors.
- Handle 'nomodifiable' in `nvim_put()` explicitly.
- Require explicit `false` from `vim.paste()` in order to "cancel",
otherwise assume true ("continue").
|
| |
|
|
|
|
|
|
|
|
| |
- Show error only once per "paste stream".
- Drain remaining chunks until phase=3.
- Lay groundwork for "cancel".
- Constrain semantics of "cancel" to mean "client must stop"; it is
unrelated to presence of error(s).
|
|
|
|
|
|
|
|
|
|
| |
HACK: The cursor does not get repositioned after the paste completes.
Scheduling a dummy event seems to fix it.
Test case:
0. Revert this commit.
1. Paste some text in Normal-mode.
2. Notice the cursor is still in the cmdline area.
|
|
|
|
|
|
| |
- Normal-mode redo idiom(?): prepend "i" and append ESC.
- Insert-mode only needs AppendToRedobuffLit().
- Cmdline-mode: only paste the first line.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes strange behavior where sometimes the buffer contents of a series
of paste chunks (vim._paste) would be out-of-order.
Now the tui_spec.lua screen-tests are much more reliable. But they still
sometimes fail because of off-by-one cursor (caused by "typeahead race"
resulting in wrong mode; fixed later in this patch-series).
|
| |
|
|
|
|
| |
This is "readfile()-style", see also ":help channel-lines".
|
| |
|
| |
|
| |
|
|
|
| |
Fixes https://github.com/neovim/neovim/issues/10829.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Otherwise vim will think that ml_append() needs to "enter" the buffer,
which emits unexpected autocommands.
ref https://github.com/vim-airline/vim-airline/issues/1930
|
|
|
|
|
| |
- gen_vimdoc.py: fancy "bullet"
- rework `:help channel-callback`
- rename `:help buffered` to `:help channel-buffered`
|
|
|
|
| |
ref #9924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
closes #9136
- Treat empty {rhs} like <Nop>
- getchar.c: Pull "repl. MapArg termcodes" into func
The "preprocessing code" surrounding the replace_termcodes calls needs
to invoke replace_termcodes, and also check if RHS is equal to "<Nop>".
To reduce code duplication, factor this out into a helper function.
Also add an rhs_is_noop flag to MapArguments; buf_do_map_explicit
expects an empty {rhs} string for "<Nop>", but also needs to distinguish
that from something like ":map lhs<cr>" where no {rhs} was provided.
- getchar.c: Use allocated buffer for rhs in MapArgs
Since the MAXMAPLEN limit does not apply to the RHS of a mapping (or
else an RHS that calls a really long autoload function from a plugin
would be incorrectly rejected as being too long), use an allocated
buffer for RHS rather than a static buffer of length MAXMAPLEN + 1.
- Mappings LHS and RHS can contain literal space characters, newlines, etc.
- getchar.c: replace_termcodes in str_to_mapargs
It makes sense to do this; str_to_mapargs is, intuitively, supposed to
take a "raw" command string and parse it into a totally "do_map-ready"
struct.
- api/vim.c: Update lhs, rhs len after replace_termcodes
Fixes a bug in which replace_termcodes changes the length of lhs or rhs,
but the later search through the mappings/abbreviations hashtables
still uses the old length value. This would cause the search to fail
erroneously and throw 'E31: No such mapping' errors or 'E24: No such
abbreviation' errors.
- getchar: Create new map_arguments struct
So that a string of map arguments can be parsed into a more useful, more
portable data structure.
- getchar.c: Add buf_do_map function
Exactly the same as the old do_map, but replace the hardcoded references
to the global `buf_T* curbuf` with a function parameter so that we can
invoke it from nvim_buf_set_keymap.
- Remove gettext calls in do_map error handling
|
| |
|
| |
|
|
|
|
| |
ref #9886
|
| |
|
|\
| |
| | |
windows: float config changes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Allow floating windows of width 1. #9846
- For a new floating window the size must be specified. Later on we
might try to calculate a reasonable size by buffer contents
- Remember the configured size of a window, just like its position.
- Make get_config and set_config more consistent. Handle relative='' properly in set_config.
get_config doesn't return keys that don't make sense for a non-floating window.
- Don't use width=0 for non-changed width, just omit the key.
|
| | |
|
|/
|
| |
Fixes https://github.com/neovim/neovim/issues/9892
|
| |
|
|
|
|
| |
closes #9719
|
|
|
| |
closes #9750
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Co-Author: Dongdong Zhou <dzhou121@gmail.com>
|
|
|
|
|
| |
Creating a scratch buffer is a chore/ritual, and would be more
useful/common if formally exposed.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Loading existing files into a buffer is non-trivial and requires a window.
Creating an unnamed emtpy buffer is trivial and safe though, thus worth a
special case.
Change nvim_buf_set_option to use aucmd_prepbuf. This is necessary
to allow some options to be set on a not yet displayed buffer, such
as 'buftype' option.
vim-patch:7.4.1858: Add BLN_NEW to enforce buflist_new creating new buffer
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Lua
- developer guidelines
- MAINTAIN.md
- TUI: cleanup
- TUI: mention Windows terminfo builtins
- cleanup if_pyth, redirect python-bindeval tag
Helped-by: Björn Linse <bjorn.linse@gmail.com>
Helped-by: erw7 <erw7.github@gmail.com>
|
| |
|
|
|
|
| |
closes #9349
|
| |
|
|
|
|
|
|
|
|
|
| |
There is no need to call update_screen() directly in an API function,
mode input processing invokes update_screen() as needed. And if the API
call is done in a context where redraw is disabled, then redraw is
disabled for a reason. A lot of API functions are of equal semantical
strength (nvim_call_function and nvim_execute_lua can also do whatever,
nvim_command is not special), this inconsistency has no purpose.
|