| Commit message (Collapse) | Author | Age |
|---|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| | |
This avoids generating khash tables at runtime, and is consistent with
how evalfuncs lookup work.
|
| | |
| |
| | |
related vim-8.2.{4402,4639}
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* feat(api): `group` can be either string or int
This affects the following API functions:
- `vim.api.nvim_create_autocmd`
- `vim.api.nvim_get_autocmds`
- `vim.api.nvim_do_autocmd`
closes #17552
* refactor: add two maps for fast lookups
* fix: delete augroup info from id->name map
When in "stupid_legacy_mode", the value in name->id map would be updated
to `AUGROUP_DELETED`, but the entry would still remain in id->name. This
would create a problem in `augroup_name` function which would return the
name of the augroup instead of `--DELETED--`.
The id->name map is only used for fast loopup in `augroup_name` function
so there's no point in keeping the entry of deleted augroup in it.
Co-authored-by: TJ DeVries <devries.timothyj@gmail.com>
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
marktree.c was originally constructed as a "generic" datatype,
to make the prototyping of its internal logic as simple as possible
and also as the usecases for various kinds of extmarks/decorations was not yet decided.
As a consequence of this, various extra indirections and allocations was
needed to use marktree to implement extmarks (ns/id pairs) and
decorations of different kinds (some which is just a single highlight
id, other an allocated list of virtual text/lines)
This change removes a lot of indirection, by making Marktree specialized
for the usecase. In particular, the namespace id and mark id is stored
directly, instead of the 64-bit global id particular to the Marktree
struct. This removes the two maps needed to convert between global and
per-ns ids.
Also, "small" decorations are stored inline, i.e. those who
doesn't refer to external heap memory anyway. That is highlights (with
priority+flags) are stored inline, while virtual text, which anyway
occurs a lot of heap allocations, do not. (previously a hack was used
to elide heap allocations for highlights with standard prio+flags)
TODO(bfredl): the functionaltest-lua CI version of gcc is having
severe issues with uint16_t bitfields, so splitting up compound
assignments and redundant casts are needed. Clean this up once we switch
to a working compiler version.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows users to define behaviors for arbitrary registers. These
registers can be any character including multibyte characters. This
means that any character may be used as a register and if that register
is not a builtin register, it will defer to a user-defined vimscript
function for behavior.
This is done throw an option called 'userregfun'
The function that 'userregfun' defines is a function that takes 3
arguments:
action - Either set to "put" or "yank"
register - The character representing the register.
content - If the action is "yank" this string contains the content
yanked.
Multibyte registers are still broken for expressions. So while
let @&=xyz
Works as expected,
let @λ=xyz
will still throw a parse error.
|
| |
|
|
| |
Closes #13505
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* refactor: format with uncrustify
* fixup(dundar): fix functions comments
* fixup(dundar): remove space between variable and ++/--
* fixup(dundar): better workaround for macro attributes
This is done to be able to better use uncrustify rules for macros
* fixup(justin): make preprocessors follow neovim style guide
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Note: the reason for removing them is not that there after this refactor
is no use of them, but rather that having them available is an
anti-pattern: they manange an _extra_ heap allocation which has
nothing to do with the functionality of the map itself (khash
manages the real buffers internally). In case there happens to
be a reason to allocate the map structure itself later, this
should be made explicit using xcalloc/xfree calls.
|
| | |
|
| | |
|
| |
|
|
|
| |
the only field of Map(...) was a pointer to a khash_t. make it contain
the struct by value instead.
|
| |
|
|
|
|
|
|
| |
syn_name2id and syn_check_group go brr.
Note: this has impact mostly when using multiple filetypes,
as the old syn_name2id was optimized to return latest
added groups quickly (which will be the latest filetype)
|
| |
|
|
|
|
|
|
|
|
| |
co-author: hlpr98 <hlpr98@gmail.com> (dict2hlattrs function)
orange is sus??
NOVEMBER DAWN
erase the lie that is redraw_later()
|
| | |
|
| |
|
|
| |
one very important thought
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add new "splice" interface for tracking buffer changes at the byte
level. This will later be reused for byte-resolution buffer updates.
(Implementation has been started, but using undocumented "_on_bytes"
option now as interface hasn't been finalized).
Use this interface to improve many edge cases of extmark adjustment.
Changed tests indicate previously incorrect behavior. Adding tests for
more edge cases will be follow-up work (overlaps on_bytes tests)
Don't consider creation/deletion of marks an undoable event by itself.
This behavior was never documented, and imposes complexity for little gain.
Add nvim__buf_add_decoration temporary API for direct access to the new
implementation. This should be refactored into a proper API for
decorations, probably involving a huge dict.
fixes #11598
|
| | |
|
| |
|
|
| |
- README.md: Removed waffle.io because that service is shutting down.
|
| |
|
|
|
|
|
|
|
|
|
| |
- Minimum required libuv is now v1.12
- Because `uv_os_getenv` requires allocating, we must manage a map
(`envmap` in `env.c`) to maintain the old behavior of `os_getenv` .
- free() map-items after removal. khash.h does not make copies of
anything, so even its keys must be memory-managed by the caller.
closes #8398
closes #9267
|
| |
|
|
|
|
|
|
|
| |
Namespaces is a lightweight concept that should be used to group
objects for purposes of bulk operations and introspection. This is
initially used for highlights and virtual text in buffers, and is
planned to also be used for extended marks. There is no plan use them
for privileges or isolation, neither to introduce nanespace-level
options.
|
| |
|
|
|
| |
This allows us to keep track of the source higlight groups,
and not only the final combined highlights.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
also allow handle==0 meaning curbuf/curwin/curtab
|
| |
|
|
| |
header generator.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change implementation to compare sequences of bytes instead of C
strings.
The former implementation would return "false positives" in these cases:
"\0a" and "\0b": C strings are NUL-terminated, so it would compare two
empty strings.
"a" and "ab": If both strings aren't the same length, it would
compare only up to the length of the shorter one.
Fixes #5046.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
API functions exposed via msgpack-rpc now fall into two categories:
- async functions, which are executed as soon as the request is parsed
- sync functions, which are invoked in nvim main loop when processing the
`K_EVENT special key
Only a few functions which can be safely executed in any context are marked as
async.
|
| |
|
|
|
|
| |
We already use wrappers for allocation, the new `xfree` function is the
equivalent for deallocation and provides a way to fully replace the malloc
implementation used by Neovim.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since all API functions now run immediately after a msgpack-rpc request is
parsed by libuv callbacks, a mechanism was added to override this behavior and
allow certain functions to run in Nvim main loop.
The mechanism is simple: Any API function tagged with the FUNC_ATTR_DEFERRED (a
"dummy" attribute only used by msgpack-gen.lua) will be called when Nvim main
loop receives a K_EVENT key.
To implement this mechanism it was necessary some restructuration on the
msgpack-rpc modules, especially in the msgpack-gen.lua script.
|
| |
|
|
|
| |
Create the msgpack_rpc subdirectory and move all modules that deal with
msgpack-rpc to it. Also merge msgpack_rpc.c into msgpack_rpc/helpers.c
|
| |
|
|
|
| |
The new map type uses `String` instances as keys to avoid unnecessary copying to
zero-terminated buffers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introducing the concept of providers: co-processes that talk with the editor
through the remote API and provide implementation for one or more core
services.
The `provider_register` function and it's API wrapper can be used by channels
that want to self-register as a service provider.
Some old builtin vim features will be re-implemented as providers. The
`provider_has_feature` function is used to check if a provider
implementing a certain feature is available(It will be called by the `has`
vimscript function to check for features in a vim-compatible way)
This implements the provider module without exposing any extension points, which
will be done in future commits.
|
| |
|
|
|
| |
To replace `Map(T)`, a new macro `PMap(T)` was defined as `Map(T, ptr_t)` for
writing maps that store pointers with less boilerplate
|
| |
|
|
|
| |
This module will be used to implement remote management of objects through the
API. Object types to be registered must have a `uint64_t` field named 'handle'.
|
| |
|
|
| |
Now the map.c module is used to implement the 'lookup set' for that function
|
| |
|
|
|
|
| |
The map_* declarations and definitions are now created by a macro invocation
with a key type parameter. Also refactored server module to use the updated
version.
|
