Previously, there were three low-level delay entry points
- os_delay(ms, ignoreinput=true): sleep for ms, only break on got_int
- os_delay(ms, ignoreinput=false): sleep for ms, break on any key input
os_microdelay(us, false): equivalent, but in μs (not directly called)
- os_microdelay(us, true): sleep for μs, never break.
The implementation of the latter two both used uv_cond_timedwait()
This could have been for two reasons:
1. allow another thread to "interrupt" the wait
2. uv_cond_timedwait() has higher resolution than uv_sleep()
However we (1) never used the first, even when TUI was a thread, and
(2) nowhere in the codebase are we using μs resolution, it is always a ms
multiplied with 1000.
In addition, os_delay(ms, false) would completely block the thread for
100ms intervals and in between check for input. This is not how event handling
is done alound here.
Therefore:
Replace the implementation of os_delay(ms, false) to use
LOOP_PROCESS_EVENTS_UNTIL which does a proper epoll wait with a timeout,
instead of the 100ms timer panic.
Replace os_microdelay(us, false) with a direct wrapper of uv_sleep.
Problem:
has('gui_running') is still common in the wild and our answer has
changed over time, causing frustration.
95a6ccbe9f
Solution:
Use stdin_tty/stdout_tty to decide if a UI is (not) a GUI.
Problem:
- API validation involves too much boilerplate.
- API validation errors are not consistently worded.
Solution:
Introduce some macros. Currently these are clumsy, but they at least
help with consistency and avoid some nesting.
- <expr> mapping has no business saving and restoring the
low-level UI cursor. The cursor will be put in a reasonable
position after input is processed, chill out.
- TUI handles output needed for suspend
- vgetc() family of function does flushing
Problem: Code is indented more than necessary.
Solution: Use an early return where it makes sense. (Yegappan Lakshmanan,
closesvim/vim#11813)
e857598896
Partial port as this depends on some previous eval and 'smoothscroll'
patches.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
- The defined interface for the UI is only the RPC protocol. The original
UI interface as an array of function pointers fill no function.
- On the server, all the UI:s are all RPC channels.
- ui.c is only used on the server.
- The compositor is a preprocessing step for single-grid UI:s
- on the client, ui_client and tui talk directly to each other
- we still do module separation, as ui_client.c could form the basis
of a libnvim client module later.
Items for later PR:s
- vim.ui_attach is still an unhappy child, reconsider based on plugin experience.
- the flags in ui_events.in.h are still a mess. Can be simplified now.
- UX for remote attachment needs more work.
- startup for client can be simplified further (think of the millisecs we can save)
This was previously disabled due to build issues on windows.
Any reasonable platform can now be expected to have the necessary
interfaces to build and run the TUI subsystem.
Runtime quality issues of using the TUI (on any new platform) are not
relevant here. Just run Nvim in an external UI instead of the TUI as always.
Allow Include What You Use to remove unnecessary includes and only
include what is necessary. This helps with reducing compilation times
and makes it easier to visualise which dependencies are actually
required.
Work on https://github.com/neovim/neovim/issues/549, but doesn't close
it since this only works fully for .c files and not headers.
Problem: Assert_fails() setting emsg_silent changes normal execution.
Solution: Use a separate flag in_assert_fails.
28ee892ac4
Cherry-pick no_wait_return from patch 9.0.0846.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: The screen.c file is much too big.
Solution: Split it in three parts. (Yegappan Lakshmanan, closesvim/vim#4943)
7528d1f6b5
This is an approximation vim-patch 8.1.2057. Applying the patch directly
isn't feasible since our version of screen.c has diverged too much,
however we still introduce drawscreen.c and drawline.c:
- screen.c is now a much smaller file used for low level screen functions
- drawline.c contains everything needed for win_line()
- drawscreen.c contains everything needed for update_screen()
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
vim-patch:8.1.2082: some files have a weird name to fit in 8.3 characters
Problem: Some files have a weird name to fit in 8.3 characters.
Solution: Use a nicer names.
30e8e73506
Note for external UIs: Nvim can now emit multiple "redraw" event batches
before a final "flush" event is received. To retain existing behavior,
clients should make sure to update visible state at an explicit "flush"
event, not just the end of a "redraw" batch of event.
* Get rid of copy_object() blizzard in the auto-generated ui_event layer
* Special case "grid_line" by encoding screen state directly to
msgpack events with no intermediate API events.
* Get rid of the arcane notion of referring to the screen as the "shell"
* Array and Dictionary are kvec_t:s, so define them as such.
* Allow kvec_t:s, such as Arrays and Dictionaries, to be allocated with
a predetermined size within an arena.
* Eliminate redundant capacity checking when filling such kvec_t:s
with values.
Problem:
Piping NodeJS output into Neovim makes the editor unusable.
This happens because NodeJS changes the tty state on exit after
Nvim calls uv_tty_set_mode(). (May not always happen due to race
condition.)
This should have been fixed by 4ba5b4a864#13084. But some
commands and functions (:sleep, system(), …) call ui_flush()
internally, in particular the first tui_mode_change() is called before
the end of startup.
Steps to reproduce:
1. node -e "setTimeout(()=>{console.log('test')}, 1000)" | nvim -u NORC +"sleep 500m" -
2. The cursor key letters just overwrite the editor screen, and CTRL+C exits.
Solution:
Skip pending_mode_update during startup.
Note: Delaying ui_flush() entirely could be a more general solution
(emit a new UI event on VimEnter?). But "remote/coprocess TUI" #18375
could make all of this moot anyway.
Fixes#18470
drawback: tracing memory errors with ASAN is less accurate for arena
allocated memory.
Therefore, to start with it is being used for Object types around
serialization/deserialization exclusively. This is going to have
a large impact especially when TUI is refactored as a co-prosess
as all UI events will be serialized and deserialized by nvim itself.
Problem:
1. The main log routine does not protect itself against recursion.
log_lock() doesn't guard against recursion, it would deadlock...
2. 22b52dd462 (#11501) regressed 6f27f5ef91 (#10172), because
set_init_1..process_spawn tries to log (see backtrace below), but the
mutex isn't initialized yet. Even if the mutex were valid, we don't
want early logging to fallback to stderr because that can break
embedders when stdio is used for RPC.
frame 1: 0x00000001001d54f4 nvim`open_log_file at log.c:205:7
frame 2: 0x00000001001d5390 nvim`logmsg(log_level=1, context="UI: ", func_name=0x0000000000000000, line_num=-1, eol=true, fmt="win_viewport") at log.c:150:20
frame : 0x000000010039aea2 nvim`ui_call_win_viewport(grid=2, win=1000, topline=0, botline=1, curline=0, curcol=0, line_count=1) at ui_events_call.generated.h:321:3
frame 4: 0x00000001003dfefc nvim`ui_ext_win_viewport(wp=0x0000000101816400) at window.c:939:5
frame 5: 0x00000001003ec5b4 nvim`win_ui_flush at window.c:7303:7
frame 6: 0x00000001003a04c0 nvim`ui_flush at ui.c:508:3
frame 7: 0x00000001002966ba nvim`do_os_system(argv=0x0000600000c0c000, input=0x0000000000000000, len=0, output=0x0000000000000000, nread=0x00007ff7bfefe830, silent=false, forward_output=false) at shell.c:894:3
frame 8: 0x0000000100295f68 nvim`os_call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_args=0x0000000000000000) at shell.c:663:18
frame 9: 0x0000000100295845 nvim`call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_shell_arg=0x0000000000000000) at shell.c:712:14
frame 10: 0x0000000100294c6f nvim`os_expand_wildcards(num_pat=1, pat=0x00007ff7bfefeb20, num_file=0x00007ff7bfefee58, file=0x00007ff7bfefee60, flags=43) at shell.c:328:7
...
frame 23: 0x000000010028ccef nvim`expand_env_esc(srcp=",~foo", dst="~foo", dstlen=4094, esc=false, one=false, prefix=0x0000000000000000) at env.c:673:17
frame 24: 0x000000010026fdd5 nvim`option_expand(opt_idx=29, val=",~foo") at option.c:1950:3
frame 25: 0x000000010026f129 nvim`set_init_1(clean_arg=false) at option.c:558:19
frame 26: 0x00000001001ea25e nvim`early_init(paramp=0x00007ff7bfeff5f0) at main.c:198:3
frame 27: 0x00000001001ea6bf nvim`main(argc=1, argv=0x00007ff7bfeff848) at main.c:255:3
Solution:
1. Check for recursion, show "internal error" message.
- FUTURE: when "remote TUI" is merged, can we remove log_lock()?
2. Skip logging if log_init wasn't called yet.
Problem: The mode #defines are not clearly named.
Solution: Prepend MODE_. Renumber them to put the mapped modes first.
249591057b
A hunk from the patch depends on patch 8.2.4861, which hasn't been
ported yet, but that should be easy to notice.
