12 ms·

Show HN: VS Code extension to edit the filesystem like a text buffer

67 points by hexomancer 1y ago

This is a spiritual adaptation of oil.nvim for vscode. The main idea is you edit the filesystem by editing the current directory listing's text buffer. For example, if I want to rename a file, I just rename it in the listing file. This is extremely powerful because it translates all of your text-editing skills immediately into file editing capabilities. Some features: * Create/rename/move/delete files by editing the current directory listing's textbuffer * Filter using glob pattern * Trash and undo support * Works even in remote-ssh workspaces * Works across multiple vscode windows

dcreater 1y ago
Falling to see why `touch newfile` doesn't accomplish this as fast if not faster and without yet another extension.
- hexomancer 1y ago
  I doubt this comment was in good faith (you decided to ignore literally all the features I mentioned and focused on just creating files) but I am going to reply anyway: 1. There is no way that `touch newfile` is faster. Using voil, you press a keybind, enter `newfile`, save and you are done. Using touch you have to first, use some keybinding to switch to terminal, then type `touch ` (6 letter overhead) then type the name of the file and then switch back to vscode. I am not saying voil is meaningfully faster, but you saying that `touch newfile` is faster is wild to me. 2. If I am editing a comlpex file name I like having access to all the text editing features that I have in vscode as opposed to the barebones text editing features in the terminal. 3. There is also all the other moving/copying/renaming with visual feedback that you decided to completely ignore. 4. If touch was faster then oil.nvim would not have been such a popular extension. I am sure most vim users know how to use `touch`.
  - homebrewer 1y ago
    If you need complex file manipulation, all of that can be achieved by writing a shell script. That's what I've been doing. You also automatically get access to flow control statements and tools like sed/awk/find. > all the text editing features that I have in vscode as opposed to the barebones text editing features in the terminal. VSCode is a very primitive text editor compared to vim, emacs or helix. You don't need to edit the command line right there in the shell prompt, nor do you need to create any files — press Ctrl+X + Ctrl+E and hack away. Save and close the file (ZZ in vim, for example), and it gets executed by the shell. > then oil.nvim would not have been such a popular extension Popularity is a bad metric, most people don't bother to learn the tools they're using.
    - hexomancer 1y ago
      > If you need complex file manipulation, all of that can be achieved by writing a shell script. That's what I've been doing. You also automatically get access to flow control statements and tools like sed/awk/find. Well yes, of course they all "can" be done by writing a shell script, the same way any text editing with vim "can" also be done using ed. > VSCode is a very primitive text editor compared to vim, emacs or helix. You don't need to edit the command line right there in the shell prompt, nor do you need to create any files — press Ctrl+X + Ctrl+E and hack away. Save and close the file (ZZ in vim, for example), and it gets executed by the shell. I actually use vscode with the vim extension. You seem to be assuming I am unfamiliar with vim and emacs, I can assure you I know them well enough (at least vim, I also am familiar with the overall features of emacs, though I lack the muscle memory to use it efficiently). Here is an example: Let's say you have a file named `feature_experimental.cpp` now you want to remove the `_experimental.cpp` from all the files in the current directory which have `_experimental`. I assure you that I can do it faster using voil than you can with vanilla vscode.
  - dcreater 1y ago
    1. There is an inbuilt terminal in VS code. Its almost always active for me and even if it isnt focusing it/bringing it up is the same distance as firing up voil. The benefit here is that it doesnt occupy your editor 2. What complex file names do you need text editing features for? 3. fzf and zoxide covers most of it I dont want to return the favor of speculate on intent of comment as yours would be petulant and stubborn without focusing on meaningful rebuttal. Im placing this in my comment as based on your other responses there does seem to be a pattern.
turboponyy 1y ago
"Look what they need to mimic a fraction of our power" - some Emacs user, probably
- heltale 1y ago
  Some vim user too! oil.nvim is a pretty popular package that does this.
  - hexomancer 1y ago
    I obviously love oil.nvim and that's why I ported it to vscode. But I think in some ways voil is even more powerful than oil. Specifically: - It can work across multiple vscode windows - The top line (that shows the current directory) can be used to filter files. For example, if you add "*.{txt,md}" to the end of that line, it will only show the txt and markdown files. - The ability to defined custom shell commands and bind keybindings to them. For example, I can create a command that zips selected files and run it with a single keybinding in voil. - Undo functionality
