[HN Gopher] Show HN: VS Code extension to edit the filesystem li...
___________________________________________________________________
Show HN: VS Code extension to edit the filesystem like a text
buffer
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
Author : hexomancer
Score : 59 points
Date : 2025-07-13 08:41 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| turboponyy wrote:
| "Look what they need to mimic a fraction of our power" - some
| Emacs user, probably
| heltale wrote:
| Some vim user too! oil.nvim is a pretty popular package that
| does this.
| hexomancer wrote:
| 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 wrote:
| 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 wrote:
| 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.
| hexomancer wrote:
| > Creating empty files is rarely useful or necessary
|
| I kind of disagree? Most files were once created as an
| empty file! (at least that's the case in my workflow).
| ckolkey wrote:
| I've always just used `:e <filename>` - never saw the
| appeal of oil.nvim for that use case. But for other kinds
| of modifications it's nifty.
| globular-toast wrote:
| The normal pattern, in Unix-like systems at least, is to
| just write to a non-existent file. There is very little
| reason to create an empty file first.
|
| In Emacs I can even open a file in a non-existent
| directory and it will create all the containing
| directories when I try to save. So I rarely even use
| mkdir.
| whalesalad wrote:
| Was literally thinking the same thing. A colleague of mine
| basically used emacs as an operating system. Pretty sure he
| could get his to make buttered toast.
| senectus1 wrote:
| haha yeah this'll never bee a problem with AI plugged into your
| VSCode :-D
| hexomancer wrote:
| 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 wrote:
| 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_ wrote:
| The idea's cool, but the ui is kinda raw
| hexomancer wrote:
| 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 wrote:
| hey that's just dired !
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...
| hexomancer wrote:
| There was some discussion about dired here:
| https://news.ycombinator.com/item?id=44568404
| signa11 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| anuramat wrote:
| I thought the entire point of vscode was to be an
| extensible "lightweight" barebones code editor, as
| opposed to eg jetbrains stuff; what about vim/emacs then?
| 4gotunameagain wrote:
| I did not by any means want to discourage you from
| developing things and sharing them, if anything I thank
| you for that.
|
| My intention was to highlight that the SW supply chain
| nowadays is an insecure mess.
|
| Regarding your last point, for the vast majority of open
| source SW releases, we can never be sure if the release
| we get is produced from the same code we see. I do not
| know if that is the case with VScode addons, but you get
| my point
| hexomancer wrote:
| > Regarding your last point, for the vast majority of
| open source SW releases, we can never be sure if the
| release we get is produced from the same code we see. I
| do not know if that is the case with VScode addons, but
| you get my point
|
| You actually can depackage vscode's .vsix files (it is
| just a zip file) and compare the package contents to the
| repository.
| hollerith wrote:
| >The problem is that nobody will do that. Even if it were
| 500 LOC.
|
| I do it with the code I download to extend Emacs.
| SketchySeaBeast wrote:
| The burden isn't just when I install it, I need to validate
| every time it's updated as well. But let's be realistic, the
| fact that I intrinsically trust extensions published by
| Microsoft isn't any better.
| aaomidi wrote:
| I'm Iranian too and our names get people a lot more
| concerned.
|
| If your name sounded English the implicit bias would make you
| sound more trust worthy.
| gschizas wrote:
| I have high 2 digits of extensions in my VS Code, and yours
| is the only one that wouldn't have a verified publisher. And
| I certainly have more than one from solo developers.
|
| Qt organization (because you mentioned it) also has
| verification. It displays a different message (because I
| haven't installed anything from them):
|
| > The extension Qt Core is published by Qt Group. This is the
| first extension you're installing from this publisher.
|
| > Qt Group has verified ownership of qt.io.
|
| > 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.
|
| EDIT: I'm sure there are other extensions that are also by
| unverified publishers. It was the first time I was hit with
| that message though.
| norman784 wrote:
| For the current extension model, I would not trust anyone
| besides any known org. Even installing themes are potentially
| dangerous, because of the attack vector.
| lorenzohess wrote:
| See vimv (https://github.com/thameera/vimv) for a minimal version
| of this in the CLI, using Vim as the editor.
| mjw1007 wrote:
| Also vidir, which is in the moreutils package in popular
| distros.
| SwiftyBug wrote:
| Is it possible to make an extension like that for Zed?
| norman784 wrote:
| 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 wrote:
| AFAIK not with their current extremely limited API, but it's on
| their roadmap to have a more extendable editor.
| nsonha wrote:
| 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.
| dcreater wrote:
| Falling to see why `touch newfile` doesn't accomplish this as
| fast if not faster and without yet another extension.
| hexomancer wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| Davidbrcz wrote:
| So emacs-dired ?
| mprovost wrote:
| 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
| hexomancer wrote:
| That's so cool, I was actually curious about history of such
| programs. Thanks for posting this :)
| weakfish wrote:
| Awesome work! I'll definitely try this out.
___________________________________________________________________
(page generated 2025-07-15 23:02 UTC)