Thank you for the PR! I have some change requests:

• The path.is_symlink() is a time-consuming IO operation, and the current implementation does additional IO operations for each file on every match. We can modify the path parameter of matches to file and pass the entire File struct containing preloaded metadata. You can get the necessary data through file.cha.

• Please change typ to kind and create an enum to represent it, like enum FiletypeKind { Symlink, Executable }.

• It seems that mode_bin.len() is not always 16. Perhaps we can use constants from libc to better implement it, similar to what permissions() does.

Should we move the FileKind enum in a separate file or is it fine to keep it there?

It seems that mode_bin.len() is not always 16. Perhaps we can use constants from libc to better implement it, similar to what permissions() does.

Checking if it's not a directory should be enough right?

Should we move the FileKind enum in a separate file or is it fine to keep it there?

It seems that mode_bin.len() is not always 16. Perhaps we can use constants from libc to better implement it, similar to what permissions() does.

Checking if it's not a directory should be enough right?

Nope, I mean you can use something like libc::S_IXUSR constants here instead of hardcoding it - libc will help us to define its value automatically, it may have different values on different platforms.

Also we don't need to check is_dir(), this will limit it to only available for files but not available for directories, if users need only apply it for files/directories, they can add additional constraints like name = "*" or name = "*/".

I can't wait to release v0.2.0, let me finish the next work of this PR! 😆

Nope, I mean you can use something like libc::S_IXUSR constants here instead of hardcoding it - libc will help us to define its value automatically, it may have different values on different platforms.

Alright, no problem.

Also we don't need to check is_dir(), this will limit it to only available for files but not available for directories, if users need only apply it for files/directories, they can add additional constraints like name = "*" or name = "*/".

Well, if we don't check is_dir() all directories will be highlighted as executable files, and that's not the intended behavior...

I added some other filetypes support, let's merge it then.

Docs added here https://yazi-rs.github.io/docs/configuration/theme#filetype

Thank you very much, guys, for this excellent addition and for closing my original issue with it.

Just noticed the following:

is = "exec" seems to have a higher priority than is = "link", even for links to non-exec files.

With

{ name = "*/", is = "exec", fg = "green" }

(which does not make sense for folders) all linked folders a colored as executables.

If you set the color codes for exec files below linked files and folders, everything works correctly:

[filetype]

rules = [
	{ name = "*", is = "orphan", fg = "red" },
	{ name = "*/", is = "orphan", fg = "red" },
	{ name = "*", is = "link", fg = "cyan" },
	{ name = "*/", is = "link", fg = "cyan" },
	{ name = "*", is = "exec", fg = "green" } # <- has to be last rule
]

Not quite sure whether this is a tiny issue.

Thank a lot!

Hey @Brixy, I'm not quite sure if I understand your meaning. Which files do you want to highlight, and which files do you not want to highlight at the same time?

Hey @Brixy, I'm not quite sure if I understand your meaning. Which files do you want to highlight, and which files do you not want to highlight at the same time?

With the complete setting posted above everything works as expected. So, there is no real problem.

I just noticed that exec needs to be placed below link.

If you use

[filetype]

rules = [
	{ name = "*", is = "exec", fg = "green" },
	{ name = "*/", is = "exec", fg = "green" }, # makes no sense ;-)
	{ name = "*", is = "orphan", fg = "red" },
	{ name = "*/", is = "orphan", fg = "red" },
	{ name = "*", is = "link", fg = "cyan" },
	{ name = "*/", is = "link", fg = "cyan" }
]

all symbolic links are green, i.e. marked as executables -- although the links lead to non-executable files and folders.

Maybe yazi qualifies links as exec files in general?!

Please ask back if I did not make this clear. I am not sure whether this is an issue anyway.

{ name = "*/", is = "orphan", fg = "red" } is meaningless; when a link is an orphan, it can only be a (pointing to an invalid location) file.

I think I understand what you're saying, but it's not that links take precedence over executable files; in fact, they coexist.

Let's say:

• a points to b, where b is present and an executable file, then a has both "link" and "executable" properties
• a points to c, but c doesn't exist, then a only has the "link" "orphan" property (fixed in 8533445).

I think this makes sense; when a file is a "link" pointing to an "executable", users can choose to present it either as a "link" or as an "executable" file.

Thanks a lot for your commit and your answers!

I think this makes sense; when a file is a "link" pointing to an "executable", users can choose to present it either as a "link" or as an "executable" file.

Yes, totally 😀

Please allow one last question -- which is a shortform of my clumsy initial question.

If you have a pointing to b (but b does not exist) and this setting

[filetype]
rules = [
	{ name = "*", is = "exec", fg = "green" },
	{ name = "*", is = "orphan", fg = "red" },
]

I would expect the orphan a to be red, but it’s green. Is this intended? (It’s no problem to swap the rules, of course. Just asking in case it’s important for you.)

Yeah this is as expected, orphan files (or link files themselves) in Linux are files with special properties that have both rwx - you can verify it with ls -al.

I think we should follow this convention, separating the x property from it looks a bit strange. 🤔

I think we should follow this convention, separating the x property from it looks a bit strange. 🤔

👍

Oh sorry. I did’t ls -la, but just compared this case with some other terminal file managers.

Thanks for your patience!