Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Give plugin authors an "on_close" callback to use when we close down their buffer #1

Open
tjdevries opened this issue Jul 22, 2020 · 12 comments

Comments

@tjdevries
Copy link
Member

This would prevent a lot of pain that I have experienced recently.

@anihm136
Copy link
Contributor

anihm136 commented Oct 1, 2020

I'd like to work on this

@anihm136
Copy link
Contributor

anihm136 commented Oct 1, 2020

How would I be notified of a specific window closing?

@tjdevries
Copy link
Member Author

Hey!

I think the best way would probably add an autocmd on/before window close for the window that calls a lua function that was registered at startup.

@anihm136
Copy link
Contributor

anihm136 commented Oct 7, 2020

Ah, didn't think of that. Few questions about the implementation -

  1. Do I just add the autocommand using nvim_command?
  2. How would the callback be passed to the function? New parameter? Within vim_options?
  3. If we need to pass arguments to the callback, how would they be passed?

@anihm136
Copy link
Contributor

anihm136 commented Oct 7, 2020

Additionally, should the callback be a vimscript function or a lua function?

@tjdevries
Copy link
Member Author

Lua functions and vim script functions are interchangeable, so that parts fine :)

Yes, autocommands are added with nvim_command.

I think on_close is a parameter for the vim style of popup_* arguments. So you should check the docs for vim. The idea is that popup.nvim should resemble vim's implementation.

If that doesn't make sense, I can explain more later 😄

@anihm136
Copy link
Contributor

anihm136 commented Oct 7, 2020

It does make sense, thanks. I read the vim popup api docs, and one of the options is a callback as you said, so that's fine

@anihm136
Copy link
Contributor

anihm136 commented Oct 7, 2020

From the vim popup api docs, it seems that the callback works this way -

  • It is used only when a filter is also specified
  • It is called with the ID of the popup window and the output of the filter, only when the popup closes
    Is this the functionality you're looking for? That would mean that we would also have to handle the filter function

@tjdevries
Copy link
Member Author

I haven't read the docs in a bit for this, but yeah, if you wanted to start implementing the features needed to eventually get on_close to work, that'd be fantastic.

I want this to be basically the exact end result of the vim api. I can take a deeper look if you need some help on the issue or want some guidance. Just let me know.

@tjdevries
Copy link
Member Author

Oh, I forgot to mention some items may require PRs sent to neovim core. I'd be happy to guide you or help out there.

@anihm136
Copy link
Contributor

anihm136 commented Oct 8, 2020

Any ideas on how to implement filter? My first idea was to map all the keys to a wrapper, which calls the function for the pressed key and returns the key if the filter function did not handle it. But this seems to be a very ugly solution. Once filter is implemented I think the on_close callback should be much easier
Edit: Something along these lines

fun Filter(char) abort
	if a:char=='a'
		echo a:char	
		return v:true
	endif
	return v:false
endf

fun Wrapper(char) abort
	let l:captured = Filter(a:char)
	if !l:captured
		return a:char
	endif
endf

for i in range(97,122)
	exe 'map <expr> '.nr2char(i).' Wrapper("'.nr2char(i).'")'
endfor

@anihm136
Copy link
Contributor

@tjdevries could you take a look at this when you're free? I'm a little busy rn but I will get back to it. Just let me know what you think of this, and if there's a better way to handle the keystrokes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants