tracy fibers describe execution on one native thread, but tokio tasks are
owned by the scheduler and can move across runtime threads after an await.
that made the old serial command instrumentation invalid.
also we add a profiling only scroll metric for what we actually need to
compare for the follow up patch targeting batch wheel scrolls.
error
Instrumentation failure: Fiber execution stopped on a thread which is not executing a fiber.
after some debugging, stable and nightly currently encode buffer writes
differently meaning that stable has something like:
{
data = ...,
id = "bufwrite",
percent = 0,
source = "nvim",
status = "running",
text = { '[file-path]' },
title = ""
}
against the current nightly
{
data = ...,
id = 'nvim.bufwrite "[file-path]"',
source = "nvim",
status = "running",
text = { '"[file-path]" ' },
title = ""
}
so missing percentages now finish the active progress item instead of starting
a 0% animation, while determinate progress continues to animate by id.
for example now we will show the progress bar only when a neovim producer
(a plugin or any process event that uses nvim_echo) sends a real determinate percent.
vim.api.nvim_echo({ { "my-progress-bar." } }, true, {
kind = "progress",
id = "neovide-task",
source = "plugin-name",
percent = 25,
status = "running",
})
* fix: parsing neovim api function parameters
Fix neovim API parsing failure after dc8934482e.
* refactor api parameter type parsing
---------
Co-authored-by: Alexsander Falcucci <alex.falcucci@gmail.com>
we are now replacing the native tabs switcher into a Neovide-owned custom editor switcher.
Why?
The native tab overview was a temporary choice for this feature.
editors should be about moving between Neovide editors without limitations,
but tying it to the system tabs overview made the behavior depend on whether native
tabs to be enabled, plus hacking to make it work properly not affecting separate
windows.
users who prefers separate-window has been forced to merge
and detach windows just to present a choice to switcher windows easier which
made the single-window case fall back to pinned-window toggling. That
was a known gap.
now with a Neovide-owned custom switcher it gives both modes the
outcome.
NOTE: behavior-wise shouldn't change, besides the switcher appearing now even
for separate-window mode.
neovide started temporarily requesting external messages in #3504 so
startup errors from #3499 would not disappear behind a hit-enter prompt
before the first grid was rendered.
losing early startup errors is a bad failure mode and users should not have to
guess why Neovim is stuck before neovide has a real message area.
but this also made neovide advertise ext_messages and ext_cmdline during
plugin startup. noice.nvim explicitly checks nvim_list_uis() before
attaching its own UI and refuses to handle messages or the cmdline when
another UI client already owns those extensions.
neovim can hit wait-return during startup before the first grid update. at that point
we have no message area to show the error and no useful window to accept the Enter
that would let startup continue.
now temporarily we request external messages during startup, capture msg_show events until the
first rendered batch, restore the built-in message and cmdline UI, then replay the captured
messages through nvim_echo without duplicating message history.
we keep this path gated to nvim 0.12+, since 0.10/0.11 externalize cmdline prompts in ways
we do not render during startup, so we preserve cmdheight across the temporary external-message
mode where the startup capture does not silently rewrite the user's message area.
the old fallback mapped None to WaitUntil(now), which asks the
event loop to wake up immediately. during startup, if nvim blocks before
the first render state exists, that turns into a tight CPU loop.
the error-window special case was the wrong abstraction: no deadline
should mean idle wait, regardless of why there is no render deadline.
we keep WaitUntil only for real deadlines and use Wait otherwise.
the second fullscreen transition is what previously made
the AppKit assertion wrongly.
```
Assertion failure in -[NSWindowStackController _enterWindow:intoFullScreenWithWindow:]
```
If the host window is already fullscreen, reapplying the
global fullscreen setting to the new window is redundant.
now we just resolve the initial fullscreen state for new
windows more carefully: if the new window is being created from a
fullscreen native-tab host, we skip the initial fullscreen call for
that secondary window and leave the host alone.
since its state is already fullscreen, the new window will be created in
a normal state and then transition to fullscreen immediately after.
the cursor setting neovide_cursor_animate_command_line was broken
see https://github.com/neovide/neovide/discussions/3180
first,
neovim has three actual editing modes:
- cmdline_normal
- cmdline_insert
- cmdline_replace
- cmdline_hover (ignored, mouse shape state, not editing mode)
secondly,
the immediate movement wasn't actually immediate. we snapped the cursor position,
but left the corner springs alive, so the next frame resumed animating and
produced the trail we were supposed to suppress.
we basically now reset the spring state when movement is forced immediate.
there is also a ui2 incompatibility that we fix. (experimental)
with ui2, leaving the cmdline is not a single clean mode transition.
neovim leaves MODE_CMDLINE first, then ui2
redraws the cursor in its cmdline float one more time before the cursor
returns to the real editing window. A plain previous_mode/current_mode
check misses that last hop.
we fix that by tracking a small cmdline cursor context in the renderer,
so the final ui2 exit hop is still treated as part of the cmdline transition.
* handoff: pass neovim_bin and neovim_args
* handoff: keep route cwd on duplicate windows
since duplicating a window now takes with it its neovim bin/args, it's
reasonable to keep also its route cwd as well to not sound incomplete.
---------
Co-authored-by: Alexsander Falcucci <alex.falcucci@gmail.com>
*A grid having a size is not the same thing as that grid being visible*
the experimental ui2 just exposed an assumption that we were doing.
See #3446
A resize tells us that a grid exists and what size it has. It does not
tell us that the grid is actually visible. Those seems to be different
states from neovim, and we were treating them as if they were the same.
For a new non-root grid that first appeared through a resize, we would
instantiate a window immediately. That construction also gave it a
position, and the renderer then treated that position update as if it
meant to show that window. That logic only works if every resized grid is
supposed to become visible right away.
hidden helper windows can be resized long before neovim decides to place
or show them. which seems to be the case now on ui2. So our old behavior
could restore a window that neovim still considered hidden, which is why
the wrong border and stale helper window would leak on startup and
again after resizing.
mainly linux users affected but users who doesnt explicitly set 'guifont'
and doesn't have the default upstream list installed could notice some
slowness.
see https://github.com/neovide/neovide/issues/3457
font loading is very fast but expensive if we do redundant stuff.
neovim now sends platform-specific default 'guifont' fallback lists.
on affected systems the first entry in that list may not be installed,
but Neovide still keeps it in the active fallback chain and probes it
again on every shape-cache miss. That turns a normal miss into repeated
redundant load_font churn before we ever get to a font that can actually
render the text.
we now fix that in two ways:
- remember FontKeys that already failed to load;
- drop failed normal guifont entries from the cache fallback list
after validation, so the miss path stops re-searching fallback chains
around fonts we already rejected
if we want an explicit cwd to be respected, it has to be part of the
actual command executed by the non interactive login.
So we do the following now:
- resolve the cwd once before building the command spec
- pass that cwd into the command builder
- emit cd <cwd> && exec <command> for desktop launches
- keep the terminal-launch path unchanged
previously we assumed that clipboard support was always there, so
unwrap() was inappropriate meaning that if the clipboard provider failed to
initialize, we panicked.
todo: in fact we should ERASE all unwrap() from the codebase if not tests.
so to model the thing we actually have:
- a clipboard provider that *can* be available
- or it can be unavailable, with a reason
x11 PRIMARY vs CLIPBOARD selections
see https://specifications.freedesktop.org/clipboard-spec/1.0
x11 display connection is explicit and may fail
see https://www.x.org/archive/X11R7.5/doc/man/man3/XOpenDisplay.3.html
wayland display is an explicit compositor connection and connect can fail
see https://wayland.freedesktop.org/docs/html/apb.html
see: https://github.com/neovide/neovide/issues/3447
after the multi-window refactor, the renderer can be created before
neovim initial globals are ready.
the runtime path had a second bug:
scale factor updates through settings updates stored the new user scale
and then recomputed the grid scale with the old one. so scale changes were
always one step behind also reported at
https://github.com/neovide/neovide/issues/3447
the real problem is that neovim handle wasnt really ready yet. The queued file-open events
e.g from finder were being flushed as soon as the first handler registered,
but the handler registration happens before ui_attach and in embedded mode neovim
does not finish startup until the UI attaches.
we were replaying `:drop` into an instance that had not finished loading a bunch of
of things like filetype detection, syntax setup or user startup scripts.
see: https://github.com/neovide/neovide/issues/3444
* reintroduce error window for launch failures
* fix: high cpu usage launch-error windows
just adding some control flow for the eventloop scheduler to avoid it
to wake up immediately when the only remaining window is an error
dialog, or if it is an error window in general.
---------
Co-authored-by: Alexsander Falcucci <alex.falcucci@gmail.com>
the old :restart progpath/argv payload is not the protocol anymore
see: https://github.com/neovim/neovim/pull/35223
the contract is now simpler:
- the server starts the new neovim instance
- the UI gets a restart event with the new listen address
- the UI follows that address instead of rebuilding argv
impl the new protocol exposes the second bug. if a reused Neovide process
opens a new embedded window, that route has to start with the files it was
actually asked to open, otherwise :restart will attempt to restart the
process startup args from the first window, or an empty session.
note: neovim reports message grids with the full default-grid height even when only
the bottom few rows are actually on screen.
f2d0b06ecb/src/nvim/message.c?plain=1#L205-L254
we were already compensating for that in one place when clamping the target
position, but then we turned around and used the full backing-grid size for
pixel_region()
that means the renderer still treated the message window as if
all rows were visible, which is wrong.
https://github.com/neovide/neovide/issues/3427
we mistakenly added a theme option to the config file, but it is not
actually used anywhere, must be impl in the future.
let g:neovide_theme has no changes.
the mistake here was treating --chdir and a relative file arg as if
they described the same directory.
they don't.
For a handoff like
cd ~/neovide
neovide --reuse-instance --new-window src/main.rs --chdir ~
the file comes from the caller shell cwd, so it should still mean ~/neovide/src/main.rs
but the new neovim route itself should start with cwd ~
now we take both meanings explicitly through the handoff path:
- cwd: the per-route startup cwd
- caller_cwd: the base directory for resolving relative file drops
