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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/79001154-211e-4dad-bf4f-4410d09f09aan%40googlegroups.com.
