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.
I kind of disagree? Most files were once created as an empty file! (at least that's the case in my workflow).
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.
- 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
> 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.
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.
If your name sounded English the implicit bias would make you sound more trust worthy.
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.
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.
> 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.
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.
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
You actually can depackage vscode's .vsix files (it is just a zip file) and compare the package contents to the repository.
Again, I am not questioning your integrity or your plugin.
I do it with the code I download to extend Emacs.
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`.
> 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.
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.
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.
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.
just like fvwm, there is nothing better than :o) !