aboutsummaryrefslogtreecommitdiff
path: root/runtime/doc/dev_arch.txt
Commit message (Collapse)AuthorAge
* feat(multicursor): zq operator; cursor-local marks #42148Justin M. Keyes2026-09-29
| | | | | | | | | | | | | | | | | | Problem: - `[count]Q` and `{Visual}Q` are implemented as ad hoc utils, because `Q` is not an "operator". - `Q` always "toggles", it is not "idempotent". - Various *cursor-relative* marks (`'.`, `'[`) are not saved/restored per-cursor, so they don't work during cascade. - Insert cascade clobbers the primary's `'^` and changelist. Solution: - Introduce the `zq{motion}` operator, which places cursors at every reachable `{motion}`. - `{Visual}Q` is now an alias to `{Visual}zqj`. - Introduce `1Q` and `2Q` for idempotent cursor placement. - Drop `[count]Q`, it's redundant with `zqgn`. - Classify cursor-relative marks as `type=motion` instead of `type=jump`. Save/restore per-cursor during cascade.
* feat(multicursor): 'follow' option #42095Justin M. Keyes2026-09-27
| | | | | | | | Problem: - gQ does not restore follow-mode (q=). - Users/plugins have no way to check if follow-mode is enabled. Solution: Introduce buffer-local 'follow' option.
* fix(multicursor): cascade mapping-edit during Visual selection #42027Justin M. Keyes2026-09-21
| | | | | | | | | | | | | | | | Problem: - A mapping that edits the buffer during a Visual selection applies only at the primary cursor. The edit "voids" the pending Visual-session, because `mc_vsel_refresh` only previews the selection per-cursor and must not edit. - A cursor overlapping the primary applies an edit twice, if the command moves the primary before cascade ("yiwp"). Solution: Cascade a Visual session's edits span-by-span, like an insert-session. - Each span is prefixed with "gv" so per-cursor reselect works. - Void only if no subatom was captured. - Dedupe cursors against the primary's anchor at cmd start, not its position after.
* fix(multicursor): visual "gv", change-marks '[,'] #41988Justin M. Keyes2026-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: - `gv` reselects only primary's region, it doesn't have per-cursor behavior. '< '> are buffer-global and the sandbox restores the primary's marks. The Visual atom containing `gv` was voided anyway, so it never cascaded. - Same for change-marks (`'[ '] '.`): they are stale after edits from other cursors, not managed per-cursor. - `McSandbox` saves "editor state", which should be owned by the `Context` module. Solution: Lift more state from `McSandbox` into `Context`. `kCtxCursor` (position, curswant) and `kCtxMarks` (Visual area, change-marks), are owned by `Context` now, as an "in-memory" special-case (TODO: support it for the "serialized" case?). - Classify a `gv` selection as replayable. Manage its state per-cursor. Dot-repeat "." after `gv` behaves like Vim (the "1v" fallback). - Save/restore change-marks per-cursor. The primary's change-marks are shifted by edits from other cursors during the cascade. `McSandbox` still contains (for now) the view and replay isolation (typeahead/mode, redobuff, search patterns, the active selection). Bonus: - `visualmode()` is per cursor. - A cursor's `curswant` follows its column when other cursors' edits shift it, instead of the column captured after its own replay.
* fix(cmdatom): mapping tail after a mode-change is not captured #41897Justin M. Keyes2026-09-13
| | | | | | | | | | | | | | | | Problem: `inoremap <Esc> <Esc>l` starts in insert-mode and ends in normal-mode ("l"). Its normal-mode "l" is not captured as a CmdAtom (and thus doesn't cascade to multicursors in follow-mode). Analysis: CmdFrames only delineate in Normal/Visual/Op-pending (i.e. the `MODE_NORMAL` modes), so a mapping resolved in Insert, Cmdline or Terminal mode does not start a `composite`, then the mapping "tail" is lost. Solution: Start a "deferred" `composite` if state is not `MODE_NORMAL`, instead of skipping it entirely.
* feat(multicursor): MC HAMMER #41587Justin M. Keyes2026-09-01
| | | | | | | | | | | | | | | | | | | | | Other (squashed) commits: fix(tui): emit ui_send output atomically with the frame Problem: tui_ui_send() writes directly to the TTY, bypassing the output buffer. Sequences sent via nvim_ui_send() (e.g. kitty multiple-cursors, or visual-dot-repeat) always arrive in a separate TTY write from the frame they were computed for. This manifests as "tearing", or e.g. in the case of multicursor the terminal renders text with stale cursor overlays. Solution: - tui_ui_send(): while a frame is being assembled (pending invalid regions or buffered output), buffer instead of writing directly. - Out-of-frame sends (tty queries, clear-on-disable) still write immediately. - mcursor.lua: emit the terminal-cursor update at the end of the redraw cycle (`on_end`, when screen positions are final) instead of vim.schedule().
* refactor(input): exec stuffed keys eagerlyJustin M. Keyes2026-08-29
| | | | | | | | | | | | | | | | | | | Problem: The Vim "stuff" concept breaks the ability to reason about the call stack and thus the boundaries of a `CmdAtom`: a stuffed translation ("x" => "dl") defers to the main loop. This "continuation" must be modeled in `CmdAtom`, by checking global flags at undefined times, during undefined circumstances. Solution: - After a stuffed "translation", eagerly execute the stuff buffer (`exec_stuffed()`). - Delete the CmdAtom "continuation" junk. Note: - op_colon runs its cmdline "nested", but that's fine because operators already nest interactive sessions there (op_change runs edit()), and the cmdline is frameless so the operator's frame can own/capture it.
* feat(cmdatom): mappings capture continuationJustin M. Keyes2026-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: A mapping that ends mid-operation (`nnoremap ,D d`) emits a content-free "mapping" atom plus a `pending` field, and the "continuation" motion arrives as a sibling atom. Consumers must stitch the two together (which has broken cases, e.g. Insert-opening mappings (",i") lose their session entirely). - ",i": the session atom is dropped bc the mapping RHS is consumed before the session starts (typebuf_maplen()==0), so atom_is_user_input()=false. - ":normal"-in-opfunc: the opfunc internal "v..y" session (a) became kVatomTyped just because the deferred composite was open, masking the real operator capture via atom_captures, and (b) its nested frames re-derived the outer redo. - "Motion" based on `moved=true`, has false negatives. - `CmdAtom.remap` is unnecessary, and clutters the docs/usage. Solution: - Introduce `frame_id` to identify CmdFrames. - Classify `type=motion` better, via `NV_MOTION` flag on the `nv_cmds` table. - Drop `CmdAtom.pending`, `CmdAtom.remap`. - Defer atom_composite_end() at the clock edge while an operator is pending, Visual is active, or `restart_edit` is set: the composite keeps collecting, so the continuation is captured in the mapping atom. - ",i": Now an open composite counts as user input. - ":normal"-in-opfunc: Now handled correctly. - `remap` is now decided by `composite.payload || 0 subatoms`. atom_payload_mark() records the read the resolution never captures. - `toplevel` is now decided by `CmdFrame.parent == NULL`. before/after: INPUT BEFORE AFTER --------------------------------------------------------------------- ,D w {mapping lhs=,D pending=operator} {operator lhs=,Dw keys=dw} + {operator keys=dw} ysiw" {mapping lhs=ys pending=operator} {operator lhs=ysiw" keys=g@iw"} + {operator lhs=g@iw"} ,v d {mapping pending=visual} {visual lhs=,vd keys=viwd} + {visual lhs=viwd} ,i XY<Esc> {normal keys=i lhs=,iXY<Esc>} {insert keys=1iXY<Esc> text=XY}
* feat(input)!: CmdAtom event #41297Justin M. Keyes2026-08-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: There is no unified notion of a "user action". Vim processes input by one-char-at-a-time, and mostly throws away any hints it might gather about the user's action, with one exception: it stores the last _edit_ action (the "redo buffer", encoded as unstructured `["x][v][count]body` bytes). Plugins can only observe individual keys (vim.on_key) and high-level effects (TextChanged, CursorMoved). Solution: - Users can subscribe to `CmdAtom` events to handle any user action. - Event is deferred; handlers cannot cancel or interfere with user actions. - Capture `CmdSpec` from the normal/insert/visual subsystems. - typeahead/readahead stay unstructured (`buffheader_T`): they are key streams, not commands. - the redo/record buffers become `StringBuilder`: fewer allocations/copies. - Repurpose the input/redo engine to accept `CmdSpec` objects. "atom": one repeatable unit of user input, as a resolved (post-mapping) keysequence plus structured fields. Only user actions, not `:normal`, API calls, or non-"t" `feedkeys`. BREAKING: dot-repeat of an Insert session, replays the entire session including cursor-moves (:help ins-repeat). BREAKING: dot-repeat of a Visual operation, replays the selection instead of operating on a fixed-size region.
* refactor(insert): rename edit.c => insert.c #40705Justin M. Keyes2026-07-12
| | | | | | | | | | Problem: - `edit.c` is an unnecessarily misleading and less-discoverable name than `insert.c`. - Numerous insert-mode related things are named with a `ins_` prefix. - There is already a `insexpand.c` module... Solution: Rename `edit.c` => `insert.c`.
* refactor(lua): rename nlua_call_typvalJustin M. Keyes2026-07-06
|
* docs: dev, lsp, indent-guides #39756Justin M. Keyes2026-05-14
| | | | | | | - document "indent guides" https://github.com/neovim/neovim/issues/39726 - document guidance for "subcommands" https://github.com/neovim/neovim/issues/32263#issuecomment-4436002808 Co-authored-by: glepnir <glephunter@gmail.com> Co-authored-by: Noa Levi <275430404+lphuc2250gma@users.noreply.github.com>
* fix(lua): vim.wait(0) does not call loop_poll #39679Justin M. Keyes2026-05-10
| | | | | | | | | | | Problem: Regression from c822a2657c78: `vim.wait(0)` does not call `loop_poll`, so `vim.wait(1)` is needed to "yield" from Lua. Solution: - Ensure that `vim._core.loop_poll()` is always called, even when `time=0`. - Document how to interrupt Lua code (ctrl-c). ref https://github.com/neovim/neovim/issues/6800
* docs: misc #39256Justin M. Keyes2026-04-25
|
* docs: misc #39207Justin M. Keyes2026-04-20
|
* feat(vimfn): use Lua for more excmds/vimfnsJustin M. Keyes2026-04-18
| | | | | | | | | | | Problem: Too much boilerplate needed to use Lua to impl an excmd or f_xx function. Solution: - Add `nlua_call_vimfn` which takes the args typval, executes Lua, and returns a typval. - refactor(excmd): lua impl for :log, :lsp
* perf(vim.fn): call Lua-implemented vim.fn.xx() directly #39166Justin M. Keyes2026-04-17
| | | | | | | | | | | | | | | | | | | | | | | | Problem: - Builtin "Vimscript" functions (f_xx) are mostly implemented in C. Partly that's because there is some boilerplate required to call out to Lua. - Calls to `vim.fn.foo()` always marshall over the Lua <=> Vimscript ("typval") bridge, even if `fn.foo()` is implemented entirely in Lua: ``` Lua => typval => Object => Lua => Object => typval => Lua. ``` Solution: Functions declared in eval.lua with `func_lua` are implemented in entirely in Lua (`_core/vimfn.lua`). - `gen_eval.lua` wires `func_lua` entries to `lua_wrapper`, which handles the typval conversion for Vimscript callers (slow path). - `nlua_call()` detects `func_lua` functions and calls the Lua implementation directly. This eliminates all conversion overhead for Lua callers (fast path). - Validate at build-time that `func`, `func_float`, and `func_lua` are mutually exclusive. - Migrate `hostname()` as a toy example, to show the idea.
* docs: miscJustin M. Keyes2026-04-12
| | | | | | | | Close #38748 Close #38866 Co-authored-by: Mario Loriedo <mario.loriedo@gmail.com> Co-authored-by: Anakin Childerhose <anakin@childerhose.ca>
* docs: api, plugins, ui2Justin M. Keyes2026-03-24
|
* fix(runtime)!: move "tohtml" to pack/dist/opt/ #34557Justin M. Keyes2026-03-23
| | | | | | | | | | | Problem: The "tohtml" plugin is loaded by default. Solution: - Move it to `pack/dist/opt/nvim.tohtml/`, it is an "opt-in" plugin now. - Document guidelines. - Also revert the `plugin/` locations of `spellfile.lua` and `net.lua`. That idea was not worth the trouble, it will be too much re-education for too little gain.
* docs: lsp, options, promptbufJustin M. Keyes2026-02-12
| | | | | | | | | | | | | Close #37630 Close #37682 Close #37762 Close #37785 Co-authored-by: Daniel Schmitt <d.schmitt@lansoftware.de> Co-authored-by: Duane Hilton <duane9@gmail.com> Co-authored-by: NeOzay <colpaert.benoit@gmail.com> Co-authored-by: Yi Ming <ofseed@foxmail.com> Co-authored-by: "Justin M. Keyes" <justinkz@gmail.com>
* docs: misc (#37281)zeertzjq2026-01-12
| | | | | | | Close #37289 Close #37348 Co-authored-by: Marc Jakobi <marc@jakobi.dev> Co-authored-by: Anton Kesy <anton@kesy.de>
* docs: misc (#37280)zeertzjq2026-01-07
| | | | | | | | | | | | | | | | | | | | Close #36806 Close #36812 Close #37003 Close #37016 Close #37038 Close #37039 Close #37157 Close #37185 Close #37213 Co-authored-by: saroj_r <sarojregmi.official@gmail.com> Co-authored-by: Olivia Kinnear <git@superatomic.dev> Co-authored-by: Igor <igorlfs@ufmg.br> Co-authored-by: Justin Roberts <JustinEdwardLeo@gmail.com> Co-authored-by: "Mike J. McGuirk" <mike.j.mcguirk@gmail.com> Co-authored-by: Aymen Hafeez <49293546+aymenhafeez@users.noreply.github.com> Co-authored-by: Peter Cardenas <16930781+PeterCardenas@users.noreply.github.com> Co-authored-by: DrNayak2306 <dhruvgnk.work@gmail.com>
* build: ship "_core/*" as bytecode (built-into Nvim binary)Justin M. Keyes2025-12-30
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: We want to encourage implementing core features in Lua instead of C, but it's clumsy because: - Core Lua code (built into `nvim` so it is available even if VIMRUNTIME is missing/invalid) requires manually updating CMakeLists.txt, or stuffing it into `_editor.lua`. - Core Lua modules are not organized similar to C modules, `_editor.lua` is getting too big. Solution: - Introduce `_core/` where core Lua code can live. All Lua modules added there will automatically be included as bytecode in the `nvim` binary. - Move these core modules into `_core/*`: ``` _defaults.lua _editor.lua _options.lua _system.lua shared.lua ``` TODO: - Move `_extui/ => _core/ui2/`
* feat(events): MarkSet event, aucmd_defer() #35793Nathan Smith2025-12-07
| | | | | | | | | | | | Problem: - Can't subscribe to "mark" events. - Executing events is risky because they can't be deferred. Solution: - Introduce `MarkSet` event. - Introduce `aucmd_defer()`. Helped-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
* docs: getpos, getregion, lspJustin M. Keyes2025-11-15
|
* docs: dev_tools, dev_archJustin M. Keyes2025-10-24
|
* docs: types, news, lua-pluginJustin M. Keyes2025-10-24
| | | | | | - mention "lua_ls", not "luals". https://github.com/neovim/neovim/discussions/36182 Co-authored-by: Maria Solano <majosolano99@gmail.com>
* docs: misc, dev-api-fast, $XDG_STATE_HOME #35138Justin M. Keyes2025-08-17
|
* docs: misc, help tags for neovim.io searches #31428Justin M. Keyes2024-12-03
| | | | | | | | | | Problem: Various keywords are commonly searched-for on https://neovim.io, but don't have help tags. Solution: Add help tags. fix #31327
* docs: dev-arch, focusable windows #30510Justin M. Keyes2024-10-07
- 'statuscolumn' is no longer experimental - add tags for popular searches on neovim.io