Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use font dimming to communicate modification/creation time #1222

Open
cohml opened this issue Jul 24, 2023 · 0 comments
Open

Use font dimming to communicate modification/creation time #1222

cohml opened this issue Jul 24, 2023 · 0 comments

Comments

@cohml
Copy link

cohml commented Jul 24, 2023

The title is probably a terrible description of the idea, but best I could do in limited space. Let me try to unpack it:

What I'm referring to is exactly what the project k does, where it calls this feature "rot" (gross to me, but I digress). Here is a visual example.

In prose: The font color of the date/time beside each file - be it creation, modification, or whatever - should be dimmer for dates that are older, and brighter for dates that are newer. This would give an immediate visual indication of which files are more important/relevant for the user at the present time.

I could see the dimming function coming in two modes, either of which would be very useful:

  1. absolute (e.g., if all files displayed were modified either today or yesterday, all should be bright; only files modified a while ago should be dim)
  2. relative to only the files displayed (e.g., regardless of absolute distance into the past, the least-recently-modified file would be dim, and the most-recently-modified file would be bright)

Ideally, the ability to toggle between these modes, or at least to set your preferred mode via an environment variable, would be super awesome. Not sure how feasible that would be to implement though.

For terminals which support the 256-color scheme, or even more, this should be doable regardless of hue, so not just black/white/gray.

Project k is written in shell code whereas exa is in Rust. But hopefully the former could still provide some useful ideas for implementation.

Anyway, curious to hear your thoughts of usability and feasibility!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant