[RFC] External ui #5686

Open
wants to merge 30 commits into
from

Projects

None yet

7 participants

@dzhou121

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:
https://youtu.be/rzclz1seo0g

@marvim marvim added the RFC label Nov 29, 2016
@justinmk
Member

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?

@bfredl
Member
bfredl commented Nov 29, 2016 edited

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.

@dzhou121

@justinmk @bfredl

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.

@justinmk
Member

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

@teto
teto commented Nov 29, 2016

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...

@qvacua
qvacua commented Nov 29, 2016

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.

@dzhou121 dzhou121 don't need to clear the window for some actions
b131783
@chemzqm
Contributor
chemzqm commented Dec 1, 2016

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.

dzhou121 added some commits Dec 2, 2016
@dzhou121 dzhou121 make preview window floating so that\nthe GUI can put it anywhere
5118e40
@dzhou121 dzhou121 Added new command fnew to create a floating window
The floating window is useful for plugins like
Crtl-P
9cfe8a0
@dzhou121
dzhou121 commented Dec 2, 2016

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.

@dzhou121
dzhou121 commented Dec 2, 2016

https://www.youtube.com/watch?v=UgS-B12E0ps

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.

@teto
teto commented Dec 2, 2016

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)?

@dzhou121
dzhou121 commented Dec 2, 2016

@teto

We could have a new wincmd command that can cycle through all floating windows. Something like

wincmd fnext

@teto
teto commented Dec 2, 2016

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 ?

@dzhou121
dzhou121 commented Dec 5, 2016

@teto

Yes :emenu seems to be working through wildmenu

The screencast was using https://github.com/dzhou121/envim

@extr0py extr0py referenced this pull request in extr0py/oni Dec 8, 2016
Merged

Added UI closing on commandline mode #53

dzhou121 added some commits Dec 12, 2016
@dzhou121 dzhou121 external statusline
d96e636
@dzhou121 dzhou121 external status line can use whole width
7492f58
@dzhou121

A screenshot for externalising statusline

dzhou121 added some commits Dec 15, 2016
@dzhou121 dzhou121 fix :messages 4326b60
@dzhou121 dzhou121 go to previous when close a floating window 90587d4
@dzhou121 dzhou121 fix win_close for floating window ac66442
@dzhou121 dzhou121 fix win_close for floating window
a6dbc91
@dzhou121 dzhou121 Merge remote-tracking branch 'upstream/master' into external-ui 523bdcd
@dzhou121 dzhou121 Merge remote-tracking branch 'upstream/master' into external-ui 6e584d7
@dzhou121 dzhou121 external ui for new stuff
0001864
@dzhou121 dzhou121 revert back the right position
45359e9
@dzhou121 dzhou121 change floating window size
3959add
@teto
teto commented Jan 2, 2017

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 ?

@dzhou121
dzhou121 commented Jan 3, 2017

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.

@teto
teto commented Jan 4, 2017

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 ?

@dzhou121
dzhou121 commented Jan 6, 2017

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.

@justinmk justinmk referenced this pull request Jan 11, 2017
Open

Fold improvements discussion #5931

3 of 8 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment