On Saturday, May 18, 2019 at 1:39:15 PM UTC+1, Bram Moolenaar wrote: > 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 -- [email protected] -- 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 ///
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. -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/6e9f2e8e-76a4-48b1-a667-a4e7eaec7b9b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