- hexomancer 1y ago
  I don't use emacs so I may not be familiar with the full power, but if you are referring to dired, I think oil.nvim is much, much more powerful than dired. The major difference being that you still need to learn some new keybinds for dired, for example, you can't just create a file by editing the text buffer whereas in oil.nvim (and by extension, voil) your text editing skills immediately apply.
  - globular-toast 1y ago
    You can switch to wdired and then edit the filenames etc. But true you can't create/delete files. Creating empty files is rarely useful or necessary, though, so not sure why you'd want that. Deleting files is more useful but that seems perfect in normal dired as you can see what you've marked rather than try to mentally keep track of lines you've already deleted.
senectus1 1y ago
haha yeah this'll never bee a problem with AI plugged into your VSCode :-D
- hexomancer 1y ago
  Since voil uses its own file extension (.voil) you can easily disable copilot for voil windows. Also voil asks you to confirm destructive actions. And even if you do, by default voil moves deleted files to a trash location and has undo functionality so you can easily undo your mistakes.
- Etheryte 1y ago
  In this day and age, this could very well be an up and coming startup. "Hey <LLM>, find all files on my computer that might be a virus and delete them."
_Broken_Cloud_ 1y ago
The idea's cool, but the ui is kinda raw
- hexomancer 1y ago
  Thanks for the feedback. Can you be a little more specific? What do you mean by "raw"? Do you mean from an aesthetic standpoint or is there some functionality you are missing from the UI?
signa11 1y ago
hey that's just dired ! https://www.gnu.org/software/emacs/manual/html_node/emacs/Dired.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...
- hexomancer 1y ago
  There was some discussion about dired here: https://news.ycombinator.com/item?id=44568404 https://news.ycombinator.com/item?id=44568404
  - signa11 1y ago
    yup ! thanks i read it all. have been using Emacs for longer than i care to admit. just like fvwm, there is nothing better than :o) !
gschizas 1y ago
This looks cool, but I'm a bit wary of publishers that aren't verified. > Do you trust the publisher "Ali Mostafavi"? > The extension voil is published by Ali Mostafavi. This is the first extension > you're installing from this publisher. > Ali Mostafavi is not verified. > Visual Studio Code has no control over the behavior of third-party extensions, including how they manage your personal data. Proceed only if you trust the publisher.
- hexomancer 1y ago
  You can view the source code and package the extension yourself if you are worried about that. It is only ~2000 LOC. It is not easy to get verified in vscode marketplace, even major publishers like Qt organization are not verified much less so a solo open source developer like myself.
  - 4gotunameagain 1y ago
    > view the source code and package the extension yourself The problem is that nobody will do that. Even if it were 500 LOC. And this is why supply chain attacks are on the rise.
    - hexomancer 1y ago
      What are you proposing? Should I not be allowed to develop and publish an extension that I think is useful? > nobody will do that "nobody" is a strong word. Yes, most people don't do that, but if a single person reads the source code and finds something nefarious they can report it or leave a review disclosing that and my reputation would be ruined.
      - msgodel 1y ago
        IMO you should avoid installing editor extensions generally. It's better to try to get them merged into the editor itself. I don't think it's good to constrain people in some way from doing that, you should just have a personal policy of avoiding extensions you're not involved in the development of.
