-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Allow regex search #9228
Allow regex search #9228
Conversation
src/buffer/out/search.cpp
Outdated
// Regex iterators are not bidirectional, so we cannot create a reverse iterator out of one | ||
// So, if we want to find the previous match, we need to manually progress the iterator | ||
while (matches_begin != matches_end) | ||
{ | ||
desired = matches_begin; | ||
++matches_begin; | ||
} |
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.
There really should be a better way to do this
|
||
// Create the regex object and iterator | ||
std::wregex regexObj{ _inputString }; | ||
auto matches_begin = std::wsregex_iterator(concatAll.begin(), concatAll.end(), regexObj); |
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 the user accidentally types a pathological regex and the search takes too long, is there any way to abort it? It doesn't look like std::regex_iterator supports any kind of cancellation token.
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 wonder if cancellation could be implemented by throwing an exception from operators of a custom iterator type. Would there be a risk that such an exception can skip some cleanup in the regexp algorithm, or that the algorithm can copy part of the input to an internal buffer and then spend excessive time examining that buffer, without using the original iterators?
#8588 makes our searching much more efficient, so we will wait till that merges before merging this one. |
@check-spelling-bot ReportUnrecognized words, please review:
Previously acknowledged words that are now absentaef apos aspnet bc boostorg BSODs Cac ci COINIT conpixels cplinfo crt cw cx dahall DEFAPP DEFCON df dh dw eb EK ev exeuwp fde fea fmtlib gb gh Gravell's hc hh hk hotkeys HPCON hu isocpp Kd KF KJ KU KX lk llvm mintty msvcrtd Nc NVDA Nx oa OI Oj Oo oq Ou Ov pb pinam pv pw px py qi QJ qo QOL remoting ri Rl rmdir ru smalllogo splashscreen storelogo sx sy sz td tf tl tt uk ul Unk unte vcrt vf vk wx xa xamarin xy Yw yx YZ Zc zd zh ZM zu zySome files were were automatically ignoredThese sample patterns would exclude them:
You should consider excluding directory paths (e.g. You should consider adding them to:
File matching is via Perl regular expressions. To check these files, more of their words need to be in the dictionary than not. You can use To accept these unrecognized words as correct (and remove the previously acknowledged and now absent words), run the following commands... in a clone of the [email protected]:microsoft/terminal.git repository
|
@PankajBhojwani I'm tempted to close this and resurrect it after #15858 merges. Thoughts? |
Oh neat, this PR already got a SVG icon for |
Agreed! |
Gotcha. We'll resurrect... shortly 😄 |
Delete branch? |
Ah, the asset was a copy of the Case Search asset ![]() I was keeping the branch around because of the asset, but... yea. @lhecker @KalleOlaviNiemitalo asked about pathological regeces and cancellation, which we may want to address or at least consider in the followup PR |
Summary of the Pull Request
Initial stage of implementing regex search
Todos left:
References
#3920
PR Checklist
Validation Steps Performed