| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
Problem: Assert hit related to message kind, which is reset after a
ext_messages UI is forcibly detached, so the assertion is
expectedly false. Assert hit related to message grid variables
after an ext_messages UI attaches while message grid is scrolled.
Solution: Don't check message kind assertion if no ext_messages UI is
attached. Flush message grid when first/last ext_messages UI
attaches/detaches.
|
| |
|
|
|
|
|
| |
Problem: Prompts are emitted as messages events, where cmdline events
are more appropriate. The user input is also emitted as
message events in fast context, so cannot be displayed with
vim.ui_attach().
Solution: Prompt for user input through cmdline prompts.
|
| |
|
| |
Result of `make iwyu` (after some "fixups").
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Option metadata like list of valid values for an option and
option flags are not listed in the `options.lua` file and are instead
manually defined in C, which means option metadata is split between
several places.
Solution: Put metadata such as list of valid values for an option and
option flags in `options.lua`, and autogenerate the corresponding C
variables and enums.
Supersedes #28659
Co-authored-by: glepnir <glephunter@gmail.com>
|
| |
|
|
| |
Add kinds for various commands that output a list, the 'wildmode'
list, and for number prompts.
|
| |
|
|
|
|
|
| |
Problem: No longer able to show prompt messages with vim.ui_attach().
Solution: Do not execute callback in fast context for prompt message
kinds. These events must be safe to show the incoming message
so the event itself serves to indicate that the message
should be shown immediately.
|
| |
|
|
|
|
|
|
| |
Problem: Lua callbacks for "msg_show" events with vim.ui_attach() are
executed when it is not safe.
Solution: Disallow non-fast API calls for "msg_show" event callbacks.
Automatically detach callback after excessive errors.
Make sure fast APIs do not modify Nvim state.
|
| |
|
|
|
| |
This makes it possible to use HLF_ values directly as highlight id:s
and avoids +1 adjustments especially around messages.
|
| |
|
|
|
|
|
| |
Problem: Highlight group id is not propagated to the end of the message call
stack, where ext_messages are emitted.
Solution: Refactor message functions to pass along highlight group id
instead of attr id.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the api_info() output:
:new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val')
...
{'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1}
The `ArrayOf(Integer, 2)` return type didn't break clients when we added
it, which is evidence that clients don't use the `return_type` field,
thus renaming Dictionary => Dict in api_info() is not (in practice)
a breaking change.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The default builtin UI client does not declare its client info. This
reduces discoverability and makes it difficult for plugins to identify
the UI.
Solution:
- Call nvim_set_client_info after attaching, as recommended by `:help dev-ui`.
- Also set the "pid" field.
- Also change `ui_active()` to return a count. Not directly relevant to
this commit, but will be useful later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The ui_rgb_attached function determines if any UI is attached which
supports RGB (truecolor). We determine if the TUI supports RGB via the
'termguicolors' option which is checked at the beginning of this
function. If the TUI does not support RGB ('termguicolors' is unset), we
check to see if any _other_ UI is attached which supports RGB.
Normally, the TUI's "rgb" flag and the 'termguicolors' option are the
same. However, they may differ during startup when the "rgb" flag is set
by tui/tui.c to indicate to the core that the terminal emulator supports
truecolor. The 'termguicolors' option is not actually set until
_defaults.lua runs.
|
| |
|
|
|
|
|
|
| |
Problem: Calling :redraw from vim.ui_attach() callback results in
recursive cmdline/message events.
Solution: Avoid recursiveness where possible and replace global "call_buf"
with separate, temporary buffers for each event so that when a Lua
callback for one event fires another event, that does not result
in invalid memory access.
|
| | |
|
| |
|
|
|
|
| |
Problem: Enabling ext_messages claims to set 'cmdheight' to zero, but
only does so for the current tabpage.
Solution: Set stored 'cmdheight' value to zero for all tabpages.
|
| |
|
|
|
|
| |
Problem: Updating internalized UI capabilities is postponed until a
remote UI attaches.
Solution: Always update active UI widgets in ui_refresh().
|
| |
|
|
| |
Remove remaining code that prevents non-zero 'cmdheight' with ext_messages.
|
| |
|
|
|
|
| |
Also close Nvim instance before removing log file, otherwise the Nvim
instance will still write to the log file.
Also adjust log level in libuv_process_spawn(). Ref #27660
|
| |
|
|
|
|
|
|
| |
Problem: Cursor line is unconcealed when pressing 'r' in Normal mode
when 'concealcursor' contains 'n' but not 'i'.
Solution: Don't check conceal when pressing 'r' in Normal mode.
Vim doesn't have this problem because it doesn't call redrawWinline() in
conceal_check_cursor_line() and instead sets a global variable.
|
| |
|
|
|
|
|
|
| |
Just some basic spring cleaning.
In the distant past, not all UI:s where remote UI:s. They still aren't,
but both of the "UI" and "UIData" structs are now only for remote UI:s.
Thus join them as "RemoteUI".
|
| |
|
|
|
|
|
|
|
|
|
|
| |
and for return value of nlua_exec/nlua_call_ref, as this uses
the same family of functions.
NB: the handling of luaref:s is a bit of a mess.
add api_luarefs_free_XX functions as a stop-gap as refactoring
luarefs is a can of worms for another PR:s.
as a minor feature/bug-fix, nvim_buf_call and nvim_win_call now preserves
arbitrary return values.
|
| |
|
| |
Follows up on rename of `FloatConfig` to `WinConfig` in #27397.
|
| | |
|
| |
|
|
|
| |
In the context a String inside an Object/Dictionary etc is consumed,
it is considered to be read-only.
|
| | |
|
| |
|
|
|
|
| |
When an embedded Nvim instance changes its current directory a "chdir"
UI event is emitted. Attached UIs can use this information however they
wish. In the TUI it is used to synchronize the cwd of the TUI process
with the cwd of the embedded Nvim process.
|
| |
|
|
|
|
| |
Remove `export` pramgas from defs headers as it causes IWYU to believe
that the definitions from the defs headers comes from main header, which
is not what we really want.
|
| |
|
|
|
|
|
|
|
|
|
| |
grid_put_linebuf() used grid_clear() internally to handle clearing the
left part of a rightleft line. By reimplementing that internally, we
can instead use grid_put_linebuf() as the implementation of
grid_clear(), which in the end is a net reduction of code as grid_fill()
is used for nothing else.
win_draw_end: Implement "draw_margin" on a per-row basis which closer reflects how
terminals work. Also use the magic mirror for 'rightleft'
|
| |
|
|
| |
A struct can be anonymous if only its typedef is used.
|
| |
|
|
|
| |
Specifically, specify that each initialization should be done on a
separate line.
|
| | |
|
| |
|
|
|
|
| |
Problem: Many places in the code use `findoption()` to access an option using its name, even if the option index is available. This is very slow because it requires looping through the options array over and over.
Solution: Use option index instead of name wherever possible. Also introduce an `OptIndex` enum which contains the index for every option as enum constants, this eliminates the need to pass static option names as strings.
|
| |
|
|
|
|
|
|
|
|
| |
If the color scheme is changed in a startup script, nvim used to send
multiple default_colors_set events, one for the default color scheme
and one for the user's chosen color scheme. This would cause flicker in
some UI:s. Throttle this event until we actually start drawing on the
screen.
fixes #26372
|
| |
|
| |
Discovered using __sanitizer_print_memory_profile().
|
| |
|
| |
A varargs functions can never be inlined, so a macro is faster.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
|
| | |
|
| |
|
|
|
|
| |
- Move vimoption_T to option.h
- option_defs.h is for option-related types
- option_vars.h corresponds to Vim's option.h
- option_defs.h and option_vars.h don't include each other
|
| |
|
|
|
| |
long is 32-bits even on 64-bit windows which makes the type suboptimal
for a codebase meant to be cross-platform.
|
| |
|
|
|
| |
problem: there are too many different functions in message.c
solution: fold some of the functions into themselves
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This involves two redesigns of the map.c implementations:
1. Change of macro style and code organization
The old khash.h and map.c implementation used huge #define blocks with a
lot of backslash line continuations.
This instead uses the "implementation file" .c.h pattern. Such a file is
meant to be included multiple times, with different macros set prior to
inclusion as parameters. we already use this pattern e.g. for
eval/typval_encode.c.h to implement different typval encoders reusing a
similar structure.
We can structure this code into two parts. one that only depends on key
type and is enough to implement sets, and one which depends on both key
and value to implement maps (as a wrapper around sets, with an added
value[] array)
2. Separate the main hash buckets from the key / value arrays
Change the hack buckets to only contain an index into separate key /
value arrays
This is a common pattern in modern, state of the art hashmap
implementations. Even though this leads to one more allocated array, it
is this often is a net reduction of memory consumption. Consider
key+value consuming at least 12 bytes per pair. On average, we will have
twice as many buckets per item.
Thus old implementation:
2*12 = 24 bytes per item
New implementation
1*12 + 2*4 = 20 bytes per item
And the difference gets bigger with larger items.
One might think we have pulled a fast one here, as wouldn't the average size of
the new key/value arrays be 1.5 slots per items due to amortized grows?
But remember, these arrays are fully dense, and thus the accessed memory,
measured in _cache lines_, the unit which actually matters, will be the
fully used memory but just rounded up to the nearest cache line
boundary.
This has some other interesting properties, such as an insert-only
set/map will be fully ordered by insert only. Preserving this ordering
in face of deletions is more tricky tho. As we currently don't use
ordered maps, the "delete" operation maintains compactness of the item
arrays in the simplest way by breaking the ordering. It would be
possible to implement an order-preserving delete although at some cost,
like allowing the items array to become non-dense until the next rehash.
Finally, in face of these two major changes, all code used in khash.h
has been integrated into map.c and friends. Given the heavy edits it
makes no sense to "layer" the code into a vendored and a wrapper part.
Rather, the layered cake follows the specialization depth: code shared
for all maps, code specialized to a key type (and its equivalence
relation), and finally code specialized to value+key type.
|
| |
|
|
|
|
|
|
| |
Removes the `getoption_T` struct and also introduces the `OptVal` struct
to unify the methods of getting/setting different option value types.
This is the first of many PRs to reduce code duplication in the Vim
option code as well as to make options easier to maintain. It also
increases the flexibility and extensibility of options. Which opens the
door for things like Array and Dictionary options.
|
| | |
|
| |
|
|
| |
Adds new API helper macros `CSTR_AS_OBJ()`, `STATIC_CSTR_AS_OBJ()`, and `STATIC_CSTR_TO_OBJ()`, which cleans up a lot of the current code. These macros will also be used extensively in the upcoming option refactor PRs because then API Objects will be used to get/set options. This PR also modifies pre-existing code to use old API helper macros like `CSTR_TO_OBJ()` to make them cleaner.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reduces the total number of khash_t instantiations from 22 to 8.
Make the khash internal functions take the size of values as a runtime
parameter. This is abstracted with typesafe Map containers which
are still specialized for both key, value type.
Introduce `Set(key)` type for when there is no value.
Refactor shada.c to use Map/Set instead of khash directly.
This requires `map_ref` operation to be more flexible.
Return pointers to both key and value, plus an indicator for new_item.
As a bonus, `map_key` is now redundant.
Instead of Map(cstr_t, FileMarks), use a pointer map as the FileMarks struct is
humongous.
Make `event_strings` actually work like an intern pool instead of wtf it
was doing before.
|
