-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SafeState
or something similar could be really useful for vim.ui_attach
#28772
Comments
@luukvbaal maybe you have some ideas? With all your recent changes, I was able to finally just queue the messages received in the |
What does "trigger |
The last |
I'm confused. What does this have to do with |
I meant that it (or a similar event) could be useful to allow ui updates at some points where it's currently not possible. To be fair, I think I just found a better work-around specifically for |
I'm not sure I understand why a dedicated event is needed, won't flushing the desired state in the appropriate places be sufficient; like in #27950? And for cmdpreview in particular, removing the redraw restriction is the way forward: #28510.
Care to elaborate on these? I deliberately did not look at noice's implementation and it's workarounds when working on the default ext UI(which I have postponed to work on for the time being) and instead aimed to resolve issues in the C core as I ran into them. |
I'm not sure what #27950 achieves regarding my bug report?
That would be great
Previously I queued messages in the With some of your recent updates, a lot of those Now I just queue messages and never try updating the UI in the callback (and never trigger redraws either during). What would I need to do to get my command line floating window to redraw properly after receiving an |
fyi, how I currently solve the issue with
|
This bug report or #20463? Like I mentioned in the last comment in that PR I think the change is sufficient to redraw updated cmdline state, did you try it out and experience otherwise? Perhaps it's not obvious but |
Yes, I meant #20463 indeed. I tried a couple of things with your PR:
To be clear, I am getting all the |
This is what I've been doing and I think it should be allowed. |
That would be really great, but at least before all your recent work, this segfaulted Neovim in a lot of different ways. With your PR, I get a segfault after entering Without your PR, it still doesn't work, but doesn't segfault. |
I don't know if this is helpful but before #25629 I was able to render the cmdline having cmdpreview active without issues and no workaround, by just calling redraw in the callback after setting the line in a float. On master I do observe the lagging character issue and I can't update the float window at all after the second "/". |
When I created Noice and hit some of the issues with the implementation of Based on all the recent changes and new issues I hit with Noice, I mistakenly thought that was all in preparation of the above. If I understand correctly now, the goal is to just make it all work without any new low-level API and where the lua callback is allowed to fully alter views during. I also just tested #27950 again and it works great now. For Noice, this was probably the biggest issue with Closing this issue, since it no longer applies. |
I mean this has been my goal, and so far I had not gotten the impression that there is something fundamentally wrong with that approach. If that goes against previous discussions/conclusions that is solely because I was oblivious to them. Is there a reference to those discussions? |
Not really. Was mostly on matrix and a long time ago. A lot of the underlying issues with redraw have been fixed since I released Noice. Things that also triggered segfaults unrelated to Noice. To be clear, Noice only triggers redraws or updates/creates windows/buffers during the callback in very few cases, when I know for sure or it's possible for Neovim to block on input. Most of the time, a redraw is not needed and it was mostly those redraws that triggered segfaults. Noice also detects recursive redraws (or recursive vim.ui_attach callbacks). The biggest new issue that popped up over the last couple of weeks were those I currently just queue updates in the callback during |
Sorry forgot to reply here @folke; short answer no I don't think there is a builtin way to check if textlock is active(other than I do think we should try to avoid the issue you describe but I'm not sure what's the best way to resolve it. The issue stems from |
postponing when active is probably a good approach here. |
Problem
I just read up about
SafeState
and something like this (SafeUIState
) could be really useful forvim.ui_attach
when triggered:getchar
cmdpreview_may_show
redraw
Especially the second one would be great, since the current work-around for this in Noice is not ideal.
When
cmdpreview
is active,redraw
s are ignored, but withvim.ui_attach
this is not ideal.User enters
:%s/foo/bar
. The lastr
will correctly triggerui_attach
and will then show the correct preview.However, it's not possible for the cmdline ui to redraw itself (since redraws are disabled when
cmdpreview
is active).My current work-around is to use
nvim_feedkeys
with<space><bs>
.Related issues
vim.ui_attach
withext_cmdline
andext_messages
should have an event for user input withgetchar
orgetcharstr
#20311The text was updated successfully, but these errors were encountered: