Feature: Cross-directory actions

[elihunter173]

u/PaperCupsAhoy made a comment on Reddit asking

Does it support cut and paste (akin to mv) after hopping between different directories? E.g. cut from one directory and paste in a directory next to it?

New Thoughts

See #7 (comment). I previously thought making this feature work would be too difficult, but I think I know how to now.

Old Thoughts

I think this would be a nice feature. However, I'm not sure how to implement it and it seems very error prone to take actions across directory buffers. For example, how would cutting and pasting a file work across dirbufs? You have to save the one you're cutting from first because we don't let you leave a modified dirbuf (because how do we know how to navigate the filesystem if the buffer you're using to navigate doesn't represent the filesystem?) so you have to save, which deletes the file you're cutting! Copies are notably easier but I'd like cross-directory actions to support everything.

Edit: I had a bunch of thoughts about expanding subdirectories and modifying here, but I've since made a new issue #26

[seblyng]

How about something like where you are always copying at first (since the buffer that the file/directory is moved from is not saved). Then, if you quit without saving, the file/directory is only copied. But if you save the first buffer, the file is then deleted which will be seen as a move since it's first copied to a new location, and then deleted from the original location

EDIT: There could be one issue however, and that is if the user by mistake writes the buffer before copying the file over to another directory. I think this could be less of a problem if the user gets a prompt to confirm the deletion of files/directories. I think having an option to get a prompt like that would be helpful, and not only for this case only, as deletion is not reversible like renaming, copying and creating is

[elihunter173]

I've been thinking about this more and here's my mostly unorganized thoughts.

I think it is actually feasible to take actions across directory buffers without running into issues where you're cutting a file in one directory buffer (and thus deleting it) and then trying to paste it (i.e. copy it) into another or having weirdness around leaving unsaved directory buffers like seblj was mentioning.

If instead of hard deleting files like Dirbuf currently does it moves them to a temporary directory AND if Dirbuf keeps track of filesystem entries globally, we can suddenly delete a file in one directory and paste it into another and Dirbuf will just do the right thing. This also makes it so that suddenly we can actually undo changes in a directory, save them, and have Dirbuf restore the previous state. I'm a big fan of this idea if I can make it work like I have in my head, so I'm going to update the issue accordingly

[toddgaunt]

This would be great, if by default dirbuf didn't delete files but just trashed them (make delete a hidden/alternative action if need be). Do you think you'd ever clear out the trash automatically at the end of a session, or periodically? Also I wonder how you'd handle big files with that strategy, might want to avoid copying them around too much. I wonder how normal file managers queue up operations like this, is it just a history file with commands?

[elihunter173]

Do you think you'd ever clear out the trash automatically at the end of a session, or periodically?

My current thought is for dirbuf.nvim to never clear the trash and instead just overwrite files as necessary. But I do plan to provide a function to clear out the trash manually, which users can hook up on VimLeave or call with whatever frequency/strategy they want.

Also I wonder how you'd handle big files with that strategy, might want to avoid copying them around too much.

I believe the naive way only results in an unnecessary copy if, when moving a file foo from dirbuf A to dirbuf B, you save B first after saving A. Because in this case dirbuf.nvim doesn't "know" foo has been deleted from A before it's been pasted in B, so it copies foo from A to B when you save B, and then deletes it from A when you save A.

IMO this is okay because the performance difference is irrelevant most of the time and it has the most obvious semantics. Also this would be even less important once #26 is implemented.

I wonder how normal file managers queue up operations like this, is it just a history file with commands?

I believe most file managers have undo work by having a stack (or sometimes tree) of commands/actions. Then whenever you hit undo it pops the most recent action off the stack, and applies the reverse action. I don't think this model works well for dirbuf.nvim since users don't directly take action on the filesystem.

[lourenci]

Please, do not abandon the project. Dirbuf is the best file manager out there. Waiting for this feature.

[dagadbm]

For sure!

I was just about to ask if this feature existed.

[textzenith]

'Course, if you can edit multiple directories in the same buffer, this question becomes fairly moot!

edit: Another thing I saw in the oil repo was several users saying how much they wished dirbuf moved files to a temporary storage site / trash bin instead of deleting them. If you implement that, the rest becomes easy again. Maybe it's already been done? Just installed this today, and thirsty for more power 🧛

[brianhuster]

edit: Another thing I saw in the oil repo was several users saying how much they wished dirbuf moved files to a temporary storage site / trash bin instead of deleting them. If you implement that, the rest becomes easy again. Maybe it's already been done? Just installed this today, and thirsty for more power

It is possible, but probably will require Python dependency.

It is possible to implement it from scratch, but then supporting multi-platform will be very hard. The first step could be only supporting platforms that follow FreeDesktop spec