| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: some API functions that check textlock (usually those that can change
curwin or curbuf) can break the cmdwin.
Solution: make FUNC_API_CHECK_TEXTLOCK call text_locked() instead, which already
checks for textlock, cmdwin and `<expr>` status.
Add FUNC_API_TEXTLOCK_ALLOW_CMDWIN to allow such functions to be usable in the
cmdwin if they can work properly there; the opt-in nature of this attribute
should hopefully help mitigate future bugs.
Also fix a regression in #22634 that made functions checking textlock usable in
`<expr>` mappings, and rename FUNC_API_CHECK_TEXTLOCK to FUNC_API_TEXTLOCK.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
problem: can we have Serde?
solution: we have Serde at home
This by itself is just a change of notation, that could be quickly
merged to avoid messy merge conflicts, but upcoming changes are planned:
- keysets no longer need to be defined in one single file. `keysets.h` is
just the initial automatic conversion of the previous `keysets.lua`.
keysets just used in a single api/{scope}.h can be moved to that file, later on.
- Typed dicts will have more specific types than Object. this will
enable most of the existing manual typechecking boilerplate to be eliminated.
We will need some annotation for missing value, i e a boolean will
need to be represented as a TriState (none/false/true) in some cases.
- Eventually: optional parameters in form of a `Dict opts` final
parameter will get added in some form to metadata. this will require
a discussion/desicion about type forward compatibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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)
|
|
|
|
| |
Lua makes (or reuses) an internal copy of strings, so we can safely push
buf pointers onto the stack.
|
| |
|
| |
|
|
|
|
|
|
| |
Closes https://github.com/neovim/neovim/issues/15063
Allows using Neovim core functions using LuaJIT FFI on Windows.
|
|
|
|
|
|
|
| |
Do not copy a lot of lua strings (dict keys) to just strequal() them
Just compare them directly to a dedicated hash function.
feat(generators): HASHY McHASHFACE
|
| |
|
|
|
|
| |
[skip.lint]
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Initially we will use this for the popupmenu, floating windows will
follow soon
NB: writedelay + compositor is weird, we need more flexible
redraw introspection.
|
| |
|
|
|