mirror of
https://github.com/neovim/neovim.git
synced 2024-12-25 05:35:10 -07:00
doc: Add whitespace before parens. #4202
This commit is contained in:
parent
827e267800
commit
f8f92a2360
@ -11,7 +11,7 @@ that are constantly changing. As the code becomes more organized and stable,
|
|||||||
this document will be updated to reflect the changes.
|
this document will be updated to reflect the changes.
|
||||||
|
|
||||||
If you are looking for module-specific details, it is best to read the source
|
If you are looking for module-specific details, it is best to read the source
|
||||||
code. Some files are extensively commented at the top(eg: terminal.c,
|
code. Some files are extensively commented at the top (e.g. terminal.c,
|
||||||
screen.c).
|
screen.c).
|
||||||
|
|
||||||
### Top-level program loops
|
### Top-level program loops
|
||||||
@ -43,13 +43,13 @@ a typical editing session:
|
|||||||
|
|
||||||
Note that we have split user actions into sequences of inputs that change the
|
Note that we have split user actions into sequences of inputs that change the
|
||||||
state of the editor. While there's no documentation about a "g command
|
state of the editor. While there's no documentation about a "g command
|
||||||
mode"(step 16), internally it is implemented similarly to "operator-pending
|
mode" (step 16), internally it is implemented similarly to "operator-pending
|
||||||
mode".
|
mode".
|
||||||
|
|
||||||
From this we can see that Vim has the behavior of a input-driven state
|
From this we can see that Vim has the behavior of a input-driven state
|
||||||
machine(more specifically, a pushdown automaton since it requires a stack for
|
machine (more specifically, a pushdown automaton since it requires a stack for
|
||||||
transitioning back from states). Assuming each state has a callback responsible
|
transitioning back from states). Assuming each state has a callback responsible
|
||||||
for handling keys, this pseudocode(a python-like language) shows a good
|
for handling keys, this pseudocode (a python-like language) shows a good
|
||||||
representation of the main program loop:
|
representation of the main program loop:
|
||||||
|
|
||||||
```py
|
```py
|
||||||
@ -129,20 +129,20 @@ def insert_state(data, key):
|
|||||||
While the actual code is much more complicated, the above gives an idea of how
|
While the actual code is much more complicated, the above gives an idea of how
|
||||||
Neovim is organized internally. Some states like the `g_command_state` or
|
Neovim is organized internally. Some states like the `g_command_state` or
|
||||||
`get_operator_count_state` do not have a dedicated `state_enter` callback, but
|
`get_operator_count_state` do not have a dedicated `state_enter` callback, but
|
||||||
are implicitly embedded into other states(this will change later as we continue
|
are implicitly embedded into other states (this will change later as we continue
|
||||||
the refactoring effort). To start reading the actual code, here's the
|
the refactoring effort). To start reading the actual code, here's the
|
||||||
recommended order:
|
recommended order:
|
||||||
|
|
||||||
1. `state_enter()` function(state.c). This is the actual program loop,
|
1. `state_enter()` function (state.c). This is the actual program loop,
|
||||||
note that a `VimState` structure is used, which contains function pointers
|
note that a `VimState` structure is used, which contains function pointers
|
||||||
for the callback and state data.
|
for the callback and state data.
|
||||||
2. `main()` function(main.c). After all startup, `normal_enter` is called
|
2. `main()` function (main.c). After all startup, `normal_enter` is called
|
||||||
at the end of function to enter normal mode.
|
at the end of function to enter normal mode.
|
||||||
3. `normal_enter()` function(normal.c) is a small wrapper for setting
|
3. `normal_enter()` function (normal.c) is a small wrapper for setting
|
||||||
up the NormalState structure and calling `state_enter`.
|
up the NormalState structure and calling `state_enter`.
|
||||||
4. `normal_check()` function(normal.c) is called before each iteration of
|
4. `normal_check()` function (normal.c) is called before each iteration of
|
||||||
normal mode.
|
normal mode.
|
||||||
5. `normal_execute()` function(normal.c) is called when a key is read in normal
|
5. `normal_execute()` function (normal.c) is called when a key is read in normal
|
||||||
mode.
|
mode.
|
||||||
|
|
||||||
The basic structure described for normal mode in 3, 4 and 5 is used for other
|
The basic structure described for normal mode in 3, 4 and 5 is used for other
|
||||||
@ -159,7 +159,7 @@ asynchronous events, which can include:
|
|||||||
|
|
||||||
- msgpack-rpc requests
|
- msgpack-rpc requests
|
||||||
- job control callbacks
|
- job control callbacks
|
||||||
- timers(not implemented yet but the support code is already there)
|
- timers (not implemented yet but the support code is already there)
|
||||||
|
|
||||||
Neovim implements this functionality by entering another event loop while
|
Neovim implements this functionality by entering another event loop while
|
||||||
waiting for characters, so instead of:
|
waiting for characters, so instead of:
|
||||||
@ -180,11 +180,11 @@ def state_enter(state_callback, data):
|
|||||||
while state_callback(data, event) # invoke the callback for the current state
|
while state_callback(data, event) # invoke the callback for the current state
|
||||||
```
|
```
|
||||||
|
|
||||||
where `event` is something the operating system delivers to us, including(but
|
where `event` is something the operating system delivers to us, including (but
|
||||||
not limited to) user input. The `read_next_event()` part is internally
|
not limited to) user input. The `read_next_event()` part is internally
|
||||||
implemented by libuv, the platform layer used by Neovim.
|
implemented by libuv, the platform layer used by Neovim.
|
||||||
|
|
||||||
Since Neovim inherited its code from Vim, the states are not prepared to receive
|
Since Neovim inherited its code from Vim, the states are not prepared to receive
|
||||||
"arbitrary events", so we use a special key to represent those(When a state
|
"arbitrary events", so we use a special key to represent those (When a state
|
||||||
receives an "arbitrary event", it normally doesn't do anything other update the
|
receives an "arbitrary event", it normally doesn't do anything other update the
|
||||||
screen).
|
screen).
|
||||||
|
Loading…
Reference in New Issue
Block a user