| Commit message (Collapse) | Author | Age |
... | |
|\ \ \
| |_|/
|/| |
| | |
| | | |
closes #6168
ref #5686
|
|/ /
| |
| |
| |
| | |
Co-authored-by: Björn Linse <bjorn.linse@gmail.com>
Updated docs and tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
add cchar_to_string
|
| | |
|
|/ |
|
|
|
|
|
| |
- test all properties
- test failure modes
|
|\ |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
| |
...in order to retrieve highlights.
Added test/functional/api/highlight_spec.lua
HL_NORMAL is not really a good name, since it's more like an empty attribute than the normal's one.
If one pays attention, syn_cterm_attr2entry is never called with attr=0 because it's always special cased before.
I suggest in subsequent PRs we remove the ATTR_OFF and just insert an EMPTY ATTR/RESET_ATTR/UNINITIALIZED for id 0.
|
| |
|
|
|
|
| |
References #7178
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This fixes memory leak reported by ASAN. This also somehow fixes test40, though
I have no idea why except that that test yields memory leak report.
|
|\ |
|
| | |
|
| |
| |
| |
| | |
Closes #6937 "nvim_get_keymap output is unreliable"
|
| |
| |
| |
| |
| | |
This was already removed in 3baba1e7bc66, except the documentation and
CPO_VI entry. find_term_bykeys() is irrelevant to Nvim.
|
| | |
|
| |\
| | |
| | | |
lua: Add paths from &runtimepath to package.path and package.cpath
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It used to
1. Always omit last component in runtimepath.
2. Always omit trailing empty item and leave uninitialized memory in place of
it.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: when processing cycle such as
:for pat in [' \ze*', ' \zs*']
: try
: let l = matchlist('x x', pat)
: $put ='E888 NOT detected for ' . pat
: catch
: $put ='E888 detected for ' . pat
: endtry
:endfor
`:let l = …` throwing an error causes this error to be caught after
color_cmdline attempts to get callback for highlighting next line (the one with
`$put = 'E888 NOT…`). Saving/restoring state prevents this from happening.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: When creating a bufref, then using :bwipe and :new it might get
the same memory and bufref_valid() returns true.
Solution: Add br_fnum to check the buffer number didn't change.
https://github.com/vim/vim/commit/45e5fd135da5710f24a1acc142692f120f8b0b78
|
| | |
|
|/
|
|
|
|
|
| |
* Add api function get keymap
nvim_get_keymap(mode)
nvim_buf_get_keymap(buffer, mode)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Introduce multiqueue_process_priority() to process only events at or
above a certain priority.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| |
| |
| |
| |
| |
| | |
- Work with a bool[] array parallel to the UIWidget enum.
- Rename some functions.
- Documentation.
|