popup window design

[Bram Moolenaar]

In a recent Vim you can see the current ideas of the popup window design
with ":help popup". Or go to github:
https://github.com/vim/vim/blob/master/runtime/doc/popup.txt

I have been wondering about how to specify the text and highlighting.
The current proposal is using a list with text and text properties. An
alterative would be to use a buffer, like we use for a normal window.

The buffer would be an unlisted scratch buffer. It's mostly hidden from
buffer commands, so it doesn't get in the way. A bit like help buffers
(but scratch, not associated with a file).

One of the advantages is that the code to display window text can be
used, including all the settings we have for it. It's even possible to
use syntax highlighting, so that a code snippet can easily be displayed
nicely. Also takes care of text wrapping. This does imply that we also
have a window for the buffer, with window-local options.

One restriction needs to be that the buffer can never be the current
buffer. The popup does not get keyboard focus. Only the filter can be
used to intercept keys while the popup is open. The poup is not meant
to be a window to edit text. Not sure if it has a working cursor
position. And there are many commands that only work in the current
buffer, such as syntax commands, need to figure out how to deal with
those. Perhaps with ":inbuffer {nr} {cmd}".

I'm not sure how much work it is to implement this, and whether it's
less work than the list of lines. But since this is long term
functionality the amount of work is less important. At least the newly
added text properties will work right away. It might be tricky to avoid
flicker when moving the popup around.

Thoughts?

--
At some point in the project somebody will start whining about the need to
determine the project "requirements". This involves interviewing people who
don't know what they want but, curiously, know exactly when they need it.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Ben Jackson]

This is an interesting idea. I suppose my initial thoughts are, if you squint a lot, this is a _little bit_ like how the preview window works. My reservation there is that when drawing the preview widow, auto commands are triggered (BufLeave/BufEnter, WinLeave,WinEnter if I remember correctly).

With a number of plugins hooking things like WinLeave and BufEnter, etc. you can get pretty serious slowdown when you have completeopt += preview and just scanning through the current popup menu. Arguably, this is a plugin performance issue but we should consider in this design what (if any) autocomands would be triggered for the new "popup" window and the buffer within it.

So in summary, I _do_ like the idea of the flexibility of having a window/buffer rendered as the popup, and from an engineering perspective, it is attractive because it seems canonical (in the sense that a buffer is a list of lines + some properties rendered in a window, and that's essentially a popup). But could that flexibility have performance and complexity trade-offs that we don't want? Difficult to know without trying it out I suppose.

Just thinking out loud.

[Bram Moolenaar]

> This is an interesting idea. I suppose my initial thoughts are, if you
> squint a lot, this is a _little bit_ like how the preview window
> works. My reservation there is that when drawing the preview widow,
> auto commands are triggered (BufLeave/BufEnter, WinLeave,WinEnter if I
> remember correctly).

A big difference between the popup and the preview window is that it's
showing a file. For example a header file that shows the definition of
a function. The popup window will not show a file, the text has to be
set manually. That text could be read from a file by a plugin, but the
popup buffer will not be associated with that file.

> With a number of plugins hooking things like WinLeave and BufEnter,
> etc. you can get pretty serious slowdown when you have completeopt +=
> preview and just scanning through the current popup menu. Arguably,
> this is a plugin performance issue but we should consider in this
> design what (if any) autocomands would be triggered for the new
> "popup" window and the buffer within it.

I don't think any autocommands will be triggered. A plugin that opens a
popup window needs to take care of calling any code or scripts that
needs to be executed.

> So in summary, I _do_ like the idea of the flexibility of having a
> window/buffer rendered as the popup, and from an engineering
> perspective, it is attractive because it seems canonical (in the sense
> that a buffer is a list of lines + some properties rendered in a
> window, and that's essentially a popup). But could that flexibility
> have performance and complexity trade-offs that we don't want?
> Difficult to know without trying it out I suppose.

The expensive things are syntax highlighting, folding, concealing,
showing matches and other stuff like that. So long as you don't use
them displaying text should be quite efficient. We also take advantage
of only displaying parts that changed.

Quite often it turns out that displaying colored text is the most
expensive, and we are usually willing to pay that price.

> Just thinking out loud.

Input is appreciated.

--
I recommend ordering large cargo containers of paper towels to make up
whatever budget underruns you have. Paper products are always useful and they
have the advantage of being completely flushable if you need to make room in
the storage area later.

[skywind3000]

What about implement both of them and give them two different names ?

First, implement the list of lines, the api design( https://github.com/vim/vim/blob/957f85d54ebd5a3bd0d930de9603190f0876f977/runtime/doc/popup.txt) is very simple and clear, it requires less work and can give us something to use after a short time.

Then, implement the popup buffer, it requres to modified a lot of existing window/buffer code. and many details have not been decided yet. We have planty of time to consider and implement it in a nice way.

But the buffer solution is really similar to neovim's floating window, neovim uses nearly two years to bring it out. So it's no doubt that popup buffer solution will take a long time in the future and many thing may change.

So, give plugin authors something to use (like list of lines) at first please. and collect feedback to iterate the popup buffer.

[Bram Moolenaar]

Hmm, that would mean implementing the display code twice, which makes it
even more complicated. The display code is most of the work anyway.

It would be possible to create a popup with just text, then Vim would
create a buffer to hold that text. Text properties can be added as
well, since they will be defined the same way.

--
If someone questions your market projections, simply point out that your
target market is "People who are nuts" and "People who will buy any damn
thing". Nobody is going to tell you there aren't enough of those people
to go around.

[Paul Jolly]

Hi Bram,

I'm certainly not as close to the details as you or others so won't opine on the pros or cons of buffer vs text properties.

The one thing I'll point out with respect to govim and gopls is that it's likely we'll get back markdown or some other form of markup for, say, documentation. Now it's trivial to transform this, so just so long as we have an easy way of applying highlighting I think we'll be set.

That of course doesn't preclude something more low level, just looking to (selfishly) flag what is likely to be my first use case.

Many thanks for putting time into looking at this.

Paul

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201905181239.x4ICd8qH012720%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.

[Marco Trosi]

I like the simple solution. The buffer solution can be done indeed later.