Sync sort order and the time field (long view) if sorting by time

[leo-arch]

If sorting by time (atime, btime, ctime or mtime) it makes sense to have the same time in the long view time field, no matter what the PropFields option says. Of course, if not sorting by time, whatever specified in PropFields stands.

For example, if I switch the sorting order to birthtime (via the st command), use birth times in long view, and if I switch back to name or version (or other no-time order), revert back to the value specified in PropFields (by default modification time).

Also, I assume it would be nice to have a way to force the PropFields value, disregarding the current sorting order.

@muellerto, you're a heavy long-view user, what do you think about this?

[muellerto]

@muellerto, you're a heavy long-view user,

Yess!!

what do you think about this?

It's rather simple: an interactive made setting should always have priority compared with a configuration setting. When the user decides interactively to sort the files differently from PropFields the files get into this order. In the long view it wouldn't make sense to show then another time than the one which is the current sort criteria. May be the sorting was made because this specific time plays a role, so the user should see it.

A question is still what to do when the configured sort criteria is a time different from PropFields, that's also possible. I think (also to simplify the code) this case can be handled the same way: when a time is a sort criteria this time should be displayed in the long view.

Two more ideas:

• It could be clever to make visible which concrete time is shown. You could place an a, m or c after the timestamps and darken this letter a bit, so that it's not so conspicuous:
  
  Indeed you could always mark any timestamp like this to make clear what it is. OK, such a letter must still be checked if it is useful (and not disturbing) in every case depending on the TimeStyle property. An idea would be to make a new fake-%-option in TimeStyle for this letter, so the user can place it where he wants or avoid it completely. Think about %k (for "kind") or %o (for "origin").

• Make an interactive command like ti (time), which sets a concrete kind of timetamps (ti a, ti c, ti m) for display. Then the user could sort his files by access time and see also creation time or last modification when he wants.

[leo-arch]

I like your ideas, Working on it.

[leo-arch]

First implementation is ready (dafe443).

Add these options to the configuration file (below TimeStyle):

# If sorting files by time, use the same time files are sorted by for the time
# field in long view (disregarding the value set in PropFields).
TimeFollowsSort=true

# Append an 'a', 'b', 'c', or 'm' to the timestamp (long view only) to indicate
# the kind of timestamp, i.e, access, birth, status change, or modification
# time respectively.
TimestampMark=true

TimeFollowsSort defaults to true, and TimestampMark to false.

Note: Why not %k? Cool, but works only for custom timestamps (not for default or relative timestamps). The ti command? May be useful, but not a priority now.

[leo-arch]

Added a new color code (dt) to colorize the timestamp marks (a, b, c, and m). If unset (this is the default), the current timestamp color gets dimmed (darkened). Otherwise, the specified color is used.

Why? Dimming is not a universal solution: 1. If the color currently used by the timestamp is already dimmed, dimming it makes no effect (and the timestamp mark will have the same color as the timestamp); 2. some terminal emulators (i.e. Alacritty), refuse to dim colors in the 256-colors range. For these reasons, adding a color code for this could be useful.

[muellerto]

Sorry, I'm a bit delayed. I had a 100% crash on my Windows machine after installing an ordinary Windows update, it didn't boot anymore, I got an endless loop of bluescreens ... (must install everything new in the next days ...)

Looks good in the most situations.

When TimeStyle is set to relative you have mostly letters and then an additional letter without a gap, looks a bit strange. That's what I said, we must check if it's always useful and doesn't disturb. In this case (relative) it would be better to have a separator like a space, but the space is also the column separator. I would also accept one of ": ; ' | / - ( [" between the time and the letter.

[leo-arch]

I had a 100% crash on my Windows machine after installing an ordinary Windows update

Sadly, it sounds so familiar.

As to relative timestamps, the current implementation allows two approaches:

1. Disable timestamp marks (far from ideal, I know)
2. Use a completely different color (underline it or something else), to make it standout.

CamelCase comes to my mind. What about using uppercase characters whenever we're using relative times?

[muellerto]

As to relative timestamps, the current implementation allows two approaches:

Disable timestamp marks (far from ideal, I know)
Use a completely different color (underline it or something else), to make it standout.

CamelCase comes to my mind. What about using uppercase characters whenever we're using relative times?

I think (but it's mostly a matter of taste) this additional letter should be as inconspicuous as possible because it's rather a specialist feature. Normally the origin of the timestamp is not of interest but when it is you should see it just using your eyes. That's why I say dimmed (almost invisible) lowercase letters are the optimum. Also having relative timestamps this would be a good solution because the last letter is recognized as something different, it doesn't belong to the word before.

The uppercase letters do the job as well. But someone will come and ask why these letters are different from the other timestamp modes :-) Generally I could also live with a real delimiter, 2024-08-01 17:34:56'm or 32 min'm.

BTW if you put the letter at the begin of the timestamp the problem is much less: m2024-08-01 17:34:56 or m32 min (OK, looks also strange ...)

[leo-arch]

someone will come and ask why these letters are different from the other timestamp modes

True. I'll bear all this in mind.

This feature needs to be enabled manually. So, I guess making it clear in the config file that M and m are the same thing should be enough for anyone wondering about this difference.

Btw, using uppercase always wouldn't be any better, isn't it?