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? 2. Same question as #1 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 [!] force-it is added, instead? What should happen in :lnext‘s case? 3. 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. If you could weigh in on what the expected behavior should be, that’d be really helpful. Thank you! Colin On Thursday, December 28, 2023 at 6:01:37 PM UTC-8 Colin Kennedy wrote: > Hi Christian, > > Where the terminal buffer’s window has stickybuf’ enabled and ‘switchbuf’ > includes ‘uselast’, I changed :cnext and other commands to prefer the last > ‘nostickybuf’ window. … I don’t understand option 2. How would it succeed, > if you do not change the windows buffer? > > Admittedly that #2 was not well thought out. I was too closely relating > :cnext-and-family commands to :foodo-and-family commands. I’m happy to do > #3 as you’ve suggested :) > > If you think of ‘stickybuf’ as making the window containing the buffer > immutable, I would think we should open a new window then. Thinking about > it, it seems similar to how help files are handled > > Sure, we can do that. I’ll open a new window according to 'switchbuf' > like :cnext and others already do. > > This also sounds like you may want to reuse the ‘buftype’ option and add > stickybuf as a new special value for it? > > Originally I had 'stickybuf' as a “local to buffer” option like 'buftype' > but setting 'stickybuf' on the buffer frequently caused hiccups during > testing. For example, if 'stickybuf' buffers are not hidden, there’s a > chance someone could open the 'stickybuf' buffer by accident and then > think “whoops! I didn’t mean to go to this buffer, I’d better back out!” > and try to call :edit # or something only for it to fail because the user > is in a 'stickybuf' buffer. (I later added forceit[!] to those commands, > but that’s besides the point). It was a frequent annoyance for me, during > testing. 'stickybuf' as a “local to window” option was much more natural > in my opinion because then the only concern left to solve is “when we split > a 'stickybuf' window, should the new window also be 'stickybuf'?”. > Currently I’m leaning towards “no” because if you’re making a split, you’re > probably about to switch away from the buffer. Maybe that’s a bad > assumption, please let me know. > > Regarding buffer vs window attribute, I figured if someone wants > 'stickybuf' to be buffer-like, they could still achieve the same effect > even if 'stickybuf' is a window option by using a buffer autocmd. > > Same here, if ‘stickybuf’ option is set, can we open a new window instead? > > Do you mean > > “if only windows with 'stickybuf' remain, rather than erroring, can we > open a new window instead?” > > or > > “if 'stickybuf' option is set, can we always open a new window instead” > > Either way works for me. Though I’d prefer it as a last resort, > personally. Would you also want this new window opened according to > 'switchbuf'? Currently I don’t know whether :argdo, :bufdo, :cdo consider > 'switchbuf'. The :help doesn’t mention it, that I could find. > > Last question for now - if we keep 'stickybuf' as a “local to window” > option, should we add a ! to :windo? From :help :bufdo, I noticed a line > that says “When the current file can’t be |abandon|ed and the [!] is not > present, the command fails.”. Since :windo has no !, I was wondering if > 'stickybuf' would be a good opportunity to give :windo parity with the > other :foodo[!] commands. > > Thanks, > Colin > > On Thursday, December 28, 2023 at 10:47:46 PM UTC Christian Brabandt wrote: > >> >> On Mi, 27 Dez 2023, Colin Kennedy wrote: >> >> > Hi everyone, >> > >> > I hope this is the right place to ask a question to Vim maintainers. My >> question is about this post: https://github.com/vim/vim/issues/6445 >> >> You found the right place :) >> > >> > The summary of the post above is “I would like a ‘local to window’ >> option that pins a buffer to that window”. It’s a great idea however >> implementing it requires changes to commands in Vim. I was hoping to ask a >> couple questions. One about >> > Quickfix and a related question about :argdo, :bufdo, :cdo, etc. >> > >> > Quickfix + :cnext related commands >> > >> > For example, if you have a window layout like this: >> > >> > +--------------------+ >> > | | >> > | code | 'nostickybuf' >> > | | >> > +--------------------+ >> > | | >> > | terminal | 'stickybuf' >> > | | >> > +--------------------+ >> > | quickfix | >> > +--------------------+ >> > >> > Where the terminal buffer’s window has stickybuf' enabled and >> 'switchbuf' includes 'uselast', I changed :cnext and other commands to >> prefer the last 'nostickybuf' window. But what should happen in that case >> when there is only one >> > 'stickybuf' window + quickfix window, like this? >> > >> > +--------------------+ >> > | | >> > | code | 'stickybuf' >> > | | >> > +--------------------+ >> > | quickfix | >> > +--------------------+ >> > >> > Here’s some ways I could see a command like :cnext running - >> > >> > 1. Error saying something like “cannot switch buffer because of >> ‘stickybuf’” >> > 2. Succeed to change to the next quickfix entry, just don’t change the >> window’s buffer to show it >> > 3. Something else. Not sure what! >> >> I don't understand option 2. How would it succeed, if you do not change >> the windows buffer? >> >> If you think of 'stickybuf' as making the window containing the buffer >> immutable, I would think we should open a new window then. Thinking >> about it, it seems similar to how help files are handled >> e.g. what would happen if your code window would have been a help window >> instead. This also sounds like you may want to reuse the 'buftype' >> option and add stickybuf as a new special value for it? >> >> >> > What do you think of this case? >> > >> > :foodo-related commands (:argdo, :bufdo, :cdo, :windo, etc) >> > >> > Normally running these “do” commands will change a window to view >> whatever buffer you’re currently acting upon. Like the quickfix commands, I >> have it set to prefer a window that is 'nostickybuf'. But what should >> happen if there is no >> > fallback, 'nostickybuf' window to choose? Should the “do” command >> error? Or should it continue to “do” but not change the window’s buffer to >> show each entry? >> > >> > I could imagine not changing would cause commands like :bufdo >> s/foo/bar/c to become more complex because you wouldn’t be able to confirm >> the replacement in advance. Which led me to think maybe checking for a >> valid window first before the >> > “do” command runs makes more sense and fail early if there’s no window >> to choose. What do you think? >> > >> > The quickfix and “:foodo”-related commands are some of the more >> complicated cases but once we know what the best behavior in those cases >> are, I’m sure the rest will be easy. >> >> Same here, if 'stickybuf' option is set, can we open a new window >> instead? >> >> Thanks, >> Christian >> -- >> Strangelove Reproduction: >> Having children to make up for the fact that one no longer >> believes in the future. >> -- Douglas Coupland, "Generation X: Tales for an Accelerated >> Culture" >> > -- -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/61338882-bbf6-4ccb-b8e6-cbc5ef055d15n%40googlegroups.com.
