Ben Jackson wrote:
> 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? > > 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. (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 /// -- -- 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/201905181337.x4IDbkoh002719%40masaka.moolenaar.net. For more options, visit https://groups.google.com/d/optout.
