aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/state.c
Commit message (Collapse)AuthorAge
* vim-patch:8.1.2057: the screen.c file is much too bigLewis Russell2022-08-19
| | | | | | | | | | | | | | | Problem: The screen.c file is much too big. Solution: Split it in three parts. (Yegappan Lakshmanan, closes vim/vim#4943) https://github.com/vim/vim/commit/7528d1f6b5422750eb778dfb550cfd0b0e540964 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>
* feat(terminal): implement <c-\><c-o> for terminal modebfredl2022-08-02
| | | | this works similar to <c-o> or <c-\><c-o> in insert mode
* vim-patch:8.1.1076: file for Insert mode is much too bigzeertzjq2022-07-20
| | | | | | | | | | | | Problem: File for Insert mode is much too big. Solution: Split off the code for Insert completion. (Yegappan Lakshmanan, closes vim/vim#4044) https://github.com/vim/vim/commit/7591bb39d58ece38a5fef984a08ea9012616c1f9 Cherry-pick ins_compl_len() -> get_compl_len() from patch 8.2.4001. Revert a71c5e9eb98fbb2ca88510269935cdcda37369fc: ctrl_x_mode is no longer a global variable, so l_ctrl_x_mode is no longer needed.
* docs: fix typos (#18269)dundargoc2022-06-04
| | | | | | | | | | Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Dan Sully <dan+github@sully.org> Co-authored-by: saher <msaher.shair@gmail.com> Co-authored-by: Stephan Seitz <stephan.seitz@fau.de> Co-authored-by: Benedikt Müller <d12bb@posteo.de> Co-authored-by: Andrey Mishchenko <mishchea@gmail.com> Co-authored-by: Famiu Haque <famiuhaque@protonmail.com> Co-authored-by: Oliver Marriott <hello@omarriott.com>
* fix(logging): skip recursion, fix crash #18764Justin M. Keyes2022-05-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: 1. The main log routine does not protect itself against recursion. log_lock() doesn't guard against recursion, it would deadlock... 2. 22b52dd462e5 (#11501) regressed 6f27f5ef91b3 (#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.
* refactor(uncrustify): set maximum number of consecutive newlines to 2 (#18695)dundargoc2022-05-25
|
* refactor: replace char_u variables and functions with charDundar Goc2022-05-16
| | | | Work on https://github.com/neovim/neovim/issues/459
* vim-patch:8.2.4911: the mode #defines are not clearly named (#18499)zeertzjq2022-05-10
| | | | | | | | Problem: The mode #defines are not clearly named. Solution: Prepend MODE_. Renumber them to put the mapped modes first. https://github.com/vim/vim/commit/249591057b4840785c50e41dd850efb8a8faf435 A hunk from the patch depends on patch 8.2.4861, which hasn't been ported yet, but that should be easy to notice.
* vim-patch:8.2.4845: duplicate codezeertzjq2022-04-30
| | | | | | | | | | | | | | | | | | | | Problem: Duplicate code. Solution: Move code below if/else. (closes vim/vim#10314) https://github.com/vim/vim/commit/590f365f91511c164253c5b5812d4d0fc4a238d6 N/A patches for version.c: vim-patch:8.2.4844: <C-S-I> is simplified to <S-Tab> Problem: <C-S-I> is simplified to <S-Tab>. Solution: Do not simplify CTRL if there is also SHIFT. (closes vim/vim#10313) https://github.com/vim/vim/commit/758a8d199988b5b25566b2820db60dc2c9de3e58 vim-patch:8.2.4846: termcodes test fails Problem: Termcodes test fails. Solution: use CTRL-SHIFT-V to insert an unsimplified key. (closes vim/vim#10316) https://github.com/vim/vim/commit/bad8a013c238595aa206690210eb1367fbc878f9
* vim-patch:8.2.4723: the ModeChanged autocmd event is inefficientzeertzjq2022-04-10
| | | | | | | | | Problem: The ModeChanged autocmd event is inefficient. Solution: Avoid allocating memory. (closes vim/vim#10134) Rename trigger_modechanged() to may_trigger_modechanged(). https://github.com/vim/vim/commit/2bf52dd065495cbf28e28792f2c2d50d44546d9f Make v:event readonly for ModeChanged.
* fix(event-loop): check if executed register has endedzeertzjq2022-04-07
|
* fix(event-loop): duplicate display updating logic in vgetorpeek() (#17913)zeertzjq2022-03-30
|
* fix(event-loop): call vpeekc() directly first to check for characterzeertzjq2022-02-03
| | | | Expand mappings first by calling `vpeekc()` directly.
* vim-patch:8.2.3227: 'virtualedit' can only be set globallyzeertzjq2022-01-15
| | | | | | | | Problem: 'virtualedit' can only be set globally. Solution: Make 'virtualedit' global-local. (Gary Johnson, closes vim/vim#8638) https://github.com/vim/vim/commit/53ba05b09075f14227f9be831a22ed16f7cc26b2 I changed some macros to unsigned integer literals to avoid compiler warnings.
* fix: make mode() return correct value in ex modebrian m. carlson2022-01-08
| | | | | | | | | When the user is in ex mode, a call to mode(1) is documented to return "cv". However, it does not currently do so, because the check which checks for ex mode is nested inside a conditional which is never reached in ex mode. Vim uses an explicit check for exmode_active, so let's do the same thing here. Add some tests for this case both with a TTY and in silent mode.
* refactor(misc1): move out autocmd related functionsBjörn Linse2021-12-09
|
* vim-patch:8.2.3430: no generic way to trigger an autocommand on mode changeMagnus Groß2021-11-18
| | | | | | | | | | | | | | | | | Problem: No generic way to trigger an autocommand on mode change. Solution: Add the ModeChanged autocommand event. (Magnus Gross, closes vim/vim#8856) https://github.com/vim/vim/commit/f1e8876fa2359b572d262772747405d3616db670 N/A patches for version.c: vim-patch:8.2.3434: function prototype for trigger_modechanged() is incomplete Problem: Function prototype for trigger_modechanged() is incomplete. Solution: Add "void". https://github.com/vim/vim/commit/28e591dd5080bbcd0f468f9d9597cedb716e28c9 Fixes #4399. Fixes #7416.
* vim-patch:8.2.3461: distinguish Normal and Terminal-Normal mode #15878zeertzjq2021-10-09
| | | | | Problem: Cannot distinguish Normal and Terminal-Normal mode. Solution: Make mode() return "nt" for Terminal-Normal mode. (issue vim/vim#8856) https://github.com/vim/vim/commit/72406a4bd2896915b6f541e26d41521a59b1f846
* vim-patch:8.2.3466: completion submode not indicated for virtual replace ↵zeertzjq2021-10-03
| | | | | | | (#15886) Problem: Completion submode not indicated for virtual replace. Solution: Add submode to "Rv". (closes vim/vim#8945) https://github.com/vim/vim/commit/cc8cd4453332276d55b4a1109eace5785a4f319d
* refactor: format with uncrustify #15778dundargoc2021-09-25
| | | * fixup: force exactly one whitespace between type and variable
* vim-patch:8.2.3236: mode() does not indicate using CTRL-O in Select modezeertzjq2021-07-29
| | | | | | Problem: mode() does not indicate using CTRL-O in Select mode. Solution: Use "vs" and similar. (closes vim/vim#8640) https://github.com/vim/vim/commit/eaf3f36168f85c8e0ab7083cd996b9fbe937045d
* Remove EXMODE_NORMALmatveyt2021-07-23
|
* state: throttle batched event processing when input is availableBjörn Linse2021-03-08
| | | | | | | before, calling vim.schedule() from inside an event would execute the scheduled callback immediately after this event without checking for user input in between. Break event processing whenever user input or an interrupt is available.
* doc + extmarks tweaks #11421Justin M. Keyes2019-11-25
| | | | - nvim_buf_get_extmarks: rename "amount" => "limit" - rename `set_extmark_index_from_obj`
* refactor: allow us to process a child queue only while waiting on inputBjörn Linse2019-09-08
|
* log: log_key()Justin M. Keyes2019-08-27
|
* vim-patch:8.0.1480: patch missing changeJan Edmund Lazo2019-06-23
| | | | | | Problem: Patch missing change. Solution: Add missing change. https://github.com/vim/vim/commit/0562532c2eee6205d225aa1dc7e3e89af0dfd990
* vim-patch:8.1.0225: mode() does not indicate using CTRL-O from Insert mode ↵Justin M. Keyes2019-02-24
| | | | | | | (#9644) Problem: Mode() does not indicate using CTRL-O from Insert mode. Solution: Add "niI", "niR" and "niV" to mode() result. (closes vim/vim#3000) https://github.com/vim/vim/commit/612cc3888b136e80485132d9f997ed457dbc5501
* vim-patch:8.1.0648: custom operators can't act upon forced motionPedro L. Ramos2019-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Custom operators can't act upon a forced motion. (Christian Wellenbrock) Solution: Add the forced motion to the mode() result. (Christian Brabandt, closes vim/vim#3490) https://github.com/vim/vim/commit/5976f8ff00efcb3e155a89346e44f2ad43d2405a closes #8667 closes #9476 Christian Wellenbrock: > For (most) built in text objects it's possible to force operation on > them to be linewise, for example by using `dVab` (`:h o_V`, > `motion_force`). When using custom text objects (defined as mappings > by plugins for example), this doesn't currently work. > > Example: > > onoremap x viw > > Open a file with a few lines each containing some words. With the > cursor on any word, try: > > 1. `dw` (builtin) deletes some characters > 2. `dVw` (builtin) deletes linewise > 3. `dx` (from mapping) deletes some characters > 4. `dVx` (from mapping) deletes some characters, but should delete > linewise ref: https://github.com/wellle/targets.vim/issues/214 ref: https://gitter.im/neovim/neovim?at=5b379ff7f1664406610e7483
* log: RPC, input, other eventsJustin M. Keyes2018-09-19
|
* globals: virtual_op is TriStateJan Edmund Lazo2018-08-01
|
* Merge #7587 'vim-patch:8.0.0283'Justin M. Keyes2017-11-19
|\
| * vim-patch:8.0.0283ckelsel2017-11-19
|/ | | | | | | | | Problem: The return value of mode() does not indicate that completion is active in Replace and Insert mode. (Zhen-Huan (Kenny) Hu) Solution: Add "c" or "x" for two kinds of completion. (Yegappan Lakshmanan, closes vim/vim#1397) Test some more modes. https://github.com/vim/vim/commit/e90858d0229444b3cd16b1cd3a8d61a24c435705
* doc: eventloopJustin M. Keyes2017-09-05
|
* eventloop: FocusGained: schedule event instead of pseudokeyJustin M. Keyes2017-09-05
| | | | | closes #4840 closes #6164
* terminal: block redraw during c_CTRL-DJustin M. Keyes2017-08-05
| | | | | | | | Unlike the normal wildmenu, the CTRL-D wild-list is not restored by statusline redraw. (Semantics: ^D is controlled by 'wildoptions' option, so it's in the "wild..." family.) TODO: externalize the c_CTRL-D wild-list.
* api: nvim_get_mode()Justin M. Keyes2017-04-28
| | | | | | | | | | | | | | | | | | | | | | | | | | Asynchronous API functions are served immediately, which means pending input could change the state of Nvim shortly after an async API function result is returned. nvim_get_mode() is different: - If RPCs are known to be blocked, it responds immediately (without flushing the input/event queue) - else it is handled just-in-time before waiting for input, after pending input was processed. This makes the result more reliable (but not perfect). Internally this is handled as a special case, but _semantically_ nothing has changed: API users never know when input flushes, so this internal special-case doesn't violate that. As far as API users are concerned, nvim_get_mode() is just another asynchronous API function. In all cases nvim_get_mode() never blocks for more than the time it takes to flush the input/event queue (~µs). Note: This doesn't address #6166; nvim_get_mode() will provoke #6166 if e.g. `d` is operator-pending. Closes #6159
* *: Add comment to all C filesZyX2017-04-19
|
* event/multiqueue.c: Rename "queue" to "multiqueue".Justin M. Keyes2016-10-02
| | | | | | | | | | | | | | `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).
* refactor: eliminate misc2.cJustin M. Keyes2016-09-13
| | | | | | | | | | 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
* *: Rename main loop variable from loop to main_loopZyX2016-05-30
| | | | | | | | | | | | | | | | Current name is inappropriate for the following reasons: 1. It is often masked by local `loop` variables. 2. It cannot be searched for. There are many `loop` variables where `loop` is some local variable. There are many cases when “loop” word is used in a comment. 3. It is in any case bad idea to use a generic name as a name of the global variable. Best if global has module prefix: this is why it is in `main.h`: `main_loop` both stands for “a main loop” and “a loop defined in `main.*`”. Since I have no idea how to list every occurrence of this variable method used to rename it is “remove it from globals.h, try to compile, fix errors”. Thus if some occurrence was hidden under false `#if` branch it was not replaced.
* main: Start modeling Nvim as pushdown automatonThiago de Arruda2015-10-26
From a very high level point of view, Vim/Nvim can be described as state machines following these instructions in a loop: - Read user input - Peform some action. The action is determined by the current state and can switch states. - Possibly display some feedback to the user. This is not immediately visible because these instructions spread across dozens of nested loops and function calls, making it very hard to modify the state machine(to support more event types, for example). So far, the approach Nvim has taken to allow more events is this: - At the very core function that blocks for input, poll for arbitrary events. - If the event received from the OS is user input, just return it normally to the callers. - If the event is not direct result of user input(possibly a vimscript function call coming from a msgpack-rpc socket or a job control callback), return a special key code(`K_EVENT`) that is handled by callers where it is safer to perform arbitrary actions. One problem with this approach is that the `K_EVENT` signal is being sent across multiple states that may be unaware of it. This was partially fixed with the `input_enable_events`/`input_disable_events` functions, which were added as a mechanism that the upper layers can use to tell the core input functions that it is ready to accept `K_EVENT`. Another problem is that the mapping engine is implemented in getchar.c which is called from every state, but the mapping engine is not aware of `K_EVENT` so events can break mappings. While it is theoretically possible to modify getchar.c to make it aware of `K_EVENT`, this commit fixes the problem with a different approach: Model Nvim as a pushdown automaton(https://en.wikipedia.org/wiki/Pushdown_automaton). This design has many advantages which include: - Decoupling the event loop from the states reponsible for handling events. - Better control of state transition with less dependency on global variable hacks(eg: 'restart_edit' global variable). - Easier removal of global variables and function splitting. That is because many variables are for state-specific information, and probably ended up being global to simplify communication between functions, which we fix by storing state-specific information in specialized structures. The final goal is to let Nvim have a single top-level event loop represented by the following pseudo-code: ``` while not quitting let event = read_event current_state(event) update_screen() ``` This closely mirrors the state machine description above and makes it easier to understand, extend and debug the program. Note that while the pseudo code suggests an explicit stack of states that doesn't rely on return addresses(as suggested by the principles of automata-based programming: https://en.wikipedia.org/wiki/Automata-based_programming), for now we'll use the call stack as a structure to manage state transitioning as it would be very difficult to refactor Nvim to use an explicit stack of states, and the benefits would be small. While this change may seem like an endless amount of work, it is possible to do it incrementally as was shown in the previous commits. The general procedure is: 1- Find a blocking `vgetc()`(or derivatives) call. This call represents an implicit state of the program. 2- Split the code before and after the `vgetc()` call into functions that match the signature of `state_check_callback` and `state_execute_callback. Only `state_execute_callback` is required. 3- Create a `VimState` "subclass" and a initializer function that sets the function pointers and performs any other required initialization steps. If the state has no local variables, just use `VimState` without subclassing. 4- Instead of calling the original function containing the `vgetc()`, initialize a stack-allocated `VimState` subclass, then call `state_enter` to begin processing events in the state. 5- The check/execute callbacks can return 1 to continue normally, 0 to break the loop or -1 to skip to the next iteration. These callbacks contain code that execute before and after the old `vgetc()` call. The functions created in step 2 may contain other `vgetc()` calls. These represent implicit sub-states of the current state, but it is fine to remove them later in smaller steps since we didn't break compatibility with existing code.
generated by cgit (git 2.34.1) at 2025-06-25 15:11:30 +0000