| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Otherwise cursor and redraw code for normal and insert mode will not run. The
"tickle" workaround was used for this instead, and can now be removed.
The builtin vim.lua got the name
[string "-- Nvim-Lua stdlib: thevimmodule (:help l..."]
in error messages. Fix it to something reasonable.
|
| |
|
|
|
|
|
|
|
|
| |
- 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).
|
|
|
|
|
|
| |
- Normal-mode redo idiom(?): prepend "i" and append ESC.
- Insert-mode only needs AppendToRedobuffLit().
- Cmdline-mode: only paste the first line.
|
| |
|
|
|
|
|
|
| |
- Send `phase` parameter to the paste handler.
- Redraw at intervals and when paste terminates.
- Show "..." throbber during paste to indicate activity.
|
|
|
|
| |
This is "readfile()-style", see also ":help channel-lines".
|
| |
|
| |
|
|
|
|
|
|
| |
Flush input before entering, not only when leaving, paste mode. Else
there could be pending input which will erroneously be sent to the paste
handler.
|
|
|
|
|
|
|
| |
- Define in Lua so that it is compiled-in (available with `-u NONE`).
TODO: Eventually we will want a 'pastefunc' option or some other way to
override the default paste handler.
|
| |
|
| |
|
| |
|
|
|
| |
Fixes https://github.com/neovim/neovim/issues/10159.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: When we changed startup to wait for the TUI (like a remote UI),
we forgot to set os/input.c:global_fd. That used to be done by
input_start().
Solution: Initialize os/input.c:global_fd before initializing libtermkey
(termkey_new_abstract) so that tui_get_stty_erase() and
friends can inspect the correct fd.
fixes #10134
close #10174
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
fixes #7967
fixes #9959
Historically Vim/Nvim does backflips to handle input and show messages
before a UI is available. This logical contradiction was already fixed
for remote UIs (#9024 c236e80cf3df). Fixing it also for the TUI avoids
problems on Windows, simplifies the logic, and avoids races like #9959.
- Move ui_builtin_start() to the same position as embedded_mode
remote_ui_wait_for_attach().
- If stdin is redirected, save the original `stdin` and replace fd
0 with tty before calling `ui_builtin_start()`.
|
| | |
|
|/ |
|
|
|
| |
ref #9825
|
|
|
|
|
|
|
|
| |
- Rename the module prefix to "tinput_" instead of "term_input".
- Some of the private functions were confusing, for example
enqueue_input() calls input_enqueue() in another module.
- It is helpful for discussion, documentation, and stacktraces if
functions (even private) are globally unique.
|
|
|
|
|
| |
Based on feedback from upstream:
https://github.com/vim/vim/pull/4100
|
|
|
|
|
|
|
|
|
|
|
| |
If terminal response is received during startup, set 'background' from
a nested "one-shot" (once) VimEnter autocmd.
The previous not-so-clever "self-rescheduling" approach could cause
a long delay at startup (event-loop does not make forward progress).
fixes #9675
ref #9509
|
|
|
|
|
|
|
|
|
| |
- Like Vim, use set_option_value() followed by reset_option_was_set().
- Do not use set_string_default(), so the default is predictable.
This affects `:set bg&`.
- Wait until end-of-startup (VimEnter) to handle the response. The
response is racey anyways, so timing is irrelevant. This allows
OptionSet to be triggered, unlike during startup.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
xterm-compatible terminals support reporting their configured colors
back to the application. Use this to obtain the current background
color, compute its luminance to classify it as light or dark, and set
'bg' accordingly. Also set the default for 'bg', so that `:set bg&`
will revert to that detected default.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Note about shada.c:
- shada_read_next_item_start was intentionally shadowing `unpacked` and
`i` because many of the macros (e.g. ADDITIONAL_KEY) implicitly
depended on those variable names.
- Macros were changed to parameterize `unpacked` (but not `i`). Macros
like CLEAR_GA_AND_ERROR_OUT do control-flow (goto), so any other
approach is messy.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some terminals don't report which buttons are involved in some mouse
events. For example, the urxvt protocol
(http://www.huge-man-linux.net/man7/urxvt.html section "Mouse
reporting") does not report which button has been released.
In this case libtermkey reports button 0
(http://www.leonerd.org.uk/code/libtermkey/doc/termkey_interpret_mouse.3.html)
Up to now, forward_mouse_event did not handle button==0.
On press events there is not much we can do, and we keep the
current behavior which is dropping the event. But on drag-and-release
events we can compensate by remembering the last button pressed.
fixes #3182 for urxvt
fixes #5400
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| | |
Anything claiming to be an xterm gets DECSCUSR. This is the only
reasonable choice unless/until we get more reliable detection (#7490).
ref #6997
closes #7550
|
| |
| |
| |
| |
| | |
closes #4840
closes #6164
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For CI builds unibilium is provided through msys2 packages, and
libtermkey is built from source in third-party from equalsraf/libtermkey.
In Windows we cannot read terminal input from the stdin file descriptor,
instead use libuv's uv_tty API. It should handle key input and encoding.
The UI suspend is not implemented for Windows, because the
SIGSTP/SIGCONT do not exist in windows. Currently this is a NOOP.
Closes #3902
Closes #6640
|
| |
| |
| |
| | |
It was replaced by the "child queue" concept (MultiQueue).
|
| |
| |
| |
| |
| |
| | |
Should never happen, but better to be explicit.
Helped-by: oni-link <knil.ino@gmail.com>
|
| | |
|
| |
| |
| |
| | |
Closes #5984
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Requires libtermkey 0.19+
Closes #2048
Closes #5693
See https://github.com/neovim/libtermkey/compare/a9b61424aae9f7548162ff112393c5f706cf54f1%5E...c0eb4e4a05f49ad8fee0195c77f2c29d09cc36af
See https://bugzilla.redhat.com/show_bug.cgi?id=142659
See https://github.com/tmux/tmux/blob/fe4e9470bb504357d073320f5d305b22663ee3fd/tty-keys.c#L625-L632
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Closes #1234
multiqueue:
- Implement multiqueue_size()
- Rename MultiQueueItem.parent to MultiQueueItem.parent_item, to avoid confusion
with MultiQueue.parent.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Eliminate mb_init():
Set "enc_utf" and "has_mbyte" early. Eliminate "enc_unicode" and "enc_latin1like".
init_chartab() and screenalloc() are already invoked elsewhere
in the initialization process.
The EncodingChanged autocmd cannot be triggered.
At initialization, there is no spellfiles to reload
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`lib/queue.h` implements a basic queue. `event/queue.c` implements
a specialized data structure on top of lib/queue.h; it is not a "normal"
queue.
Rename the specialized multi-level queue implemented in event/queue.c to
"multiqueue", to avoid confusion when reading the code.
Before this change one can eventually notice that "macros (uppercase
symbols) are for the normal queue, lowercase operations are for the
multi-level queue", but that is unnecessary friction for new developers
(or existing developers just visiting this part of the codebase).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
move `call_shell` to misc1.c
Move some fns to state.c
Move some fns to option.c
Move some fns to memline.c
Move `vim_chdir*` fns to file_search.c
Move some fns to new module, bytes.c
Move some fns to fileio.c
|
| | |
|
|/ |
|