Update tags after moving/deleting tagged files

[climbTheStairs]

Currently, when files that have been tagged (t) are moved (d) or deleted, the tags remain unchanged in $XDG_DATA_HOME/lf/tags, rather than being updated or removed.

When I'm moving tagged files (or directories containing them), I have to manually update all the tags, which is inconvenient. For larger or deeper directories, it's easy to forget they contained tagged files at all.
In addition, the current behavior leads to the tags file being filled with non-existent files that have to be manually cleared out.

This would make using lf far more convenient, and considering that tags are part of lf, I believe this would be closer to the expected behavior.

[CatsDeservePets]

I don't really use tags myself but I agree with your point.
You could always write custom wrapper commands that reads $XDG_DATA_HOME/lf/tags and $XDG_DATA_HOME/lf/files before moving/deleting files to then update the tags accordingly.
I do get that this would be rather inconvenient though.

What about copying a tagged file? Should the copy also inherit the source file's tag?
What about marked directories? Shouldn't they get updated as well?

While not being related to tags, I will also link the feature requests #390 and #435, as all of them are related to changes/additions to the way lf copies/moves/deletes files.

[climbTheStairs]

What about marked directories? Shouldn't they get updated as well?

I think so, for the same reasons.

What about copying a tagged file? Should the copy also inherit the source file's tag?

The reason it makes sense to update tags after moving is because (1) the moved file stays the same, i.e. there's no new file being created (unless if moved to a different drive), and (2) not doing so would leave ghost tags.

With copying, the expected behavior is less obvious, but I do think it would probably make more sense to also copy the tags.

(Another marginal reason is that it would be easier for a user who does not want tags to be copied to un-tag everything by themselves, than it would be for a user who does want them copied to re-tag everything by themselves.)

[joelim-work]

See #2256 (comment)

Unfortunately the way tags were implemented in #791, it is just a separate mapping from path to tag string, so that it was easy to persist, and the map would only ever be consulted when displaying the UI. I don't think anyone at the time thought about sorting/filtering by tags.

The comment was about sorting/filtering by tags, but the point is that tags are linked to the path, not the file/inode itself, so moving/deleting a file doesn't affect the tag list. I guess it's possible to respond to file deletion events and clear the corresponding tag to avoid ghost tags though, but it does introduce coupling between two different features (tags and watch notifications).

[CatsDeservePets]

I am aware of this. Personally, I am more interested in the other issues I linked. However, I'd imagine that these would require changes (i.e. better 'tracking' of which files actually get moved and whether it was successful or not) that in return would make implementing this particular behaviour much simpler than it currently is.
Correct me if I am wrong.

[joelim-work]

I think the main problem is the difference between how users expect tags to work and how they are actually implemented in lf. When you perform a tag operation, you are tagging a path (and effectively any file that happens to be at that path), not a file or inode. This means that you can delete a tagged file, then create a new file with the same name and it will be associated with the original tag.

The reason the design is like that is simply because that was the design chosen in the initial implementation #791, and that design was sufficient for everyone interested in the feature at that time.

I haven't looked at the linked issues #390 or #435, I'm guessing this is about adding a step at the end of the paste operation to update the tag list accordingly. But it won't cover all scenarios:

• Other cases like delete/rename have to be handled
• The user could have a custom paste function which bypasses the internal move/copy implementation
• A user might copy files externally outside of lf and expect tags to be copied over in lf as well (somewhat unrealistic)
• A user might expect tags to apply to symbolic links and hard links

As for coming up with an improved design, I am not sure about this - different users may have different expectations about how tags should work for various operations.

[CatsDeservePets]

I have to admit, I did not consider some of the edge cases.
So I tested a bit in ranger:

• Tagging one of these also tags the other:

touch realfile
ln -s realfile linkfile

• Copying inside ranger does not tag the newly created copy
• Moving/renaming inside ranger does update the tag
• Deleting inside ranger does remove the entry from the tag file
• Deleting/moving/renaming outside ranger does not update the tag file

[joelim-work]

I had a quick look at the code in ranger, they also store it as a map with the path as the key. Since this is a separate data structure, there is additional code to update it accordingly whenever files are moved. There is probably similar code for other operations like rename/delete as well.

[CatsDeservePets]

I had a quick look at the code in ranger, they also store it as a map with the path as the key. Since this is a separate data structure, there is additional code to update it accordingly whenever files are moved. There is probably similar code for other operations like rename/delete as well.

In my opinion, storing outdated tags inside lf is just plain wrong behaviour as they theoretically pile up over time and the user having to manually edit the tag file (outdated marks can easier be removed, but I'd also consider it incorrect behaviour).

Not sure, how complex this might end up, especially considering that we just removed recursive setlocal settings in order to simplify the codebase.

[joelim-work]

I guess you can try updating the tags in response to certain events:

• When loading tags, ignore any entries for files that don't exist
• Update tags after modify operations such as rename/delete/paste
• Process delete events from watch, and remove tags accordingly

Yes it will be more code, but hopefully not too much. I'm not a fan of keeping outdated tags, but then again I'm not really a fan of having built-in support for tags either when yazi doesn't. Anyway tags won't be removed as a feature since there are many users.