feat: add new file marked state

[sxyazi]

No description provided.

[Rolv-Apneseth]

With this change, I believe the marker style should override the style for yanked files as well, so you can clearly see what files are being selected - what do you think?

[sxyazi]

I think the "yanked" state (copying, cutting) of files should always take precedence over the "selected" state. This can help avoid dangerous mistakes - users always know what they have copied (especially cut).

The "marked" state introduced by this PR is a temporary state of "selected", which will eventually become "selected" when the user exits visual mode by pressing Esc, or performs a file operation such as opening, removing, renaming, etc.

[sxyazi]

It seems like we can just make "marked" have a higher priority than "yanked"? I'm not entirely sure, need to think about it some more. What do you think?

[Rolv-Apneseth]

It seems like we can just make "marked" have a higher priority than "yanked"? I'm not entirely sure, need to think about it some more. What do you think?

Sorry yes this is exactly what I meant, the marked should have higher priority.

I understand the dangerous operations come from cutting/yanking, but I believe once the user has re-entered visual mode, the intent is to override the current selection. Perhaps entering visual mode again should clear any yanked files?

[sxyazi]

Perhaps entering visual mode again should clear any yanked files?

If that's the case, we don't need to change the priority; there won't be an issue of overwriting "marked" files when there are no files in the "yanked" state. And it can be implemented by users like: exec = [ "unyank", "visual_mode" ].

[Rolv-Apneseth]

Yeah, that could work, though if it'll just be implemented by the user via keybinds, I'd still imagine having the marked style have a higher priority might be useful for people who don't want to unyank when entering visual mode.

Alternatively, maybe there could be styles for e.g. marked and cut or marked and copied for finer control over the styles. Probably a bit too much for such a minor detail though.

[sxyazi]

Sorry I didn't quite understand. Do you mean that the "marked" state should be higher than the "yanked" state, and the "selected" state lower than the "yanked" state, i.e., marked > yanked > selected?

If so, when a user exits the virtual mode ("marked" state) (at which point the file becomes "selected"), they still wouldn't be able to see the files they've "selected" because the "yanked" state files would override them. This would visually confuse users because the files they selected in virtual mode aren't reflected into the selected state.

As for different styles, I've tried that in #313 (comment), but the effect wasn't very good, which is why I ultimately decided to introduce the unyank command. Any other ideas about styles?

[Rolv-Apneseth]

Sorry I didn't quite understand. Do you mean that the "marked" state should be higher than the "yanked" state, and the "selected" state lower than the "yanked" state, i.e., marked > yanked > selected?

If so, when a user exits the virtual mode ("marked" state) (at which point the file becomes "selected"), they still wouldn't be able to see the files they've "selected" because the "yanked" state files would override them. This would visually confuse users because the files they selected in virtual mode aren't reflected into the selected state.

That is what I meant yes. I see what you mean, that could be confusing, so I guess it's better as it is.

As for different styles, I've tried that in #313 (comment), but the effect wasn't very good, which is why I ultimately decided to introduce the unyank command. Any other ideas about styles?

I think the styling of what you have in that video could be interesting, not necessarily a different marker component though, just allowing different styles for the combinations. So it would allow the user to, for example, have the yanked, selected etc. styles all have a set fg and then marked could just change the bg but keep each underlying state's fg? Just a thought.