Multi-language code highlighting in search results

Problem description

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.

How Search Results Look Today

sublime-text-search-results-without-highlighting

Preferred solution

How Search Results Could Look

sublime-text-search-results-with-highlighting

Immediately I hope you can see how eminently more parseable these results can be considering they contain similar code. It's my assertion that it's much easier to scan through results which one's used to seeing syntax highlighted in the same way: with syntax highlighting.

It's particularly odd that highlighting is available everywhere in Sublime Text except in Search Results. I understand why this might be a setting that could be disabled for some folks who might not prefer it, but the current behavior is inconsistent in my mind.

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.

Alternatives

An alternative would be to automatically support any language definition as a potential search result highlighting option. That certainly would make it more scalable.

PS: I originally posted this in a Sublime Text Forum discussion.

I like the idea of syntax highlighting in the find results buffer, but definitely it makes sense to have it as an option as it would reduce performance - having to syntax highlight entire contents of the file until the first match is found etc.

Which is also why the current implementation of doing it in the Find Results syntax definition is not effective, even aside from the manual mapping of extensions to syntax definitions (which would ignore first line matches, user customizations etc.) - the context lines returned for a match and included in the find results buffer wouldn't be enough to accurately get the correct syntax context to highlight from so the highlighting would be dodgy. I believe it would take some dedicated approach instead of the traditional view based on a syntax definition, so I'm marking this as a feature request instead of an enhancement :)

sublimehq / sublime_text