For use in Sublime Text's "Find In Files..." Dialog (⇧⌘F)
These are some useful templates for regex strings to use in the "Find:" field
Frequently, I end up searching for code that I have a rough memory of, but not one specific enough to quickly come up with a single, efficient thing to search for. However, I can almost always remember the general shape and structure of things well enough to come up with a pretty unique pair of things to search for that should only occur in close proximity to one another a few times throughout the project.
\b[[term-1]]\W+(?:\w+\W+){[[1]],[[10]]}?[[term-2]]\b
Returns all instances of [[term-1]] that are at least [[1]] but no more than [[10]] words away from [[term-2]] -
- Just replace
[[term-1]]and[[term-2]]with the strings you want to search for [[1]]and[[10]]are quantifiers which define the minimum and maximum number of words allowed between the two search terms to return a match- Using
[[1]]as the minimum would mean that any instances where the two words were adjacent would not be considered a match - You would need to use
[[0]]instead
- Using
- NOTE - Be sure to remove the brackets
[[ ]]when inserting search terms and choosing quantifiers
\b(?:[[term-1]]\W+(?:\w+\W+){[[1]],[[10]]}?[[term-2]]|[[term-2]]\W+(?:\w+\W+){[[1]],[[10]]}?[[term-1]])\b
Same as above, but will find the terms regardless of which order they are in -
- Variation 1 will only return instances where
[[term-1]]comes before[[term-2]] - Variation 2 essentially just adds an OR and then repeats the search string with the
[[term-]]values flip-flopped
\b([[term-1]]|[[term-2]]|[[term-3]])(?:\W+\w+){[[1]],[[10]]}?\W+([[term-1]]|[[term-2]]|[[term-3]])\b
Allows you to search for more than just 2 values -
- Results will be returned if any 2 words in your list are found within the defined proximity of each other
- This example only adds 1 extra word, but using the syntax illustrated, you could add as many extras as you'd like
- I wouldn't recommend going much higher though - for both performance and logic reasons 1
- As compared to Variation 2 only the list of search terms gets repeated, as opposed to the entire set of search parameters, so that's better-ish
- It occurs to me that I'm not 100% certain what will happen if all three search terms are found within the defined range of proximity
- My guess though, would be that it shouldn't break anything too thoroughly, you would just end up with a set of results that included each combination listed as a separate match, even though they all pointed back to the same chunk of code 2
I'd be willing to bet that there's a much more succinct way of accomplishing all this, but these ones work, and I'm still very much in the early stages of learning regex - That being said, if you have any suggestions for improving those strings, I'd love to hear them.
These are some useful strings to use in the "Where:" field to make your search run faster, and avoid cluttering your results with, say, the entirety of jQuery in it's minified format, or all of the libraries you're pulling in with npm/bower/etc.
*.js,*.tpl.html
Say you're looking for a style attribute that's getting added dynamically and throwing off your selectors, because it gets added as an inline style instead of toggling a class - based off of that you know that it's almost certainly in either a full-blown .JS file, or a script tag somewhere - Combine that with the knowledge that even though our (hypothetical) values are used pretty commonly throughout the CSS, there are probably only a handful of instances that it occurs in the JS.
So you could exclude all the CSS files ( -*.css ) from your search and hopefully trim down the number of search results, keeping them more focused (and more likely to be relevant) as well as reducing the number of files being searched by a little bit. However, excluding CSS explicitly will still search every single fille of any other file-type.
-*.min.css,-*.min.js
-OR-
-*.min.*
-*/bower_components/*,-*/npm-modules/*
Because there's (usually) a lot of them, and they're long but minified - so you still end up with the full code being considered as "context" for your search results. Also, you shouldn't be editing them anyway.
I'm sure it affects overall search performance, and in general, adding more possibilities to match against will result in more matches being returned - which is good, I suppose, if you've run a more limited search already and the code you're hoping for is not showing up - but if you get back a huge list of questionable relevance then that defeats the entire purpose of searching in the first place. So, actually, I bet you could probably write a search with enough parameters, and a large enough range of proximity that (depending on your system specs and the size of your code base) it would in fact hang or crash Sublime Text - but I think you'd have to be trying fairly deliberately to do that