Before calling "attach" a screen object is just a dummy container for
(row, col) values whose purpose is to be sent as part of the "attach"
function call anyway.
Just create the screen in an attached state directly. Keep the complete
(row, col, options) config together. It is still completely valid to
later detach and re-attach as needed, including to another session.
Problem: with a single `context.options` there is no way for user to
force which scope (local, global, both) is being temporarily set and
later restored.
Solution: replace single `options` context with `bo`, `go`, `wo`, and
`o`. Naming and implementation follows how options can be set directly
with `vim.*` (like `vim.bo`, etc.).
Options are set for possible target `win` or `buf` context.
Problem: `vim._with()` has many different use cases which are not
covered with tests.
Solution: cover with tests. Some (many) test cases are intentionally
marked as "pending" because they cover cases which don't work as
expected at the moment (and fixing them requires specific knowledge of
C codebase). Use them as a reference for future fixes.
Also some of "can be nested" tests currently might pass only because
the tested context doesn't work.
It's a function to perform operations in their own sealed context,
similar to pythons `with`. This helps ease operations where you need to
perform an operation in a specific context, and then restore the
context.
Marked as private for now as it's not ready for public use. The current
plan is to start using this internally so we can discover and fix any
problems. Once this is ready to be exposed it will be renamed to
`vim.with`.
Usage:
```lua
local ret = vim._with({context = val}, function()
return "hello"
end)
```
, where `context` is any combination of:
- `buf`
- `emsg_silent`
- `hide`
- `horizontal`
- `keepalt`
- `keepjumps`
- `keepmarks`
- `keeppatterns`
- `lockmarks`
- `noautocmd`
- `options`
- `sandbox`
- `silent`
- `unsilent`
- `win`
(except for `win` and `buf` which can't be used at the same time). This
list will most likely be expanded in the future.
Work on https://github.com/neovim/neovim/issues/19832.
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