lorenzohess 1y ago
See vimv (https://github.com/thameera/vimv https://github.com/thameera/vimv) for a minimal version of this in the CLI, using Vim as the editor.
- mjw1007 1y ago
  Also vidir, which is in the moreutils package in popular distros.
  - deleted 1y ago
    [deleted]
SwiftyBug 1y ago
Is it possible to make an extension like that for Zed?
- norman784 1y ago
  At this point I opted to just install extension from known ORGs only, like Microsoft, Github, etc and the official extensions from the languages I use. All other extensions, even themes are no more for me.
- weakfish 1y ago
  AFAIK not with their current extremely limited API, but it’s on their roadmap to have a more extendable editor.
nsonha 1y ago
When I was a student about 10 years ago there was a custom shell that works like this and even had an extension for sublime, but for the life of me I cannot remember its name.
Davidbrcz 1y ago
So emacs-dired ?
mprovost 1y ago
There's a long history of "directory editor" programs going back to (at least) 1974, which predates emacs. It's not surprising that there are many examples of convergent evolution. https://invisible-island.net/ded/dating-dired.html https://invisible-island.net/ded/dating-dired.html
- hexomancer 1y ago
  That's so cool, I was actually curious about history of such programs. Thanks for posting this :)
weakfish 1y ago
Awesome work! I’ll definitely try this out.

67 points by hexomancer 1y ago

dcreater 1y ago

Falling to see why `touch newfile` doesn't accomplish this as fast if not faster and without yet another extension.

hexomancer 1y ago
I doubt this comment was in good faith (you decided to ignore literally all the features I mentioned and focused on just creating files) but I am going to reply anyway: 1. There is no way that `touch newfile` is faster. Using voil, you press a keybind, enter `newfile`, save and you are done. Using touch you have to first, use some keybinding to switch to terminal, then type `touch ` (6 letter overhead) then type the name of the file and then switch back to vscode. I am not saying voil is meaningfully faster, but you saying that `touch newfile` is faster is wild to me. 2. If I am editing a comlpex file name I like having access to all the text editing features that I have in vscode as opposed to the barebones text editing features in the terminal. 3. There is also all the other moving/copying/renaming with visual feedback that you decided to completely ignore. 4. If touch was faster then oil.nvim would not have been such a popular extension. I am sure most vim users know how to use `touch`.
- homebrewer 1y ago
  If you need complex file manipulation, all of that can be achieved by writing a shell script. That's what I've been doing. You also automatically get access to flow control statements and tools like sed/awk/find. > all the text editing features that I have in vscode as opposed to the barebones text editing features in the terminal. VSCode is a very primitive text editor compared to vim, emacs or helix. You don't need to edit the command line right there in the shell prompt, nor do you need to create any files — press Ctrl+X + Ctrl+E and hack away. Save and close the file (ZZ in vim, for example), and it gets executed by the shell. > then oil.nvim would not have been such a popular extension Popularity is a bad metric, most people don't bother to learn the tools they're using.
  - hexomancer 1y ago
    > If you need complex file manipulation, all of that can be achieved by writing a shell script. That's what I've been doing. You also automatically get access to flow control statements and tools like sed/awk/find. Well yes, of course they all "can" be done by writing a shell script, the same way any text editing with vim "can" also be done using ed. > VSCode is a very primitive text editor compared to vim, emacs or helix. You don't need to edit the command line right there in the shell prompt, nor do you need to create any files — press Ctrl+X + Ctrl+E and hack away. Save and close the file (ZZ in vim, for example), and it gets executed by the shell. I actually use vscode with the vim extension. You seem to be assuming I am unfamiliar with vim and emacs, I can assure you I know them well enough (at least vim, I also am familiar with the overall features of emacs, though I lack the muscle memory to use it efficiently). Here is an example: Let's say you have a file named `feature_experimental.cpp` now you want to remove the `_experimental.cpp` from all the files in the current directory which have `_experimental`. I assure you that I can do it faster using voil than you can with vanilla vscode.
- dcreater 1y ago
  1. There is an inbuilt terminal in VS code. Its almost always active for me and even if it isnt focusing it/bringing it up is the same distance as firing up voil. The benefit here is that it doesnt occupy your editor 2. What complex file names do you need text editing features for? 3. fzf and zoxide covers most of it I dont want to return the favor of speculate on intent of comment as yours would be petulant and stubborn without focusing on meaningful rebuttal. Im placing this in my comment as based on your other responses there does seem to be a pattern.

turboponyy 1y ago

"Look what they need to mimic a fraction of our power" - some Emacs user, probably

heltale 1y ago
Some vim user too! oil.nvim is a pretty popular package that does this.
- hexomancer 1y ago
  I obviously love oil.nvim and that's why I ported it to vscode. But I think in some ways voil is even more powerful than oil. Specifically: - It can work across multiple vscode windows - The top line (that shows the current directory) can be used to filter files. For example, if you add "*.{txt,md}" to the end of that line, it will only show the txt and markdown files. - The ability to defined custom shell commands and bind keybindings to them. For example, I can create a command that zips selected files and run it with a single keybinding in voil. - Undo functionality
hexomancer 1y ago
I don't use emacs so I may not be familiar with the full power, but if you are referring to dired, I think oil.nvim is much, much more powerful than dired. The major difference being that you still need to learn some new keybinds for dired, for example, you can't just create a file by editing the text buffer whereas in oil.nvim (and by extension, voil) your text editing skills immediately apply.
- globular-toast 1y ago
  You can switch to wdired and then edit the filenames etc. But true you can't create/delete files. Creating empty files is rarely useful or necessary, though, so not sure why you'd want that. Deleting files is more useful but that seems perfect in normal dired as you can see what you've marked rather than try to mentally keep track of lines you've already deleted.

senectus1 1y ago

haha yeah this'll never bee a problem with AI plugged into your VSCode :-D

hexomancer 1y ago
Since voil uses its own file extension (.voil) you can easily disable copilot for voil windows. Also voil asks you to confirm destructive actions. And even if you do, by default voil moves deleted files to a trash location and has undo functionality so you can easily undo your mistakes.
Etheryte 1y ago
In this day and age, this could very well be an up and coming startup. "Hey <LLM>, find all files on my computer that might be a virus and delete them."

_Broken_Cloud_ 1y ago

The idea's cool, but the ui is kinda raw

hexomancer 1y ago
Thanks for the feedback. Can you be a little more specific? What do you mean by "raw"? Do you mean from an aesthetic standpoint or is there some functionality you are missing from the UI?

signa11 1y ago

hey that's just dired ! https://www.gnu.org/software/emacs/manual/html_node/emacs/Dired.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...

hexomancer 1y ago
There was some discussion about dired here: https://news.ycombinator.com/item?id=44568404 https://news.ycombinator.com/item?id=44568404
- signa11 1y ago
  yup ! thanks i read it all. have been using Emacs for longer than i care to admit. just like fvwm, there is nothing better than :o) !

