-
Notifications
You must be signed in to change notification settings - Fork 59.9k
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
Informing a regex syntax should include required slash separators #35234
Conversation
… in-place If we inform the user about how to make a case sensitive search using a regex syntax, do it with the regex delimitators in place, so the user: - Don't gets an error when copying and pasting the regex syntax to the github code search textbox. Error meaning it didn't find results because it lacks the regex slash separators. - Avoid the user to have to also find in the documentation how to enter a regex in the code search textbox. Have to find out it needs to use the slash separators.
Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines. |
Automatically generated comment ℹ️This comment is automatically generated and will be overwritten every time changes are committed to this branch. The table contains an overview of files in the Content directory changesYou may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.
fpt: Free, Pro, Team |
@nbenitez Thanks so much for opening a PR! I'll get this triaged for review ✨ |
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.
Hi @nbenitez 👋 I agree we can make improvements here. We should use the opportunity to make this more consistent with the rest of the article, so I've made a suggestion to amend your PR accordingly.
Thanks for your interest in the GitHub docs!
content/search-github/github-code-search/understanding-github-code-search-syntax.md
Outdated
Show resolved
Hide resolved
…code-search-syntax.md Co-authored-by: Ben Ahmady <[email protected]>
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.
Thank you! I'll get this merged now 👍
content/search-github/github-code-search/understanding-github-code-search-syntax.md
Outdated
Show resolved
Hide resolved
…code-search-syntax.md
Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues ⚡ |
If we inform the user about how to make a case sensitive search using a regex syntax, do it with the regex delimitators in place, so the user:
Don't gets an error when copying and pasting the regex syntax to the github code search textbox. Error meaning it didn't find results because it lacks the regex slash separators.
Avoid the user to have to also find in the documentation how to enter a regex in the code search textbox. Have to find out it needs to use the slash separators.
So this MR is about removing burden from the user when trying to find out how to do a case sensitive search in Github.
Why:
Because a user checking docs of GitHub code search syntax to know how to search with case-sensitiveness enabled, would have to do so in two separate places (one where the required regex syntax is informed (i.e.
(?-i)
) and when pasting that and see it does not work, he would then have to find again in the documentation how a regex syntax is inputted (i.e. using two slash separators/(?-i)/
).What's being changed (if available, include any code snippets, screenshots, or gifs):
Check off the following:
I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).
data
directory.For content changes, I have completed the self-review checklist.