Hello again,
Some good news and bad news. Good news - I have a branch working and it even passing GitHub’s CI, which is comforting! Bad news - I still have many questions ranging from simple things such as “What should the error code be for when we need to display a message?” I picked E922 since it is currently unused but I don’t know if there’s a standard to the error codes that I’m stepping over to more complex decisions such as - The :drop command has no [!] so 'stickybuf' completely disables it. Are we okay with adding [!] so it has a fallback? - Several mappings are disabled during 'stickybuf'. Do we want to change :normal! the-disabled-mapping to force the mapping on 'stickybuf' windows? :normal! already has an existing, different meaning. - Should X group of commands that follow a specific 'stickybuf' behavior merge into group Y other-commands-behavior? And other decision-making related questions like that. Would you rather we keep communications to here while each point is sorted out or would you want to see a GitHub draft PR sooner and I can place remaining questions there? I’m happy to do either. Thanks, Colin On Wednesday, January 17, 2024 at 11:29:33 AM UTC-8 Christian Brabandt wrote: > > On Di, 16 Jan 2024, Colin Kennedy wrote: > > > Hello! > > > > I had to take a break from this for a while but I'm back at it. Since > > then, I've encountered some scenarios that I wanted to double-check > > with you all. > > > > Previously, we talked about creating a new split window if `:foodo` is > > called and all of the current windows are `'stickybuf'`. I've added > > that behavior for `:argdo`, `:bufdo`, `:cdo`, and others. > > > > Now for my questions, below: > > > > 1. What about `:ldo`? Location lists are tied to one window, I > > believe. So if you create a window, then a location list, then set > > that window to `'stickybuf'`, and then call `:ldo` to try do an > > operation on multiple buffers, I don't think we could split the window > > in that case, right? Because the location list is tied to a window, > > the newly-split window would be unrelated. What happens in this case - > > should the user get an error unless `[!]` force-it is included? > > Yes, location lists are window-specific. I would think an error unless > '!' is given is reasonable behaviour. > > > 1b. Same question but for `:lnext` and other commands related to > > location lists. I'm not sure if it makes sense to split the window if > > calling `:lnext` would visit another buffer. We can do that for > > `:cnext` and its family of commands but I'm not sure about `:lnext`. > > Should I give the user an error message unless `[!]` forceit is added, > > instead? > > Yes, also reasonable. > > > What should happen in `:lnext`'s case? > > Did you not just talk about :lnext? > > > 2. If I call `:windo` should it also fail only any encountered window > > is `'stickybuf'`? I was thinking we could add `[!]` to mean "force-it > > on all windows, including `'stickybuf'` windows". Currently there's no > > `:windo!` so it seemed like a good reason to add `[!]` to `:windo`. > > I don't think so. If you do :windo :set nu, why should this fail for > sticky buffers? I don't think :windo should fail in general, but we > should rather leave this to the individual commands. E.g. when trying to > load a new buffer in the window, this command should fail (and then > cause :windo fail as well). > > > If you could weigh in on what the expected behavior should be, that'd > > be really helpful. > > > > Thank you! Colin > > > Thanks for working on it. I hope a few people can try it out once you > have the patch ready. > > > Thanks, > Christian > -- > Contains a substantial amount of non-tobacco ingredients. > -- -- 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/152feafb-4ce0-4706-88b4-476af8fbbd90n%40googlegroups.com.
