jeremypw
commented
1 week ago Files gets the displayed "Type" field from a FileAttribute (STANDARD_CONTENT_TYPE or FAST_CONTENT_TYPE) associated with the file. This is probably why the result may vary - it depends on what mime-type was given to the file. Could you check on the Properties of the .typ files with different Type descriptions to see what MIME type they have?
A quick look at /usr/share/mime/globs (on OS7.1) indicates there is no system level association of the extension *.typ with any mime-type. usr/share/mime/types shows that there is at least one mime-type (text/x-objcsrc) recognised as an Objective C source file.
So it looks like some of your files do not have sufficient metadata for the system to determine their exact type and it cannot be recognized from the extension so it is regarded as generic text. There is not a lot Files can do about that.
It is possible to register a new mimetype-extension association (this is often done by applications to register their own custom extension/mimetype/icon), but which ones are present out of the box is a system level responsibility I think.
What Happened?
In the list view, Typst files (.typ) are recognized as Objective-C files sometimes, rather than always falling back to a generic text file
Steps to Reproduce
.typfile.typfileExpected Behavior
I would expect the file browser to either fall back to recognizing a file as a generic text file if it doesn't know what the extension is. Alternatively, add Typst source file as a recognized file type
OS Version
7.x (Horus)
Session Type
Classic Session (X11, This is the default)
Software Version
Latest release (I have run all updates)
Log Output
No response
Hardware Info
No response