I have also been using it for a couple of months and it is great. Most other software that try to emulate a tiling window manager in windows/linux end up being too buggy and annoying to use full time, but in my experience aerospace is the first one that I have been able to run full time with no issues.
Yeah I got exited thinking this is about traffic lights. I use a bike to commute to work and recently I was thinking if I could adjust my cycling cadence so that I never hit a red light, but unfortunately the timing of the traffic lights in my city is not constant. If there was a publicly accessible API to get the current timing info, I could write an app to do that.
If you're in America, take a look at the strobe on top of school busses. I'm not sure if they still have them (they used to). It would flash at a specific frequency and trip a photovoltaic sensor connected to the traffic light, which would turn it green so the kids aren't late for class. If you had a bright enough strobe which flashed at the same frequency...you get the idea.
Is that actually true? I've heard of ambulances & police cars having such devices, but they were supposed to be infrared.
The last time I saw the strobe on top of a school bus active, it was when I was a passenger in one, driving down the freeway at night, and it wasn't strobing particularly fast. It's possible that our driver just forgot to turn it off, I suppose - he was that kind of guy.
I never heard about this being used on school busses. This was always something for emergency services like firetrucks/ambulances to not have to sit in traffic at a red light, but it was only active if they were actively responding to a call with their lights on. Otherwise, they sit at the lights too.
Emergency vehicles have devices that announce their presence to get traffic lights to change in their favor. “Kids being late to class” is not on the order of importance to create a complex scheme to change traffic lights based on strobe lights from a bus.
Bus priority lanes and traffic lights that give priority to busses are definitely a thing. Usually for municipal busses and not school busses, but I'd expect a community that had priority lights for busses would allow school busses onto the system as well.
Not specifically to avoid late arrivals of pupils, but because prioritizing many passenger vehicles is valuable.
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`.
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.
> 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.
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.
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.
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.
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.
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.
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.
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?
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
> 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.
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?
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.
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.
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.
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.
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.
