But does ANYONE actually like the /* icon? I think the icon should not look like text at all. The filename is text, the icon should look like an icon. I think this should be reconsidered. And even worse: it starts a comment block. I don’t think this was thought out well enough. But maybe I’m just minority here. What do others think?
I want to emphasize that I have only seen the screenshots. I have not used the new theme/dev versions.
Maybe some outline/border could improve the icon. I don’t know. Don’t know the reason why the old icons had to be changed. (I think this has been discussed in another thread, maybe it has been reasoned there too.)
EDIT: This is the resoning by wbond:
The primary motivation for the various icon choices was to have a symbol that was abstract, but all visually distinct. Previously all of the icons used a similar page outline that made it difficult to scan for different file types. The new icons are crisper, eschew the paper outline, and should hopefully be fairly easy to distinguish without a detailed look.
Not sure if the crispyness and distinctiveness outweight the problems, though.
What icon is this? I am using build 3142 and quite do not remembering seem it. Do you have some screenshot?
What problems are you referring to? I’m not sure I’d consider liking the icon, or lacking a “paper” outline to be a problem. Those seem to be more of a preference.
Exactly. This is not a matter of taste. ‘/*’ has a specific meaning - it’s a wildcard for all files, and doesn’t make sense to display besides a single file. A simple empty document icon ‘[ ]’ as almost every other app uses would suffice perfectly.
It is also the beginning of a comment in very many programming languages (C/C++, PHP, CSS, JavaScript, Go, D, Java, Swift, Rust), which is why I chose it.
The entire UI can be changed, you can tweak this yourself, or use one of the hundreds of other themes. There is full documentation on the theme engine at http://www.sublimetext.com/docs/3/themes.html.
I feel your pain. I am also bugged by the /* icon – mostly because A)) it looks like text and B) an asterisk is very often used to indicate a changed/unsaved file.
You can configure the icons for source files to be the same as for default (unknown) file types:
open command palette -> Package Resource Viewer: Open Resource -> Default -> Icon (Source).tmPreferences
inside, replace “file_type_source” with “file_type_default” and you should no longer see the /* icons.
For me that is proving a painful decision. My mind is seeing a long list of unterminated comments. It’s tripping my syntax error fuses and this hurts my productivity.
I took a look at “File Icon” but it is a source of more visual noise again.
Is the icon configurable? If not, please make the file icon configurable (edit: it is, thanks kolega). But even that won’t help for pair work, I can’t force my preferences on a colleague.
Thank you so much for this solution! The /* as an icon is insanity IMHO. It feels like my entire project won’t build because there are open comments everywhere.
Cheers!
Also not a fan of that icon. Not a deal breaker but having the start of a comment as the file icon just seems wrong. If it was surrounded in a box to make it look like a file it wouldn’t be as bad.
The new theme for ST3 looks good, especially it also provided the “adaptive” one.
But regarding the asterisk icon, I agree with Paapaa and benfrain.
Now in latest ST3, all my code files showing "/" everywhere in my project file panel looks wierd.
1st, they do not look so intuitively as file icons. They have no background-shape. And they do not have border. At the first glance of my opening my code project with ST3, I was even guessing the / is indicating a folder structure sense of parent-and-children.
2nd, a “/*” might also not be quite suitable as a file type for code. In my own opinion, I suppose a “[]” or “<>” is much more often used as indicating a coding file type.
Understood @wbond and I’m glad it can be changed. 
I think the main thing people are saying here is that it’s not an ideal default - as @benfrain said just adding a box around it would be fine.
@inopinatus use the color option with ‘A File Icon’ - it will make the icons greyscale, less noisy and fit in the the ST3 final theme.
This has the unfortunate side effects of:
There are a number of constraints that we face in the default theme. Part of it is that the color in the Sublime Text interface is dominated by the colors in the user’s color scheme. So we can’t really use color to distinguish files/folder icons from each other. Instead, we really need to work with monochrome, which requires we rely more on shape.
Previously all of the file icons followed the pattern of a piece of paper, with a folder corner, and a small symbol in the middle. Unfortunately the space available for the symbol was so small, and the paper outline dominated the shape so much that the icons effectively provided no differentiation. The current set of icons was an attempt at:
From user feedback, it appears that the symbol /* is confusing for a small subset of users, so I’d say we haven’t found the ideal solution for an icon that means “source code”. That said, adding a border around the symbols for source code, markup and text seems less than ideal since it negatively affects our attempt at addressing 1 and (to a lesser degree) 2.
Some have implied that the fact that it is a comment symbol is the main source of their confusion. Another set of users have implied that the fact that it is unbalanced (no closing comment marker) is part of their confusion.
The best suggestion I’ve heard for a possible alternative symbol is {}, which isn’t as distinct from <> (used for markup) as I would like. To some it also implies more of a CSS files that “source code”.
In the end I’m not sure if there will be a “perfect” solution possible, but I am going to continue to brainstorm and see if it makes sense to try and tweak the icon in a future release.
Until then, the small subset of users should feel free to try an alternative theme, or install a package like “A File Icon”.
Quick fix. Open the zip file Theme - Default.sublime-package take out the icons. Delete everything other than these three files:
file_type_default.png
file_type_default@2x.png
file_type_default@3x.png
run script to fill in the rest with the correct file icon:
cp file_type_default.png file_type_binary.png
cp file_type_default@2x.png file_type_binary@2x.png
cp file_type_default@3x.png file_type_binary@3x.png
cp file_type_default.png file_type_css.png
cp file_type_default@2x.png file_type_css@2x.png
cp file_type_default@3x.png file_type_css@3x.png
cp file_type_default.png file_type_image.png
cp file_type_default@2x.png file_type_image@2x.png
cp file_type_default@3x.png file_type_image@3x.png
cp file_type_default.png file_type_markup.png
cp file_type_default@2x.png file_type_markup@2x.png
cp file_type_default@3x.png file_type_markup@3x.png
cp file_type_default.png file_type_source.png
cp file_type_default@2x.png file_type_source@2x.png
cp file_type_default@3x.png file_type_source@3x.png
cp file_type_default.png file_type_text.png
cp file_type_default@2x.png file_type_text@2x.png
cp file_type_default@3x.png file_type_text@3x.png
Put the new files back into the zip file. Done. Now your files aren’t commented out anymore and all files just look like files.
That proposal is not recommendable.
Any manipulation to default packages located in ST’s installation directory will be overwritten uppon application upgrade.
Do not manipulate them!
It’s preferable to having my files look like they were commented out. Instead of telling me it’s not recommendable, tell me where I can make this simple change so it wont get overwritten upon application upgrade.
Make a folder in Packages named Default, put inside of it only the files you want to change or replace using the exact same path inside of the folder as they have inside of the extracted package.
Those files will now always be present and will override the versions in the sublime-package file of the same name, even if that package gets replaced.
Thus your changes won’t get lost. I would recommend you install OverrideAudit as well. With those files in place, they will block any update that might happen should the default theme ever change; overrideaudit will tell you when that is happening so you can take appropriate action.