Include a text editor for human

I know that speaking like this makes me sound like a loser, but I'm unable to learn and use vi. I have used Linux for more than 10 years, but I have always used nano. It's lucky for me that nano is available and is the default text editor on all Linux distributions I have used. I have played with FreeBSD a bit, the default text editor is vi but fortunately there is also ee.

[Peter0x44]

You can get nano from here:
https://files.lhmouse.com/nano-win/
https://github.com/lhmouse/nano-win

Its build scripts require msys2, but this can probably be factored out with some effort.
Also worth noting is that w64devkit provides gvim if you prefer that.

Also worth noting is that w64devkit provides gvim if you prefer that.

I hate modal editors.

I found that the busybox-w32 wget is very slow compared to the actual GNU wget on MSYS2. I found a Windows port for GNU wget here: https://eternallybored.org/misc/wget/. Can you evaluate it to see if it is safe or not? And please tell me how to replace the built-in wget with it. Thank you.

BTW, we should have curl and zlib on w64devkit thanks to #146, but the Git PR (#77) has never been merged. If you omit Git, can we have curl and zlib? Also note that there is a standalone curl for windows here: https://curl.se/windows/, so we don't really need to integrate everything into w64devkit.

Some other GNU utilities also have native Windows ports:

https://github.com/mbuilov/grep-windows

https://github.com/mbuilov/sed-windows

[Peter0x44]

w64devkit is limited in scope and cannot hope to package everything. I highly recommend you fork w64devkit and change how it is packaged yourself when you want to add tools, that will give you the level of control you seek.

[skeeto]

My goal with w64dk is to provide a curated distribution of powerful C and C++ development tools. Instead of multiple options, my goal is to provide the best option available that fits my criteria. For editors that happens to be Vim. An editor like Nano is easier to pick up, so it may be better at first, but it has a low capability ceiling and simply doesn't hold up against more powerful editors driven by experienced fingers. The tools I pick aren't perfect, and each has a non-empty list of problems I wish they didn't, including and especially Vim, but over time those lists are slowly shrinking. Another goal is compatibility with other tools. So if you don't want to use Vim, w64dk won't get in your way of choosing something else. It just won't be distributed in w64dk. I know a number of people use w64dk with vscode, for example. No matter your choice, it's probably best to launch the editor from the w64dk environment so that it inherits the environment. I understand you're not interested in learning Vim, but for anyone else following along: I high recommend Practical Vim by Drew Neil. Unlike the official tutorial, vitutor (included in w64dk!), which is mostly a list of facts, the book is an opinionated guide to Vim, which is exactly what a newcomer needs. I keep a few physical copies on hand just to lend out to friends and colleagues.

Can you evaluate it to see if it is safe or not?

I don't see any reason to distrust these builds, and in fact I see several of green flags that increase my confidence these are good builds (contact address, conscientious, no ads, no cookies, no js, and a tidy site). The best I can really do is this vibe check, though. You can copy it over the wget.exe in w64dk (which you'll need to redo after updating w64dk), or put it in a directory that you place in at the front of PATH in your .profile. In either case the busybox-w32 shell will prefer its built-in, so to reliably run your custom wget you'll need this environment variable, too: $ BB_OVERRIDE_APPLETS=wget

busybox-w32 wget is very slow compared to the actual GNU wget on MSYS2

That's not too surprising. BusyBox is written for compactness more than performance. Though file system access through MSYS2 is atrocious, and I wouldn't be surprised if say, busybox-w32 "find" was faster than MSYS2. In general, w64dk is an offline kit, and so using it to download stuff from the internet is not really what it's about. (In fact, BusyBox is not written nearly robustly enough to safely handle arbitrary network inputs, as quickly revealed by running it only a little under sanitizers.) I've considered disabling the wget applet, but it's just been too useful from time to time (e.g. for quick local network transfers). So a dedicated tool like curl isn't really on the table.

Some other GNU utilities also have native Windows ports

I looked, and I'm unimpressed with these ports. The equivalent busybox-w32 applets already work better than these GNU patches. Though even if the ports were better, the busybox-w32 applets are already quite sufficient, and in a sweet spot for trade-offs, so I probably wouldn't include them anyway.

w64devkit is limited in scope and cannot hope to package everything. I highly recommend you fork w64devkit and change how it is packaged yourself when you want to add tools, that will give you the level of control you seek.

I want to customize my own local installation. I don't want to make changes to your project.

It's expected that you will refuse to include nano. But thanks to lhmouse's nano-win, I will use it as my default text editor anyway.