Close buffer and delete underlying file

[tobiaskohlbau]

I would like to have an option to delete files from within helix itself. AFAIK there is only the option to use the shell command to rm a file.

Lets assume I've a file called hello.world and I want to delete it. I imagine something like the following to delete the current open file and close the buffer.

1. f -> hello.world
2. :delete

Would this something be considered worth adding into helix?

[Omnikar]

I'm not sure I like the idea of being able to really easily rm a file from Helix (and closing the buffer means that there's no way to recover it using Helix), especially since it would be a command that could potentially be accidentally autocompleted; if we were to add this, I'd want it to utilize the system's "trash" mechanism, rather than rm-ing the file.

[tobiaskohlbau]

I strongly agree that this implementation should be aware of system specific trash mechanism.

Any ideas around that, does linux have a general trash mechanism or is it distro specific? I know for Windows and MacOs there are unified trash directories. I will try to research this for linux.

[tobiaskohlbau]

Looks like the answer was quiet simple to find there exists a The FreeDesktop.org Trash specification which stated by https://github.com/Byron/trash-rs/blob/fcf6bb5eded49de4fedb40513c949f11c6da0b12/src/freedesktop.rs#L1-L7 is implemented by all common distros and DE.

I'm not aware about the dependency guidelines for this repo. Would it be okay to add the dependency on something like Byron/trash-rs (https://crates.io/crates/trash) or should this be implemented within the project itself?

[the-mikedavis]

IMO file management bumps with the idea of a text editor. I think supporting file management through :sh and a file variable in a custom keymap would be ok (so #3134 plus #2757 to solve this use-case) but I don't like the idea of building file-management in.

[tobiaskohlbau]

That would be a feasible solution for me, too. I can unterstand the desire to keep file-management out from the editor. Command substitutions would be really nice. Maybe it's worth contributing to #3134.Feel free to close this issue as not relevant within the core.

I think #4393 should be getting the same information about command substitutions being a better option instead ab baking in file-management as it's quiet similar to this issue.

[QiBaobin]

We can use archive this by :cmds sh rm %val {filename} && buffer-close once #3393 and #4773 merged

[5-pebbles]

The two PRs mentioned by QiBaobin have been closed. As far as I can tell, their replacements are:

• Add command expansions %key{body} #6979
• Command expansion v2 #11164

I strongly believe that this should be part of helix core. While I agree that file management might be out of the scope of an editor, it is required to manage a code bases efficiently just like creating new files, moving them and locating them. I would like to implement it similar to the move command using LSP support, would this be acceptable?

I would prevent accidental deletion, but I have come up with a good solution for that yet.

This config kind of works

[keys.normal.space]
del = [":move ~/trash", ":buffer-close"] # move! on #11093

However, I can't advise anyone else use this because it tells the LSP to change all imports (rust-analyzer ignores that though if the destination is outside the src directory).

[kabouzeid]

Surely, while working on a project, you create, rename, and delete files. How am I expected to do this right now? (Serious question.)

[kanielrkirby]

I use yazi (a file manager) and Helix together quite often, which has served most of my use cases well. There's a hundred terminal-based file managers out there, half written in Rust (to be blazingly fast).

I feel there's a lot of parallels here to the discussions about an integrated terminal, and figuring out at what point we should be building these things into the editor, or leaving that for a dedicated tool (or for someone to go implement it in the plugin system themselves).

Personally, I like how simple Helix is, it makes it easy to use and contribute to (and likely easier to maintain).

[Omnikar]

Surely, while working on a project, you create, rename, and delete files. How am I expected to do this right now? (Serious question.)

I usually do so from either another terminal tab or from :sh. Helix is a terminal based editor after all, so you can use the terminal to do whatever project stuff you need to that falls outside the scope of a text editor (whether that's using yazi like kanielrkirby mentioned or just using shell commands).

[kabouzeid]

Thanks for your answers. I also use yazi and coreutils for file management quite often. However, in Helix, this feels cumbersome because I have to manually navigate to the file again in yazi to delete it (and then also manually close the buffer afterwards, but this is less important). Similarly, with :sh, I have to type out the full relative path to the file I want to delete. Even if basic file management is not planned for Helix, we should at least add some command expansion for the current file name (#11164) to be able to quickly use coreutils for file management, e.g., :sh rm %file instead of :sh rm long/nested/path/to/my/file.rs.

[pascalkuthe]

you can already do :sh rm <c-r>% which is my goto

[kabouzeid]

Thank you, this is much better already. Is this documented somewhere? Also, is it possible to use this inside of a key mapping?

[5-pebbles]

I redact my previous statements. If you use register insertion, deleting files is fairly reasonable. There is no way you could do it by accident, and it doesn't take much longer than typing out a dedicated command.

To answer kabouzeid on whether it is documented:

• https://docs.helix-editor.com/registers.html#special-registers
• https://docs.helix-editor.com/keymap.html#prompt

So it can be inferred; however, it might be nice to have it explicitly mentioned somewhere...