Ingo Karkat wrote:
> >> On 29/01/2021 21:07, Bram Moolenaar wrote: > >>> > >>> Patch 8.2.2426 Problem: Allowing 'completefunc' to switch > >>> windows causes trouble. Solution: use "textwinlock" instead > >>> of "textlock". Files: src/insexpand.c, > >>> src/testdir/test_ins_complete.vim, src/testdir/test_popup.vim > >> > >> I hope that use of win_execute() is still possible during > >> completion, right? You already had disabled window switching once > >> in 8.2.0614, and after I complained in > >> https://github.com/vim/vim/issues/6017 you again allowed > >> switching as long as it returned to the original window. > > > > I forgot about that. And frankly, reading it again I don't quite > > understand why I allowed window switching. If someone has > > autocommands setup, it an fail miserably. > > Of course the plugin uses :noautocmd. It's the often-discussed tradeoff: > Vim's commands primarily focus on easy interactive use (and that's > good!); unfortunately, that makes plugins harder to write in a robust > way (but it is possible, with some effort and learning). But here I > think all completefunc's are written for plugins, never ad-hoc. > > > As I mentioned: "It's not trivial, I hope it will allow enough > > without allowing too much". So now we found another case where it > > causes trouble. I'm not sure if we can keep fixing every problem > > we find. > > It would just be nice from my perspective to detect the bad cases and > only then throw an error, instead of disallowing in general. But I fully > understand if that's not possible due to the complexity. > > >> Many of my completion plugins use window switching, and I never > >> had any issues reported because of it, so it's sad that you now > >> decide it has to be disallowed in general, just because _some_ > >> code _can_ misbehave. As long as win_execute() can be used (and > >> that does offer some minor benefits over :wincmd w), I can adapt > >> the plugin code (but will then have to either drop old Vim > >> versions that don't have it, or keep maintaining the existing > >> implementation in parallel). > > > > I don't like existing plugins to fail, but I also don't want a > > misbehaving plugin to cause trouble. In case a complete function > > bails out and doesn't restore the window, what to do? Restoring > > the window after the function returns might be best, but that might > > fail too (again, because of autocommands). Perhaps we should > > disable autocommands while in the complete function? It's getting > > too complicated... > > I don't think you have to go so far. People will notice when completion > breaks and then learn about using :noautocmd, try...finally, etc. > Throwing an "E999: Must return to original window" would be fine. > > > So, what functionality is missing to do what you want without > > actually switching windows? > > If I can still win_execute() within completefunc() to visit other > windows temporarily, do search() and cursor() in there, that would be > fine. As I hinted at, it would even have some minor benefits, like not > having to restore the previous window and windows with a height of 0. As far as I can see win_execute() works. So you are OK then? -- hundred-and-one symptoms of being an internet addict: 268. You get up in the morning and go online before getting your coffee. /// 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/202101301147.10UBlm1J620882%40masaka.moolenaar.net.
