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
show test_that() calls in document outline #11108
show test_that() calls in document outline #11108
Conversation
Separated this from #11102 because it's really two different things |
startPos, | ||
ScopeNode.TYPE_BRACE, | ||
{ | ||
"name": "✅ " + desc, |
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.
IMHO we should just use the name as-is, and consider an icon or styling (if any) on the GWT side.
(In addition, some fonts have trouble rendering certain UTF-8 symbols, so if we do want an icon or embellishment I think we should use an image)
It might also suffice to just use italics for the text label, or something similar, or leave the quotes in (since only test names would be quoted)
So cool to see this in progress 😁 🙏 |
71ff5a1
to
7000105
Compare
I think leaving the quotes is overwhelming, and an icon or emoji as before would be too much. We would rarely functions and tests anyway in a single test file. It's better practice to have helper functions in separate files. cc @jennybc you might have views here. |
This looks very nifty! It's interesting that this intersects with the question of "what about code in the test file that's not inside What happens currently in this PR in the document outline for top-level code outside of |
Not much because the outline would only show functions and sections. but we could treat functions differently depending whether they belong or not. but maybe it's more a job for source marker annotations ? Or some more ambitious dedicated "Test" pane that would enforce good practice. |
I think not appearing in the outline (non-function assignments) or appearing in a different colour (function definitions) is reasonable. It weakly discourages and signals that a bunch of |
For existing prior art, if users have opted into showing both chunks and sections in the document outline: The display is like so: That is, we use italics for the chunk names, to visually distinguish them from other sections. However, it's possible (as @maelle said) that italics could become overwhelming if every entry in the document outline were italicized, though. Can you share a screenshot with test labels using italics + no extra color, for comparison? As an aside, if we choose a color for the text we need to make sure it remains visible in different editor themes (especially Solarized and dark themes). We could also invert the relationship and choose to display R functions with italics for test files, and regular tests with "normal" styling. (I guess my bias would be mildly towards "regular" styling, but choosing to italicize R function names within a test file) |
d660c29
to
684b489
Compare
is this enough contrast for all users? |
* update rstheme * update expected rstheme
* update plot french text * more * tracé -> graphique * plural
* uiLanguage* properties in french * add trainling : in fr and en
support for 'editor' metadata options in files and projects
* index test_that calls for fuzzy finder * use moveToNextSignificantToken() * Don't unclude test_that() in the string * rm quote from test desc * make removeQuoteRegex static const * testThatCAllIndexer adds "t " prefix * only show test items if the search term starts with "t " * fuzzy finder removes artifical "t " prefix * remove dead code * When search term starts with "t ", only include test items * not looking for files and C++ items when only looking for test items * NEWS * factor out includeTestItems * handle raw string in test_that(<raw string>)
I like this as well. However, I agree we need to make sure the contrast remains high enough. If you're testing with a development build of RStudio Server + Chrome, you could use the built-in DevTools color contrast ratio checker: https://juxtdesign.cc/guides/using-chrome-dev-tools-for-color-accessibility/ I think an opacity around 0.8 would probably be more appropriate. |
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.
Code otherwise LGTM; I think we can merge once we've found an opacity that prefers contrast while de-emphasizing functions visually.
Co-authored-by: Kevin Ushey <kevin@rstudio.com>
…b.com/romainfrancois/rstudio into feature/test_outline_navigation_11082
😬 I messed up with the merging, so I see a bunch of unrelated changes, but I suppose it should be fine if squashed. |
Thanks! 0.7 looks good to me there as well -- 0.8 doesn't look visually distinct enough. |
* rm duplicate code, merge hiccup from #11108 * look for quarto style labels, i.e. #| label: <name> * Extract chunk labels from #| label: also in visual mode * use \s instead of space * update comment
Intent
addresses #11082
Approach
Specializes
TYPE_BRACE
fortest_that()
calls.Using emoji ✅ instead of having redundant
test_that()
everywhere.But using
test_that()
in the thing below:Automated Tests
QA Notes
Checklist
NEWS.md