| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
This one generates a runtime/ file instead of a source file.
But otherwise it works the same like all other generators.
It has the same prerequisites (shared and mpack modules, etc), and,
importantly, it uses results from the source generators.
The odd location makes it easy to overlook when refactoring generators
(like I did last time, lol)
|
|
|
|
|
| |
problem: the api of vim.mpack is not compatible with a system provided mpack
solution: don't require 'mpack' directly from the system path
|
| |
|
|
|
| |
Also don't highlight :def as vimCommand.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Build is not reproducible, because generated source files (.c/.h/) are not
deterministic, mostly because Lua pairs() is unordered by design (for security).
https://github.com/LuaJIT/LuaJIT/issues/626#issuecomment-707005671
https://www.lua.org/manual/5.1/manual.html#pdf-next
> The order in which the indices are enumerated is not specified [...]
>
>> The hardening of the VM deliberately randomizes string hashes. This in
>> turn randomizes the iteration order of tables with string keys.
Solution:
- Update the code generation scripts to be deterministic.
- That is only a partial solution: the exported function
(funcs_metadata.generated.h) and ui event
(ui_events_metadata.generated.h) metadata have some mpack'ed
tables, which are not serialized deterministically.
- As a workaround, introduce `PRG_GEN_LUA` cmake setting, so you can
inject a modified build of luajit (with LUAJIT_SECURITY_PRN=0)
that preserves table order.
- Longer-term we should change the mpack'ed data structure so it no
longer uses tables keyed by strings.
Closes #20124
Co-Authored-By: dundargoc <gocdundar@gmail.com>
Co-Authored-By: Arnout Engelen <arnout@bzzt.net>
|
|
|
|
| |
Update runtime files
https://github.com/vim/vim/commit/8c1b8cb2e0b52d0853f85c2096a2f22dbc57a788
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's special cased by the vimSubst syntax group, and isn't present in Vim's
vimCommand group.
For example, this fixes `call s:Foo()` highlighting `:` as Error in Nvim, as the
`s` is parsed as vimCommand rather than as vimUserFunc since
`contains=vimCommand` was added to vimUserFunc (and vimFunc) in a rt update.
Interestingly, `g:`, `l:`, etc. have the same issues due to :global, :list, etc.
Vim also has that problem, so it should ideally be fixed upstream.
We could also omit g[lobal] from vimCommand and rely on vimGlobal instead, but
it doesn't work in some cases, like when there's a `:` before the command. Also,
Vim matches only `g` in vimCommand for some reason, which doesn't produce any
highlight for `:global/foo/bar` (with Nvim you at least get some highlights on
the `global` bit despite the leading `:`).
Also, remove special handling of :py3 in syntax/vim.vim, as the generator seems
to have no problems finding it.
|
| |
|
|
|
|
| |
"b" flag is required to read binary files on Windows.
https://www.lua.org/pil/21.2.2.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Ex command info contains confusing information.
Solution: When using the NOTADR flag use ADDR_OTHER for the address type.
Cleanup code using NOTADR. Check for errors in
create_cmdidxs.vim. Adjust Makefile to see the errors.
https://github.com/vim/vim/commit/b731689e85b4153af7edc8f0a6b9f99d36d8b011
Use Lua's "assert()" to make an invalid command definition
a compilation error.
Misc changes:
Remove 'RESTRICT' flag.
Neovim does not support "restricted" mode
since commit 7777532cebcfa9abc5ab2c7beae77f386feed3ca.
TODO:
Do not generate files before Lua assertions
so that CMake always runs the generator script
if the previous build has an invalid command definition.
|
|
|
|
|
|
|
|
|
|
| |
Comparing `vimCommand` from Vim's runtime/syntax/vim.vim, one can see
that "augroup" and similar commands are conspicuously missing. They are
handled specially (`vimAugroupKey`, `vimAutoCmd`).
Excluding them from the generated `vimCommand` keyword list, fixes their
highlighting.
closes #9327
|
| |
|
|
|
|
| |
make api functions highlighted as builtins in vim.vim
|
|
|
|
|
|
| |
Removes all kinds of problems with sorting, provides a ready-to-use function
list representation for genvimvim.lua, does not require specifying function name
twice (VimL function name (string) + f_ function name).
|
|
|
|
| |
git-log-pretty-since.sh: fix bug
|
| |
|
|
|
|
| |
Fixes https://github.com/neovim/neovim/issues/5060.
|
|
|
|
| |
Excluded options (compatible, edcompatible and ttyfast) are listed in
vimOnlyOption group.
|
|
|
|
| |
Note: list was copied from master (7a6bf3f418c5ad94ac2ac71f21275a87d08e87b9).
I did not add more events there.
|
|
|