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

Should xml_find_function_calls()` land on on the parent expr instead? #2431

Open
MichaelChirico opened this issue Dec 13, 2023 · 1 comment · May be fixed by #2496
Open

Should xml_find_function_calls()` land on on the parent expr instead? #2431

MichaelChirico opened this issue Dec 13, 2023 · 1 comment · May be fixed by #2496
Labels
internals Issues related to inner workings of lintr, i.e., not user-visible performance
Milestone

Comments

@MichaelChirico
Copy link
Collaborator

MichaelChirico commented Dec 13, 2023

WDYT about xml_find_function_calls() landing on //SYMBOL_FUNCTION_CALL/parent::expr? It seems like most XPaths start there.

Originally posted by @MichaelChirico in #2357 (comment)


Alternatively, it could be an option that is TRUE by default. Or with levels, land_on = c("parent", "self", "parent::parent"). I think that would make the issue of documentation easier.

@AshesITR
Copy link
Collaborator

Adding 3.2.0 because we can't change the public API easily once it got to CRAN.

@MichaelChirico MichaelChirico added performance internals Issues related to inner workings of lintr, i.e., not user-visible labels Dec 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internals Issues related to inner workings of lintr, i.e., not user-visible performance
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants