| Age | Commit message (Collapse) | Author | Files |
|---|
|
Problem: The "Scanning:" completion, bufwrite, and indent (there may be
more) messages which indicate progress can use the "progress" kind
for their msg_show event. Indent message does not have a kind.
Solution: Emit these messages with the "progress" kind. Set the message id
to the replaced kind so that a UI knows to replace it (and to provide
a migration path in case a UI was distinguishing these messages for
whatever reason).
|
|
Replace the busted-based Lua test runner with a repo-local harness.
The new harness runs spec files directly under `nvim -ll`, ships its own
reporter and lightweight `luassert` shim, and keeps the helper/preload
flow used by the functional and unit test suites.
Keep the file boundary model shallow and busted-like by restoring `_G`,
`package.loaded`, `package.preload`, `arg`, and the process environment
between files, without carrying extra reset APIs or custom assertion
machinery.
Update the build and test entrypoints to use the new runner, add
black-box coverage for the harness itself, and drop the bundled
busted/luacheck dependency path.
AI-assisted: Codex
|
|
If the final screen state does match but an intermediate screen state
doesn't, show the first intermediate state.
|
|
Problem: converting a split to a floatwin may not remove the last statusline
when needed. (e.g: 'ls' is 1)
Solution: call last_status/win_comp_pos in win_new_float, after win_remove.
Also fix float_pos formatting for screen snapshots so it doesn't give a nil
error for external windows.
Not an issue from this PR.
|
|
Problem: Unable to tell whether a msg_show event is emitted as a result
a command typed on the cmdline (UI may want to represent these
differently from other messages).
Solution: Add trigger parameter that is set to "typed_cmd" for
a message emitted due to an interactively typed command.
Possible extensions are mapping/timer/event but it's hard to
imagine a UI distinguishing those so not added here.
|
|
After #27620 flags.timeout is no longer used as the minimal timeout for
"intermediate", but the default minimal timeout shouldn't be too small.
|
|
|
|
Problem:
Currently it's only possible to test a single string match in the
screen, which makes it hard match multiple strings in the screen to
avoid having to compare the whole screen state.
It's also not possible to test if a string match is not found in the screen.
Solution:
Support an array of `any` matches and also support `none`, which does a
negative comparision.
|
|
Problem:
Nvim does not have a core concept for indicating "progress" of
long-running tasks. The LspProgress event is specific to LSP.
Solution:
- `nvim_echo` can emit `kind="progress"` messages.
- Emits a `Progress` event.
- Includes new fields (id, status, percent) in the `msg_show` ui-event.
- The UI is expected to overwrite any message having the same id.
- Messages have a globally unique ID.
- `nvim_echo` returns the message ID.
- `nvim_echo(… {id=…})` updates existing messages.
Example:
local grp = vim.api.nvim_create_augroup("Msg", {clear = true})
vim.api.nvim_create_autocmd('Progress', {
pattern={"term"},
group = grp,
callback = function(ev)
print(string.format('event fired: %s', vim.inspect(ev))..'\n')
end
})
-- require('vim._extui').enable({enable=true, msg={target='msg', timeout=1000}})
vim.api.nvim_echo({{'searching'}}, true, {kind='progress', percent=80, status='running', title="terminal(ripgrep)"})
local id = vim.api.nvim_echo({{'searching'}}, true, {kind='progress', status='running', percent=10, title="terminal(ripgrep)"})
vim.api.nvim_echo({}, true, {id = id, kind='progress', percent=20, status = 'running', title='find tests'})
vim.api.nvim_echo({}, true, {id = id, kind='progress', status='running', percent=70})
vim.api.nvim_echo({{'complete'}}, true, {id = id, kind='progress', status='success', percent=100, title="find tests"})
Followups:
- Integrate with 'statusline' by listening to the Progress autocmd event.
- Integrate progress ui-event with `vim._extui`.
|
|
This function allows the Nvim core to write arbitrary data to a TTY
connected to a UI's stdout.
|
|
|
|
Problem: get_default_attr_ids() is used to get and change a subset of
the current highlight definitions in {fold,popupmenu}_spec.lua,
for which we have add_extra_attr_ids().
Solution: Use global highlight definitions and use add_extra_attr_ids to
replace.
|
|
Problem: Hardcoded highlight IDs for ext_messages/cmdline output need
to be adjusted everytime a builtin highlight group is added.
Solution: Store a global map of default highlights through nvim_get_hl()
and fetch missing (custom) highlight groups through synIDattr().
Use more compact formatting for screen:expect().
|
|
Problem: Unable to tell whether msg_history_show event is emitted for a
:messages or g< command.
Solution: Add "prev_cmd" argument that is set to true for g<.
|
|
Problem: ext_messages is implemented to mimic the message grid
implementation w.r.t. scrolling messages, clearing scrolled
messages, hit-enter-prompts and replacing a previous message.
Meanwhile, an ext_messages UI may not be implemented in a way
where these events are wanted. Moreover, correctness of these
events even assuming a "scrolled message" implementation
depends on fragile "currently visible messages" global state,
which already isn't correct after a previous message was
supposed to have been overwritten (because that should not only
happen when `msg_scroll == false`).
Solution: - No longer attempt to keep track of the currently visible
messages: remove the `msg_ext(_history)_visible` variables.
UIs may remove messages pre-emptively (timer based), or never
show messages that don't fit a certain area in the first place.
- No longer emit the `msg(_history)_clear` events to clear
"scrolled" messages. This opens up the `msg_clear` event to
be emitted when messages should actually be cleared (e.g.
when the screen is cleared). May also be useful to emit before
the first message in an event loop cycle as a hint to the UI
that it is a new batch of messages (vim._extui currently
schedules an event to determine that).
- Set `replace_last` explicitly at the few callsites that want
this to be set to true to replace an incomplete status message.
- Don't store a "keep" message to be re-emitted.
|
|
Problem: The "append" parameter added in abb40ece is missing from
history entries, resulting in different message formatting
for "g<".
Solution: Add "append" field to message history entries.
Co-authored-by: phanium <91544758+phanen@users.noreply.github.com>
|
|
Add '^' and '$' around the pattern. This makes it less likely to make
mistakes of when writing tests with {MATCH:}, as most such tests have
text before and after {MATCH:}.
|
|
Problem: Consecutive "msg_show" events stemming from an `:echon`
command are supposed to be appended without a newline, this
information is not encoded in the "msg_show" event.
Solution: Add an "append" parameter to the "msg_show" event that is set
to true to indicate the message should not start on a new line.
Considered alternative: Emit a newline for the common case instead at the
start of a new message. That way UIs can more closely follow the logic
as it is implemented for the message grid currently. This would be a
breaking change. The "append" parameter seems OK.
|
|
In a floating window grid, "wrap" flag should not
be set when vertical borders are used, as the the wrapped
text will be broken up by border chars.
fixes #33719
|
|
Provide compositor information, like composition index and absolute
position.
|
|
|
|
Problem:
Indenting text is a common task in plugins/scripts for
presentation/formatting, yet vim has no way of doing it (especially
"dedent", and especially non-buffer text).
Solution:
Introduce `vim.text.indent()`. It sets the *exact* indentation because
that's a more difficult (and thus more useful) task than merely
"increasing the current indent" (which is somewhat easy with a `gsub()`
one-liner).
|
|
|
|
Problem:
cmdline abort state may be reset when intermediate states are received.
Solution:
Reset after `self:_wait()`.
|
|
Also remove a hack in the multigrid "with winbar" test.
|
|
Pass along whether message in msg_show event is added to the internal
:messages history.
|
|
Problem: Unable to tell what highlight the prompt part of a
cmdline_show event should have, and whether cmdline_hide was
emitted after aborting.
Solution: Add additional arguments hl_id to cmdline_show, and abort to
cmdline_hide.
|
|
When a terminal application running inside the terminal emulator sets
the cursor shape or blink status of the cursor, update the cursor in the
parent terminal to match.
This removes the "virtual cursor" that has been in use by the terminal
emulator since the beginning. The original rationale for using the
virtual cursor was to avoid having to support additional UI methods to
change the cursor color for other (non-TUI) UIs, instead relying on the
TermCursor and TermCursorNC highlight groups.
The TermCursor highlight group is now used in the default 'guicursor'
value, which has a new entry for Terminal mode. However, the
TermCursorNC highlight group is no longer supported: since terminal
windows now use the real cursor, when the window is not focused there is
no cursor displayed in the window at all, so there is nothing to
highlight. Users can still use the StatusLineTermNC highlight group to
differentiate non-focused terminal windows.
BREAKING CHANGE: The TermCursorNC highlight group is no longer supported.
|
|
Before:
screen:expect({ | screen:expect({
grid = [[ | grid = [[
{10:>!}a | | line ^1 |
{7: }b | | {1:~ }|*4
{10:>>}c | | ]], messages={ {
{7: }^ | | content = { { "\ntest\n[O]k: ", 6, 11 } },
{1:~ }|*9 | kind = "confirm"
| | } }
]] | })
})
After:
screen:expect([[ | screen:expect({
{10:>!}a | | grid = [[
{7: }b | | line ^1 |
{10:>>}c | | {1:~ }|*4
{7: }^ | | ]],
{1:~ }|*9 | messages = { {
| | content = { { "\ntest\n[O]k: ", 6, 11 } },
]]) | kind = "confirm"
| } },
| })
|
|
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: Ext_messages chunks only contain the highlight attr id, which
is not very useful for vim.ui_attach() consumers.
Solotion: Add highlight group id to message chunks, which can easily be
used to highlight text in the TUI through nvim_buf_set_extmark():
hl_group = synIDattr(id, "name").
|
|
|
|
|
|
This makes screen:snapshot_util() generate code with the new
screen:add_extra_attr_ids { ... } pattern. For convenience,
the old-style configuration is still detected and supported (until
all tests have been refactored, which is my goal for the 0.11 cycle)
Remove the last traces of the "ignore" attr anti-pattern. This code
is no longer functional, it is just "ignore" argument being passed around
like a hot potato at this point.
|
|
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.
|
|
We start at 100 so we can make the base set larger if needed. (It might need to
grow/shrink as a result of adopting the new default color scheme as the
default for tests)
Usage best illustrataded by example.
Improving the workflow for making new tests with `screen:snapshot_util()` will
be a follow up.
|
|
Problem: using win_viewport for implementing smooth scrolling in an external
UI might run into problems when winbar or borders is used, as there is
no indication that the entire grid is not used for scrolled buffer text.
Solution: add `win_viewport_margins` event.
|
|
Problem: Screen snapshot is printed in a way that still needs to be formatted.
Solution: Adjust the snapshot formatting (indentation, braces).
|
|
|
|
This is the first installment of a multi-PR series significantly
refactoring how highlights are being specified.
The end goal is to have a base set of 20 ish most common highlights,
and then specific files only need to add more groups to that as needed.
As a complicating factor, we also want to migrate to the new default
color scheme eventually. But by sharing a base set, that future PR
will hopefully be a lot smaller since a lot of tests will be migrated
just simply by updating the base set in place.
As a first step, fix the anti-pattern than Screen defaults to ignoring
highlights. Highlights are integral part of the screen state, not
something "extra" which we only test "sometimes". For now, we still
allow opt-out via the intentionally ugly
screen._default_attr_ids = nil
The end goal is to get rid of all of these eventually (which will be
easier as part of the color scheme migration)
|
|
With "intermediate" flag, only using minimal timeout is too short and
may lead to failures.
Also remove the fallback timeout in screen:expect_unchanged(), as having
a different fallback timeout than screen:expect() is confusing.
|
|
Extmarks can contain URLs which can then be drawn in any supporting UI.
In the TUI, for example, URLs are "drawn" by emitting the OSC 8 control
sequence to the TTY. On terminals which support the OSC 8 sequence this
will create clickable hyperlinks.
URLs are treated as inline highlights in the decoration subsystem, so
are included in the `DecorSignHighlight` structure. However, unlike
other inline highlights they use allocated memory which must be freed,
so they set the `ext` flag in `DecorInline` so that their lifetimes are
managed along with other allocated memory like virtual text.
The decoration subsystem then adds the URLs as a new highlight
attribute. The highlight subsystem maintains a set of unique URLs to
avoid duplicating allocations for the same string. To attach a URL to an
existing highlight attribute we call `hl_add_url` which finds the URL in
the set (allocating and adding it if it does not exist) and sets the
`url` highlight attribute to the index of the URL in the set (using an
index helps keep the size of the `HlAttrs` struct small).
This has the potential to lead to an increase in highlight attributes
if a URL is used over a range that contains many different highlight
attributes, because now each existing attribute must be combined with
the URL. In practice, however, URLs typically span a range containing a
single highlight (e.g. link text in Markdown), so this is likely just a
pathological edge case.
When a new highlight attribute is defined with a URL it is copied to all
attached UIs with the `hl_attr_define` UI event. The TUI manages its own
set of URLs (just like the highlight subsystem) to minimize allocations.
The TUI keeps track of which URL is "active" for the cell it is
printing. If no URL is active and a cell containing a URL is printed,
the opening OSC 8 sequence is emitted and that URL becomes the actively
tracked URL. If the cursor is moved while in the middle of a URL span,
we emit the terminating OSC sequence to prevent the hyperlink from
spanning multiple lines.
This does not support nested hyperlinks, but that is a rare (and,
frankly, bizarre) use case. If a valid use case for nested hyperlinks
ever presents itself we can address that issue then.
|
|
Very rough buts resolves most diagnostic errors and should provide
some useful hovers.
|
|
When an embedded Nvim instance changes its current directory a "chdir"
UI event is emitted. Attached UIs can use this information however they
wish. In the TUI it is used to synchronize the cwd of the TUI process
with the cwd of the embedded Nvim process.
|
|
|
|
|
|
|
|
|