gschizas 1y ago

This looks cool, but I'm a bit wary of publishers that aren't verified. > Do you trust the publisher "Ali Mostafavi"? > The extension voil is published by Ali Mostafavi. This is the first extension > you're installing from this publisher. > Ali Mostafavi is not verified. > Visual Studio Code has no control over the behavior of third-party extensions, including how they manage your personal data. Proceed only if you trust the publisher.

hexomancer 1y ago
You can view the source code and package the extension yourself if you are worried about that. It is only ~2000 LOC. It is not easy to get verified in vscode marketplace, even major publishers like Qt organization are not verified much less so a solo open source developer like myself.
- 4gotunameagain 1y ago
  > view the source code and package the extension yourself The problem is that nobody will do that. Even if it were 500 LOC. And this is why supply chain attacks are on the rise.
  - hexomancer 1y ago
    What are you proposing? Should I not be allowed to develop and publish an extension that I think is useful? > nobody will do that "nobody" is a strong word. Yes, most people don't do that, but if a single person reads the source code and finds something nefarious they can report it or leave a review disclosing that and my reputation would be ruined.
    - msgodel 1y ago
      IMO you should avoid installing editor extensions generally. It's better to try to get them merged into the editor itself. I don't think it's good to constrain people in some way from doing that, you should just have a personal policy of avoiding extensions you're not involved in the development of.

lorenzohess 1y ago

See vimv (https://github.com/thameera/vimv https://github.com/thameera/vimv) for a minimal version of this in the CLI, using Vim as the editor.

mjw1007 1y ago
Also vidir, which is in the moreutils package in popular distros.
- deleted 1y ago
  [deleted]

SwiftyBug 1y ago

Is it possible to make an extension like that for Zed?

norman784 1y ago
At this point I opted to just install extension from known ORGs only, like Microsoft, Github, etc and the official extensions from the languages I use. All other extensions, even themes are no more for me.
weakfish 1y ago
AFAIK not with their current extremely limited API, but it’s on their roadmap to have a more extendable editor.

nsonha 1y ago

When I was a student about 10 years ago there was a custom shell that works like this and even had an extension for sublime, but for the life of me I cannot remember its name.

Davidbrcz 1y ago

So emacs-dired ?

mprovost 1y ago

There's a long history of "directory editor" programs going back to (at least) 1974, which predates emacs. It's not surprising that there are many examples of convergent evolution. https://invisible-island.net/ded/dating-dired.html https://invisible-island.net/ded/dating-dired.html

hexomancer 1y ago
That's so cool, I was actually curious about history of such programs. Thanks for posting this :)

weakfish 1y ago

Awesome work! I’ll definitely try this out.