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

feat: add Terminal.find function #486

Merged
merged 1 commit into from
Sep 11, 2023
Merged

Conversation

willothy
Copy link
Contributor

@willothy willothy commented Sep 6, 2023

Very generic way of finding a terminal that should be adaptable to most use cases. I'm using it for finding a terminal by bufnr.

---@return Terminal?
function M.find(predicate)
for _, term in pairs(terminals) do
if predicate(term) then return term end
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if only a well defined subset of the terminal's fields be passed ot the predicate so people can't do undesirable things or use private fields or trigger side effects here that they shouldn't 🤔. I'm sure some some people are already doing stuff like this but I worry about users getting used to operating on the whole terminal in a way that a lot of people become dependent on private fields.

The cat might already be out of the bag on that one though since lua doesn't really support privacy for fields

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm definitely doing a lot of janky things in my config taking advantage of Lua's lack of privacy haha (haven't needed to do so with toggleterm, though). I'm not really sure about this specific case - the idea makes sense, but the function will return a full Terminal object that will be exposed either way, so that would really only avoid mutation in the predicate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would be better to expose one or two functions for filtering terminals by bufnr or name, etc. and avoid using a higher order function entirely?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 I guess it's always been the case that users can interact with the terminal directly and I have advised in the README not to use the private methods but I'm sure some users will anyway 🤦🏾‍♂️, I guess more specific functions will just lead to future requests for more variants so probably one function that is super generic is better

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, that makes sense. Let me know if there are any changes you'd like!

I think with Lua it's almost impossible to make something private, even locals can be retrieved with debug.getupvalue, so I'm not sure it's worth spending much energy on haha

@willothy willothy force-pushed the term-find branch 2 times, most recently from c160dee to fccfcc8 Compare September 6, 2023 13:07
@willothy
Copy link
Contributor Author

willothy commented Sep 7, 2023

Anything else you want changed here? If you're not interested in merging this that's alright, pretty much the same behavior can be achieved with vim.iter(terminal.get_all()):find(...) as long as #487 gets fixed. Happy to make any changes or close if this isn't wanted :)

@akinsho
Copy link
Owner

akinsho commented Sep 7, 2023

Nope no changes needed, I'm just more focused on personal projects of mine in my free time so can only afford a few mins here and there to look at neovim OSS stuff. This generally looks fine just want to make sure I don't carelessly merge (which I've done in the past) without thinking if this might produce future issues (don't think it will though)

@willothy
Copy link
Contributor Author

willothy commented Sep 7, 2023

Nope no changes needed, I'm just more focused on personal projects of mine in my free time so can only afford a few mins here and there to look at neovim OSS stuff. This generally looks fine just want to make sure I don't carelessly merge (which I've done in the past) without thinking if this might produce future issues (don't think it will though)

Totally, no rush!

@akinsho akinsho merged commit 01a84bc into akinsho:main Sep 11, 2023
3 of 4 checks passed
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

Successfully merging this pull request may close these issues.

2 participants