Icons of symbolic links to directories

[Naheel-Azawy]

I have just noticed that the icons of links to directories look like files (ln=🗎). I guess the source shows the reason in icons.go:

case f.linkState == working:
	key = "ln"

Maybe it's possible to add something like ln-di? But some might complain about other icons too. Maybe better ignore checking if it's a link or not and just use the icon of the linked file? Not sure, what do you think?

[gokcehan]

@Naheel-Azawy I'm still trying to keep our color and icon configuration symmetric. And as you know color configuration is still somewhat compatible with ls colors. I think dircolors have an option for this in the form LINK target. Maybe we can implement something similar though I don't know if it is feasible in our code or not.

[Dimfred]

Maybe better ignore checking if it's a link or not and just use the icon of the linked file?
Ranger does it also like this the link has the same icon as the underlying file.

That would be really great to have an ignore, like when ln is not present in LF_ICONS to then take the underlying filetype.

[lorentzforces]

Old issue, but I was looking for discussion of link target colors and here I am.

I'd be willing to take a stab at getting something together for this.

It looks like right now the biggest hurdle is in how to represent that preference in the icon/color mapping; the code that determines how to style the entries in a directory looks pretty straightforward. I could see two options off the bat: we could either use some kind of special value (like a hardcoded string we stuff into the icon map or a field on a tcell.Style). The other option might be to redefine the styleMap and iconMap types to be structs with an additional boolean field called useLinkTarget or something similar, and check that when determining styling when rendering the UI. That has the disadvantage of requiring an update to any access to those types, but there aren't too many of them and the change would be pretty light. They're already defined as types, so we've got that going for us, at least. This seems relatively cleaner as an approach.

Any preference one way or the other? Happy to take any guidance.