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/ZY37DQ13GlV9aAJE%40256bit.org.

Raspunde prin e-mail lui