This pull request is inspired by the external popupmenu and try to address the same approach for windows.
This patch will make neovim to treat each window individually and will output cmdline, tab, wildmenu to API without drawing them.
It will only have effect when win_external is set by API so tui is still working in the old way.
The achieved result is shown in this screencast:
chars display correctly now
Merge branch 'external-ui' of https://github.com/dzhou121/neovim into…
external some new changes
will output cmdline, tab, wildmenu to API without drawing them.
will output cmdline, tab, wildmenu to API without drawing them.
Nice. Should there be a different foo_exernal flag for each of them? Currently there's only win_external. @bfredl do you think we should continue to have "granular" opt-in externalized widgets?
@dzhou121 Do you plan to add tests?
Very interesting! I will need to take a deeper look into this, for instance how does this integrate with window ^W commands?
But at a quick glance, It looks like we could have a separate cmd_msg_external that makes messages and command line (including wildmode) external without enabling separate windows. (it should only free the last row in the grid as if cmdheight=0). win_external will then simply imply cmd_msg_external.
This patch's aim is to external everything that makes sense to be externalised. So probably win_external should be changed to ui_external.
Re window ^W commands, it still let neovim to handle window layout management. But the external API will know the windows' sizes, positions, etc. So the most direct benefit is the line between vertical splits.
There's still the minor question: do we want to allow UIs to opt-in to externalizing only certain pieces? If we put everything behind a single ui_external flag then that means UIs must implement all externalized widgets instead of only some. If it makes the code/logic significantly simpler then I would lean towards "no granularity". But if it's low-cost to provide granularity then it might be worth doing so. cc @rhysd @qvacua @rogual @carlosdcastillo
very cool ! I vote for granularity since it should be simple to provide (bitfield like) while adding a convenience: easier to provide a WIP UI, if some widget is buggy, the dev can disable it in favor of the native etc...
I agree with @teto. The external popup menu does not have a very high priority for me and it'd be nice if it'd be an opt-in such that the "text"-based popup menus would continue to work.
don't need to clear the window for some actions
I do think it's better to just have a single ui_external flag, so that the GUI author could make sure to build a consist UI , instead of part of them, which would be confusing for the user, and also affect building the theme for GUI.
I also think the previewWindow should be ui_external, it would useful to avoid redraw when completing.
make preview window floating so that\nthe GUI can put it anywhere
Added new command fnew to create a floating window
The floating window is useful for plugins like
I've added floating windows support. And preview-window can be an opt in. You can make it floating or still let Neovim to handle the window layout for it.
But when you external window layout, you imply external cmdline, tabline as well, because the screen rendering happens at window level. So there's no "screen" for cmdline, tabline any more.
This screencast demonstrates the floating windows capability:
The error information of the syntax is displayed in a floating preview-window and positioned at the cursor by the GUI.
The FZF plugin is using the floating window that can be centered by the GUI.
The floating window support seems very interesting, While I don't think it can help the Window Manager handle windows instead of nvim (#2161), I wonder if it could be used to provide UI-enhanced quickfix/location lists as displayed in https://a.fsdn.com/con/app/proj/texstudio/screenshots/errorHighlighting.png . I would love to have a button to toggle warning messages (I have a QFGrep mapping for that but sometimes buttons are a nice to have as well)?
We could have a new wincmd command that can cycle through all floating windows. Something like
As you seem pretty fired up, I wonder if your UI display vim "menus" in any special way ?
I think that :emenu completion relies on wildmode so if you support wildmode that should cover it (I find the vim-menus quite useful to run rare commands I am sure to forget, yet it's not popular with plugins :/).
To reproduce your screencast, is using https://github.com/dzhou121/envim with this PR enough ?
Yes :emenu seems to be working through wildmenu
The screencast was using https://github.com/dzhou121/envim
change previewwidth default to 100
Merge branch 'master' into external-ui
automatic show matches for wildmen
external status line can use whole width
A screenshot for externalising statusline
go to previous when close a floating window
fix win_close for floating window
Merge remote-tracking branch 'upstream/master' into external-ui
external ui for new stuff
revert back the right position
change floating window size
Have you already thought about column drawing externalization (line number/folds/signs) ?
I have started working on TUI improvements related on that but for smart UI design, I wonder if neovim experts would envision some more radical changes like using extmarks to advertise the folds ?
Yes I did. But when you externalise column drawing, how would you deal with the space of the column in neovim? Either externalise the whole windows layout management or still reserve the space but doesn't draw anything there.
First of all, I believe an UI should be able to choose which columns (line number/folds/marks) to externalize for the same reasons I mentioned earlier (makes addition of UI features more incremental).
If line number drawing is externalized, then how to retrieve the line number display ? the logic can be complex between the different "set number"/"set relativenumber" configurations. Should nvim compute & communicate the result to the UI ? or should the UI duplicate the logic to compute the line display (or access the function via a neovim library ?) ?
At first I thought column externalization would be as simple as skipping the code in screen.c that draw the specific column(s) but it's not possible if neovim wants to handle several UIs with different column externalization preferences. Either neovim should send the characters with some metadata to let the UI decide to skip it or the UI should be able to retrieve the data via another channel (extmarks to get folds for instance ?).
I believe the tiebreaker would be the TUI as it is the most annoying as far as drawing is concerned but I don't know enough to propose an explicit architecture yet.
Ps: I wonder how you envision the future (merging) of this PR ? cherrypicking parts as separate PRs ? Externalizing commandline could be merged quite easily while the floating windows could be a headache IMHO ?
With the windows externalised, we can include the column width information. Without changing column rendering code, the external UI will know that which part of the window is the column.
Regarding merging this PR, what is the best approach for me? I've been using this in my daily work and it works pretty well.