Sublime Forum

New file icon themes specification

#1

Hiya,

I was excited to see that there’s better support for ‘file icon themes’ but when I came to look at the specification it seemed a bit less exciting to me.

The specification is in https://www.sublimetext.com/docs/themes.html#file-icon-themes and (at least here) appears in grey for 4.0 - although that’s probably just that it’s not been updated. Anyhow, the specification says:

{
    "icons": {
        // This matches any file with a .txt extension
        "txt": "file_type_text",
        // This matches any file called "Makefile"
        "Makefile": "file_type_make",
        "make": "file_type_make",
    }
}

Which seems interesting until I started to dig into it. The specification implies that a file txt and something with a .txt extension will get the same styling. That doesn’t feel very helpful. If I were to use t to match the .t extension commonly used to mark perl tests, then all of my temporary files (which I call t when redirecting) would also be styled that way.

I commonly have Dockerfiles for different purposes, labelled DockerfileLarge for example. There’s no way to match those - yes, I can change style to Large.dockerfile but that’s not quite as flexible as I was hoping.

Similarly, it’s not clear whether the key in the mapping was meant to match the whole name and the suffix of the name, or the whole name and the characters after the final (or first?) period. If it’s the suffix, then a file such a msgtxt would be coloured as txt, but I don’t think it would be suffix, because if it were suffix, the example would have been .txt to make such things safe. And if it’s not suffix, then I cannot match the suffix names like ,fd1 (a RISC OS BBC BASIC file in text format, eg Mandelbrot,fd1), which makes the new file icon themes less interesting.

And, there’s no way to mark files within directories as all being a given type - again, in RISC OS it is common to use c/* for C files, or s/* for assembly files.

The file icon themes seem like they’re useful for package authors, but sadly they’re less useful than I’d hoped.

Are there any hooks to be able to expand the file icons through plugins in these way so that I could expand the sidebar icons myself - I hadn’t found any, but that doesn’t mean I just haven’t looked hard enough.

0 Likes
#2

The primary innovation of .sublime-file-icons specification is to decouple file type specific icon definitions from the requirement for a related syntax definition to be present and to solve issues with conflicting icon definitions via file_type_xyz.tmPreference files.

Filename vs. extension matching works pretty much the same way as it has always been doing, despite those being matched case-sensitive even on case-insensitive filesystems.

A specified extension such as txt has always been matching files of that name or the file extension after a period. Thus mytxt has never been matched and so have my,txt or s/* not been.

Are there any hooks to be able to expand the file icons through plugins

File icons are defined in configuration files, such as classic tmPreference files or by new .sublime-file-icons files.

If demand for more sophisticated pattern matching to assign icons by location (e.g. tests/mytestfiles.ext) exists, file a feature request at https://github.com/sublimehq/sublime_text/issues, clearly describing expectations, ideally including examples.

0 Likes