Is this on the cards for a future version/release? Would be super nice.

I’ve been using Sublime Text for over a decade and this is a recurring frustration especially when trying to quickly look through similar files using search.

This Gist offers a fairly hacky but surprisingly easy way to get syntax highlighting in Search Results by extracting the Find Results.hidden-tmLanguage template and adding definitions for specific file extensions and languages using the PackageResourceViewer extension.

This is something I’ve had to do a lot in the past to make up for shortcomings in customization for theme-specific things in Sublime, but considering Sublime already has a register for extensions and languages, it makes little sense to me that I would have to add such simple definitions to a “hidden” file.

For the record, all I had to do in order to see TypeScript files highlighted in Sublime Text search results (yes, this is a search engine trap) was to add the following snippet to the Gist I linked above:

<!-- TS -->
		<dict>
			<key>begin</key>
			<string>^([^ ].*\.ts:)$</string>
			<key>beginCaptures</key>
			<dict>
				<key>1</key>
				<dict>
					<key>name</key>
					<string>entity.name.filename.find-in-files</string>
				</dict>
			</dict>
			<key>end</key>
			<string>^[^ ]</string>
			<key>patterns</key>
			<array>
				<dict>
					<key>include</key>
					<string>#line-numbers</string>
				</dict>
				<dict>
					<key>include</key>
					<string>source.ts</string>
				</dict>
			</array>
		</dict>

Almost none of this is necessary, this entire XML file could be replaced with a simple object/dictionary to map file extensions using regular expressions to relevant language highlighting, which Sublime already offers:

highlight_map = {
  /^([^ ].*\.html:)$/ => "source.html",
  /^([^ ].*\.css:)$/ => "source.css",
  /^([^ ].*\.js:)$/ => "source.js",
  /^([^ ].*\.ts:)$/ => "source.ts",
}

So let me join the original poster from wayyyy back in 2011 in asking, once again, can we please have this feature in Sublime Text… 4th of its name? Thank you.

Interesting approach.

Things tend to get burried in this forum. Feature requests are better placed at

I see possible challenges to overcome some limitations of such a simple approach:

1. Find syntax would literly need to import/embed each existing syntax, which may be possible as ST4 is the first release which lazy loads embedded syntax definitions. It would have resulted in well known 25000 contexts exceeded error in past.
2. Find results start at arbritary file locations. Thus it’s very likely a syntax definition to not pick up context correctly which causes highlighting issues.
3. A static map of file extensions may work for personal use, but may cause more issues/confusion in real in general use. A static map which needs to be adjusted manually doesn’t help much here. Scopes would need to be set with information from the file searched in.