| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem:
'isident' decides how env var names are parsed, which is more
"confusing" than "useful":
- Changing 'isident' (for 'define' or "\i") can break `$NAME` expansion.
- Its default byte ranges let multibyte names work on Windows (`$aあ`)
but not Unix (`$é`).
Solution:
Ignore 'isident' when parsing env var names.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
'isident' is checked per byte (inherited from Vim), so a name can end
in the middle of a multibyte char: with "192-255", `$é` (C3 A9) looks
up "\xC3".
- Unix: expands an env var named "\xC3", plus a stray "\xA9".
- Windows: uv_os_getenv() rejects the name (invalid UTF-8), and
os_getenv() logs an error.
`$VAR` in expressions (get_env_len()) and cmdline completion have the
same scan.
Solution:
`vim_isIDp()`: a multibyte char is an identifier char only if it is valid
UTF-8 and 'isident' has all its bytes. Use it in expand_env_esc(),
get_env_len() and cmdline completion. Names whose bytes are all in
'isident' still work, e.g. `$aあ` with the Windows default.
Assert UV_EINVAL in os_getenv() and os_getenv_buf() (like
os_env_exists() and os_setenv() already do): Nvim no longer passes
invalid UTF-8.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The magic globals `it`, `describe`, etc., are more trouble than they are
worth.
- Hooking into `after_each` requires `getfenv()` hacks.
- They confuse luals/emmylua, because the top-level `.luarc.json` isn't
merged with `test/.luarc.json` (apparently a luals limitation?)
- They totally defeat discoverability because the user just has to
"know" about the various magic symbols.
So they harm DX, which means they serve no purpose at all.
Solution:
- Expose the test API from `testutil`, so tests can call `t.it()`,
`t.describe()`, etc., in the conventional way.
- Drop `getfenv()` hacks.
- Drop the `setfenv()` injection in `load_chunk`.
- Drop `test/_meta.lua`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
1. `vim_getenv` is followed by `TO_SLASH` when getting
path-related variables.
2. cmd exits when launched with forward slash.
Solution:
1. try calling `TO_SLASH` in `vim_getenv`.
2. pass fullpath via `lpApplicationName`, only include `cmd.exe`
in cmdline.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.
Closes https://github.com/neovim/neovim/issues/27004.
|
| | |
|
| |
|
|
| |
Work on https://github.com/neovim/neovim/issues/27004.
|
| | |
|
| | |
|
| |
|
| |
Discovered using --shuffle argument of busted.
|
|
|
Problem:
Subdirectories like "visual", "insert", "normal" encourage people to
separate *related* tests for no good reason. Typically the _mode_ is
not the relevant topic of a test (and when it is, _then_ create
an appropriate describe() or it()).
Solution:
- Delete the various `test/functional/<mode>/` subdirectories, move
their tests to more meaningful topics.
- Rename `…/normal/` to `…/editor/`.
- Move or merge `…/visual/*` and `…/insert/*` tests into here where
appropriate.
- Rename `…/eval/` to `…/vimscript/`.
- Move `…/viml/*` into here also.
* test(reorg): insert/* => editor/mode_insert_spec.lua
* test(reorg): cmdline/* => editor/mode_cmdline_spec.lua
* test(reorg): eval core tests => eval_spec.lua
|
