Support for trashing files

[stevearc]

closes #99

Adds built-in support for trash. As with the previous implementation, set delete_to_trash = true to cause your deleted files to go to the trash. There are two ways to view the trash: there's the toggle_trash action (bound to g\ by default), or you can run :Oil --trash. If you delete files from the trash they will be permanently deleted (purged). To restore files, just delete them from the trash buffer and paste them wherever you like, the same as how you normally move files. There are different experiences depending on your OS:

Linux:
toggle_trash shows you the files that were deleted from your current directory. To view the entire trash bin use :Oil --trash / (or use - to navigate to the root of the trash). You will notice that some edits in the trash directory will do nothing. For example, you cannot rename or copy a file in the trash; you also cannot create new files in the trash.

Mac:
This implementation can only view the trash as one big bin. It's more similar to just viewing a normal oil directory, and should work the same.

Windows:
No support yet. I hate developing in Windows, so I'm dragging my feet. PRs welcome.

Anyone interested in trash functionality should try this out and leave feedback/bug reports. Once it seems solid enough for a while I'll merge.

[bugabinga]

That is a lot of code 🤣 . I skimmed over it, but could not find obvious issues. Will test the branch in my config for a while.

In regards to win32: AFAICT, RECYCLE_BIN is only accessible via APIs: https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shqueryrecyclebinw

Is shelling out to PowerShell the most realistic approach?
https://jdhitsolutions.com/blog/powershell/7024/managing-the-recycle-bin-with-powershell/

Other nvim plugins seem to rely on third-party cli tools: nvim-tree/nvim-tree.lua#279

[bugabinga]

Tested on linux with PopOS/Gnome and basic seem to work fine!

One potential issue: When trashing a file via Oil, but restoring via Gnome Rubbish Bin (nautilus), the file seems to get purged instead. At least I cannot find it anywhere. This does not happen when thrashing and restoring from Oil to Oil nor from Gnome to Gnome. Maybe some subtle difference in the trash info file?

[bugabinga]

It seems this should show the original path of the thrashed file, but I see nothing.

This shows Oil in floating mode, but same in normal mode.
The file gamble.xml is in trash.

[stevearc]

This is intentional, but perhaps not intuitive. You're using the Linux version which has support for listing the trash files per-directory. Since you're looking at the trashed files from a specific directory, there's no point to displaying the original path. If you open the root :Oil --trash / it shows all trashed files, and the original path for each.

[bugabinga]

Nice, virtual text shows up fine in root trash.
To be honest, it is pretty unintuitive (for me).
What I thought would happen is:

• virtual text is always visible
• listing of thrash files is per-directory recursively downwards

Now that I know how it works, it is definitely usable though.

[stevearc]

Could you explain more what you mean by "per-directory recursively downwards"?

[bugabinga]

Ok, given the following directory state (trashed files are marked with *):

- project
  - fileA
  - fileB
  - fileC*
  - dirA
    - fileA.A
    - fileA.B*
    - fileA.C
    - dirA.D
      - fileA.D.A*
      - fileA.D.B
  - dirB
    - fileB.A
    - fileB.B*
    - fileB.C*

Oil --trash project shows

- fileC -> **virtual text...**
- fileA.B -> **...**
- fileA.D.A -> **...**
- fileB.B -> **...**
- fileB.c -> **...**

Oil --trash dirA shows

- fileA.B -> **...**
- fileA.D.A -> **...**

[stevearc]

I've reworked the display logic. The trash directory will now show files that were trashed from that directory, and also directories that lead to trashed files from subdirs. When you are at the root of a trash scope (the root of a device, or the filesystem root), all trashed files will be visible.
I've also changed it so that trashed files will always have virtual text that displays their original path.

[stevearc]

Thanks for testing! Very odd behavior with nautilus; it does sound like there must be some difference between the two trashinfo files. If you get a chance to check, I'd be curious to know if you spot anything. I'll also test it out next time I'm on my linux machine.

[stevearc]

I tested out the trash + restore functionality on both dolphin and nautilus, and they both seemed to work as expected when interacting with files trashed or restored by oil. If you have any pointers on getting a repro I would appreciate it

[bugabinga]

I treid to reproduce it but could not!

While I found a difference in trashinfo files created with oil, nautilus and nushell, there seems to be no issue.
Probably user error on my part.

# nushell rm --trash
# test.txt.trashinfo
[Trash Info]
Path=/home/oli/test.txt
DeletionDate=2023-10-06T16:54:27

# gnome nautilus delete
# test.txt.trashinfo
[Trash Info]
Path=/home/oli/test.txt
DeletionDate=2023-10-06T16:57:52

# Oil Trash delete
# test.txt-1696604368.814785.trashinfo 
[Trash Info]
Path=/home/oli/test.txt
DeletionDate=2023-10-06T16:59:28

I guess those numbers are an encoding of the deletion date? Oil is probably more spec compliant then others :)

[stevearc]

Glad the issues didn't reproduce! The difference in trash file names is not important. Neither implementation is more or less spec compliant. From the spec in the "Contents of a trash directory" section:

IMPORTANT NOTE. While an implementation may choose to base filenames in the $trash/files directory on the original filenames, this is never to be taken for granted. A filename in the $trash/files directory MUST NEVER be used to recover the original filename; use the info file (see below) for that.

So it's a nice-to-have for the name of the file to be the same or related to the original name, but officially it doesn't matter.

[CorvusPrudens]

This feature is awesome! It seems like I've run into a little snag with my setup though. It looks like the trash buffer doesn't necessarily share the same column settings as the regular buffer, and restoring files from trash with a different column format fails.

Here's my setup:

require("oil").setup({
    columns = {
      "icon",
      "size",
    },
    delete_to_trash = true,
    view_options = {
        show_hidden = true,
    },
})

Restoring files looks like this (io/ being the restored item):

And this is the error message when attempting to write:

Error detected while processing BufWriteCmd Autocommands for "oil://*":                               
Error parsing oil buffers  

I don't know if I'm actually proposing the correct mechanism for the failure, but it did start working after I removed the size option.

I hope this helps!

[stevearc]

@CorvusPrudens that does help! This was actually a pre-existing issue that could happen when moving files over ssh, but the trash feature added more ways for it to happen. Should be fixed by 4088efb, and I've rebased this PR.