-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 30/01/2021 12:47, Bram Moolenaar wrote: > > 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?
Yes, I can replace the :wincmd w iteration with win_execute() then. I'll try to adapt my plugin in the coming days. I'll report back should I run into any problems :-) Thanks for considering my use case! - -- regards, ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgFUiZAAoJEA7ziXlAzQ/vCfMH/14KSQdG0lye2eIQ+FQeikon Dcu/u9c1hP1PsrPAQ6P09QYXtQTsIX7OtySX23Vyow9luPvzeRFX3ZOxImgsux4c MHndWSz/as8N58QGZO7TnbriWsTqOA1LKEWdKfI6hpITQB55bK8SaHjiapNc0oGN jiK2Zuzuf3QfYuLM9dqPme5WcZ/SyECi6GGBsYUbPKZS5qgsZz0aku3V3NIjOHMo SiTpVOQtxL4VCBTH0NOXDQ/kgR6rSsogLHVSh2ZbEjQRU6DvVpdQHoTQicYXVFAT OYaoQYnhWoVK0mSPN7TN6IWBToASKki8J9LzzEIswQhqeMPfoTpiNWVslD1MR0I= =lazK -----END PGP SIGNATURE----- -- -- 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/7c6aec0b-442c-81b0-14da-9a9f94db8e44%40ingo-karkat.de.
