-
-
Notifications
You must be signed in to change notification settings - Fork 288
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
fix(popup)!: moved="any"
, enter
default, callback=fn
#622
base: master
Are you sure you want to change the base?
Conversation
@errael I am not too familiar with the codebase itself but I can solve some of the questions To run test:
To make test:
To check code style:
The next thing I am not so sure about, but I think this PR will "break" things in comparison with the |
moved="any"
, enter
default, callback=fn
moved="any"
, enter
default, callback=fn
@AlejandroSuero Thanks so much; very useful. I was going to ask about running just popup tests. But got around to doing the following on the command line
which seemed to work. It's been so many years since I've messed with makefiles... Wanting to use the Makefile to run only popup_spec.lua, this seems to work
and doing
Is there something else that makes sense? I'll include this change in the PR, can always take it out. One test, out of all the tests, is failing. Is this something to file an issue about? |
@errael to test single files you can change or create a target on the Makefile, the I will stick to the testing the whole suite in case some other modules make use of popup. Also is what is used on CI. But this something that @Conni2461 and @tjdevries should know better to explain why there is no target for Regarding the test failure, right now Im on my mobile so its a pain to check it tbh, but no ones resolves your question, tomorrow when I wake I see what could be the point of failure 😊 |
I've added some tests. I've run into a problem. In particular Here's the use case
The code can be seen in popup_spec.lua around line 195 in the PR after
|
What I'm seeing
|
Make it ready for review. Test Test |
@errael The principal issue I see is that In my case, Here is the error that Fail || plenary.popup moved option without moved
.../aome/personal/plenary.nvim/tests/plenary/popup_spec.lua:179: attempt to call global 'async' (a nil value)
stack traceback:
.../path/to/plenary.nvim/tests/plenary/popup_spec.lua:179: in function <.../path/to/plenary.nvim/tests/plenary/popup_spec.lua:178>
Fail || plenary.popup moved option with moved
.../path/to/plenary.nvim/tests/plenary/popup_spec.lua:195: attempt to call global 'async' (a nil value)
stack traceback:
.../path/to/plenary.nvim/tests/plenary/popup_spec.lua:195: in function <.../path/to/plenary.nvim/tests/plenary/popup_spec.lua:194> |
You can use either Some examples in Also in |
@errael I made the following changes, in case you want me to commit it to your branch. -- at the top
require("plenary.async").tests.add_to_env() -- this lets you use the `a` variable to make it async
-- ...
a.describe("moved option", function()
local function populate()
local wnr = vim.fn.winnr()
local bnr = vim.fn.winbufnr(wnr)
vim.fn.setbufline(bnr, 1, {"one", "two", "three", "four"})
vim.fn.cursor(1, 1)
end
local callback_result
local function callback(wid, result)
callback_result = result
end
a.it("without moved", function()
-- removed aync()
callback_result = nil
populate()
local win_id = popup.create("hello there", {
callback = callback,
})
-- move the cursor, should not do callback
vim.fn.cursor(2, 1)
local timer = vim.uv.new_timer() -- declared timer
timer:start(10, 0, function()
eq(nil, callback_result)
vim.api.nvim_win_close(win_id, true)
end)
-- removed done()
end)
a.it("with moved", function()
-- removed async()
callback_result = nil
populate()
local win_id = popup.create("hello there", {
moved = "any",
callback = callback,
})
-- move the cursor, window closes and callback invoked
vim.fn.cursor(2, 1)
local timer = vim.uv.new_timer() -- declared timer
timer:start(10, 0, function()
eq(-1, callback_result)
if -1 ~= callback_result then
-- window wasn't closed
vim.api.nvim_win_close(win_id, true)
end
-- removed done()
end)
end)
end) |
Cool.
Thanks for the notes on using async. I'll take a look at the references you provided; appreciated. So the No need to do the commit, thanks for taking a look. So much new stuff ... |
I'll update the OP, with status of the tests. But here's a detailed look at the Source the following The cursor move autocmd that triggers the callback does not happen until the script exits. I'm guessing its because the cursor isn't actually moved until it's in the top level main loop (if that's a viable concept) and the screen is drawn. Given this comment in
I had hopes; but who knows what the "other events" encompasses. I tried various local Popup = require 'plenary.popup'
local msgs = {}
local function add_msg(msg)
table.insert(msgs, os.date('!%T') .. ': ' .. msg)
end
local callback_result
local function callback(wid, result)
add_msg('CALLBACK' .. tostring(result))
vim.print(os.date('!%T') .. ': CALLBACK ' .. tostring(result))
callback_result = result
end
add_msg('Start')
callback_result = nil
vim.fn.cursor(1, 1)
local main_wid = vim.fn.win_getid()
local popup_wid = Popup.create("hello there", {
moved = "any",
callback = callback,
})
vim.fn.feedkeys(' ', 'x')
add_msg('Exit ' .. tostring(callback_result))
vim.print(vim.inspect(msgs)) Output showing callback after exit
|
@Conni2461 @AlejandroSuero (and any cognizant lurkers) I think this is ready. There's questions, but it seems to work as advertised. |
@AlejandroSuero The "failure" I'm seeing on my system is expected because I'm using
fails. |
@errael I suspect that this is the expected behaviour right? And when moving the cursor, then it prints something like:
|
tests/plenary/popup_spec.lua
Outdated
@@ -160,3 +303,4 @@ describe("plenary.popup", function() | |||
end) | |||
end) | |||
end) | |||
-- vim:sw=2 ts=2 et |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be removed cause it can mess up other peoples environments, better to keep it in your config.
Somewhere like path/to/your/config/after/ftplugin/lua.lua
if you only want to set it for lua files.
I leave you an example of using this in my config for Golang
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the use of a modeline is not the style in plenary.nvim. It's nice to have stuff local instead of global. Oh well. I'll take it out
While I'm figuring out lua... I'll use
autocmd BufRead */plenary.nvim/*.lua set sw=2 ts=2 sts=2 noet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be removed cause it can mess up other peoples environments, better to keep it in your config.
BTW, there's set nomodeline
or set modelines=0
to avoid modelines modifying your environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just came across :help editorconfig
Think of it like 'modeline' for an entire (recursive) directory.
Adding such a file to the plenary.nvim repo might be useful.
Also I applied the formatter on the file and got this diff The project uses StyLua for the formatting rules and this is how its applied later on CI. plenary.nvim/.github/workflows/default.yml Lines 45 to 55 in 2d9b061
You can either use the cli like |
I guess this is the expected behavior, no cursor move events until the screen is drawn with the cursor in a different location; but it makes it difficult to write tests. There is undoubtedly a way to do it, I don't know what it is; and it may not be worth the effort. To contrast, notice with vim.fn.feedkeys(' ', 'x')
+vim.api.nvim_win_close(popup_wid, true)
+
add_msg('Exit ' .. tostring(callback_result))
vim.print(vim.inspect(msgs)) that the callback is invoked before exit, and so that can be checked. Note the
|
Thanks, I'll checkout installing StyLua locally. |
12574a1
to
4f0bbe2
Compare
Updated after a review. I guess there may be no one still working with |
Update for StyLua of the runtime code in this PR. |
3e64044
to
41c4d03
Compare
Oops, forgot to remove the modeline. Done. @Conni2461 @tjdevries This PR fixes issues in existing popup code; see OP.
Looking for some advisement on getting reviews and merge or reject. |
Makefile
Outdated
test1: | ||
nvim --headless --noplugin -u scripts/minimal.vim -c "PlenaryBustedDirectory tests/plenary/$(TEST1) {minimal_init = 'tests/minimal_init.vim', sequential = true}" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to add this to the Makefile
targets I think it should be it's separated PR. But if @tjdevries or @Conni2461 thinks it's okay to leave it in this one, then it won't be needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the change. I'll maintain it locally.
tests/plenary/popup_spec.lua
Outdated
local function populate() | ||
local wnr = vim.fn.winnr() | ||
local bnr = vim.fn.winbufnr(wnr) | ||
vim.fn.setbufline(bnr, 1, { "--one--", "--two--", "--three--", "--four--" }) | ||
vim.fn.cursor(1, 1) | ||
end | ||
]] | ||
|
||
--[[ | ||
it("without moved", function() | ||
--async() | ||
callback_result = nil | ||
populate() | ||
local popup_wid = popup.create("hello there", { | ||
callback = callback, | ||
}) | ||
-- move the cursor, should not do callback | ||
vim.fn.cursor(2, 1) | ||
local timer = vim.uv.new_timer() | ||
timer:start(10, 0, function() | ||
eq(nil, callback_result) | ||
vim.api.nvim_win_close(popup_wid, true) | ||
--done() | ||
end) | ||
end) | ||
]] | ||
|
||
--[[ | ||
it("with moved", function() | ||
--async() | ||
callback_result = nil | ||
populate() | ||
local popup_wid = popup.create("hello there", { | ||
moved = "any", | ||
callback = callback, | ||
}) | ||
-- move the cursor, window closes and callback invoked | ||
vim.fn.cursor(2, 1) | ||
local done = false | ||
vim.defer_fn(function() | ||
--eq(-1, callback_result) | ||
--eq(0, callback_result) | ||
done = true | ||
end, 100) | ||
vim.wait(100, function() | ||
eq(0, callback_result) | ||
return done | ||
end, 60) | ||
--if -1 ~= callback_result then | ||
-- -- window wasn't closed | ||
-- vim.api.nvim_win_close(popup_wid, true) | ||
--end | ||
|
||
--local timer = vim.uv.new_timer() | ||
--timer:start(10, 0, function() | ||
-- eq(-1, callback_result) | ||
-- if -1 ~= callback_result then | ||
-- -- window wasn't closed | ||
-- vim.api.nvim_win_close(popup_wid, true) | ||
-- end | ||
-- --done() | ||
--end) | ||
end) | ||
]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this won't be used in the end, remove it along with the require("plenary.async").tests.add_to_env()
comment on line 2, but if you want to try and add the async testing functionality, you can head to async test folder and see how it's used there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took this out and stashed it. I'll reconsider adding it at a later time.
end | ||
|
||
-- TODO: Wonder what this is about? Debug? Convenience to get bufnr? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what this does if I'm not mistaken @tjdevries @Conni2461 it's that checks for vim_options.finalize_callback
to be (it could be null) and if does exists calls it, maybe there's a part of the code where it removes it or it's set to false, will look into that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vim_options.finalize_callback
The question is about why it exists at all. It was added with #513.
@xactlyblue Could you clarify the purpose of #513? It doesn't seem to have anything to do with popups.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah why it exists, that idk, if @xactlyblue could clarify on that regard, would be nice. I tried to find where it was being used or defined and this is what I got.
I added this to log when it's called or not:
Results from make test
:
Video demo when using Telescope
which creates a popup
:
finalize_callback-demo.mp4
Note
As you can see it adds the not called
log twice because I think Telescope
calls it twice for each one it creates. I used Telescope
3 times, and got 6 not called
logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried both in this PR and in master btw, in case it was related to something this PR was removing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if @xactlyblue could clarify on that regard
Hey.
I made that change a while ago to address a problem I was having where I needed to access some information about the buffer created for the popup (I forgot the details to be honest, but if you need them I could probably go through my dotfiles commit history to figure out what my specific use-case was at the time).
It just creates an easier way for the user to manually access the bufnr
and win_id
of the popup for whatever reason they might need it. There isn't any internal implementation or usage of it.
I probably should've added a comment explaining the changes to clear the purpose up, sorry for any confusion!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
creates an easier way for the user to manually access the bufnr and win_id
Thanks, no problem. Debug convenience. Do you agree there's no reason to keep it in a final product?
Consider nvim_win_get_buf(win_id)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I should have clarified: this change was meant to be accessible by the user (for whatever reason they may need to access the bufnr
and win_id
of a created popup).
I'm not really familiar with the inner-workings of plenary or it's API, so I apologize if this change was unnecessary, but I couldn't find any existing method to easily access the bufnr of a created popup via a callback, so I figured the simplest solution would be to add an optional callback to allow the user to access the bufnr
and win_id
as soon as they're available.
If I recall correctly my use-case had something to do with zindex/overlap issues in a plugin that allowed you to supply popup arguments to plenary, which is why I made it a callback (I guess I figured it was more useful/elegant to add a general callback for plenary instead of modifying the plugin itself) the user can supply.
I looked through my NeoVim configuration and I'm not currently using it so I personally don't mind if it's removed but I'm not sure if anyone else is making use of it in their own configurations (though I'd guess the odds of that are fairly slim considering it's not really documented anywhere and has fairly specific use-cases).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understood (I think). I didn't see a reason for it, other than convenience.
simple, existing method to access the bufnr of a created popup
I'm new to neovim
, I don't know what was available when. Currently nvim_win_get_buf(win_id)
or winbufnr()
gets the buffer number from a window. May be other ways.
I'm not asking you to remove it, just wanted to make sure there wasn't something I missed.
a2b6c91
to
cc176c9
Compare
(I'm looking at adding
mousemoved='any'
,close='click'
, andpopup_close()
to popups; came across a few things to fix first.)To reviewers
This is my first
neovim
related PR and my firstlua
code. Suggestions about style... welcome. Not sure how this repo handles reviews, so I'm tagging some names that have done some popup work (sorry for the noise). There's some TODO I scattered with questions, looking for feedback (would like to remove before merge). There's a probable bug in tbl.apply_defaults, noted in popup/utils.lua.@l-kershaw @fdschmidt93 @AlejandroSuero @xactlyblue @jesseleite
@Conni2461 @tjdevries
Fix
moved = 'any'
option.Before this PR, the popup option "moved = 'any'," gets an exception because of changes made to vim.lsp.util.close_preview_autocmd:
Those changes looks like a fix. The now private code from "...lsp.util" is copied in here and the the buffer numbers are added as needed for the new code.
Default the new option
enter
tofalse
Changed the default to false, so the behavior matches
vim
with no options; which is to leave the cursor where it was and not change the focus to the popup. Is there a place to note breaking changes? Wonder the reason for "enter" option?Fix callback
I couldn't get it to work in a simple case. Converted to an autocmd. Comments on potential timing issues? Accessing buffer in callback does work. There's some preliminary work to support "popup_close(win_id, result)" and mouse stuff for a later PR.
Update POPUP.md
Tests
The options
callback
andenter
are tested. The optionmoved
only has a partial test which verifies the option can be used (it fails without this PR). #622 (comment) details the problems I'm having with getting the tests to work. Will revisit if/when I understand the trick that's needed.Could also do ...
There's dict_default(). Would using tbl.apply_defaults make sense? Seems cleaner.
Should tbl.apply_defaults do a deepcopy of any table from defaults?
There was a comment around the callback setup.
I've removed the comment. The called back function may want to know the win_id; for example,
there could be a data structure associated with the win_id that can be freed.
PS: For the stuff I'm looking at adding, I could open a discussion or just do the PR and discuss there; recommendation?