Hi Christian,

Sorry for the miscommunication there, the previous bullet points were 
rhetorical so I didn't elaborate on them as much as I normally would. From 
our chats, it sounds like, in general, you would prefer "(find or) split a 
window" where my current branch tends to do "fail X unless X[!]" instead. 
That's trivial to fix though so we can pivot as needed.

Let's get a PR up. This will make much more sense when viewed in context, I 
think.

A PR is here: https://github.com/vim/vim/pull/13903

Thank you!
Colin

On Monday, January 22, 2024 at 12:12:51 PM UTC-8 Christian Brabandt wrote:

>
> On So, 21 Jan 2024, Colin Kennedy wrote:
>
> > 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
>
> Good news. I think picking a free error code is fine. Just add a 
> reference in the help file at :h E922 which should probably sit at the 
> description of the stickybuf option.
>
> > • The :drop command has no [!] so 'stickybuf' completely disables
> > it. Are we okay with adding [!] so it has a fallback?
>
> Why do we need this? If the current buffer is a 'stickybuf' buffer, why 
> can't we open a new window with the :drop command?
>
> > • 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.
>
> What mappings? By default there shouldn't be any mappings, so why do you 
> need them to be disabled? If you are talking about certain functionality 
> such as :b for switching a buffer, I think that should simply just cause 
> an error and abort for the sticky buffer.
>
> Regarding the current :norm! meaning:
> :norm! executes commands without applying mappings, such that if you do 
> :nmap k j
> you can still use :norm! k to mean go upwards.
>
> > • Should X group of commands that follow a specific 'stickybuf' 
> > behavior merge into group Y other-commands-behavior?
>
> I don't understand this question.
>
> > 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.
>
> Yes, please go ahead and create a PR. So we can easily test it and you 
> can get better feedback.
>
> Thanks,
> Christian
> -- 
> Physician: One upon whom we set our hopes when ill and our dogs when well.
> -- Ambrose Bierce
>

-- 
-- 
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/32dc8a20-8ca9-4237-aec1-3d424f61619bn%40googlegroups.com.

Raspunde prin e-mail lui