EWW (short for Emacs Web Wowser) is very basic, only really working with the HTML and not so much the css, and definitely not JavaScript. Don’t expect anything fancier than a blog post to work :P

That's kinda cool as it decreases the attack vector very significantly. I've still got a lot of questions regarding the security implications, but I'm sure I'm not the first one that's looking for a 'hardened' Emacs experience if there's anything to worry about in the first place.

I tried several editors but always come back to emacs.

Have you used Helix and/or (Neo)Vim? If so, would you be so kind to share your experiences?

I like Spacevim a lot

Have you tried any of the ones mentioned in the OP? If so, would you be so kind to elaborate upon why you prefer SpaceVim over the others?

(inspired by SpacEmacs)

Interesting. Would you be so kind to elaborate on what this entails?

you can use neovim as the underlying vim package as well. Then update init.toml with whatever layers/plugins you want

That seems kinda hella streamlined and straightforward, which is honestly pretty cool. Is this different from how it works on any of the '(Neo)Vim distros' and/or by default?

I honestly believe that Helix will eclipse NeoVim because it’s designed better, the source code is more maintainable, and the philosophy is a bit more balanced and welcoming to users that care more about productivity than customizability. Refactoring Vim’s spaghetti C code is a massive task, and C as a language drags it down. Where the NeoVim ecosystem is currently fractured among many Lua “distributions,” Helix just builds on itself in one source tree. I think starting with a solid core before supporting plugins will be good for the future of Helix.

Perhaps I should have done a better job at formulating the question. Btw, this writing is cool. Thank you for that. I also believe it contains some excellent pointers regarding topics I should read into. However, my question was more related to the following: As you know; it doesn't matter whichever IDE I'm using, there's definitely a plugin (or perhaps even built-in functionality) that allows me to utilize my Vi(m)-acquired skills to improve my productivity on any given IDE. Do you think that Helix' keybindings (I believe they're at least to some degree inspired by Kakoune) will be similarly found either built-in or as a plugin on whichever random IDE you might come across?

Once Helix has plugins, it might be possible to get something closer to true Vim emulation.

This is the answer I was seeking. Makes sense.

Yea I think Helix is here to stay, and it will continue stealing market share from other terminal editors. It probably won’t convert anyone that’s already invested years in learning and configuring (Neo)Vim, but for newcomers looking for a powerful option with sane defaults, Helix is far easier to get started with.

Perhaps I should have done (yet again) a better job at explaining what I meant. As you know; it doesn't matter if I'm on some random Linux distro or on macOS, I'm sure that Vi(m) is installed by default and I can rely on it. Same applies to some random remote device I'm accessing; if anything, I can expect that my Vi(m)-acquired skills will be of good use. Do you think that Helix or some of the functionality it offers (from its keybindings to anything (really)) will somehow be beneficial to me in some remote accessed device or any other similar setting?

Of course, all of these questions stem from the fact that -if possible- I want usage of my IDE to be beneficial to how I engage with my text editor and vice versa. Otherwise, these questions don't make any sense at all. Perhaps, I should instead reconsider if this is important in the first place. Currently, I'm at least naive enough to believe that it's worth pursuing. But feel free to convince me otherwise 😉!

For completeness' sake, Helix has definitely peaked my interest. I will look into it and see how I might benefit from it (if at all). Thank you.

If you like VSCode, and want the longevity of FOSS, you can switch to https://vscodium.com/

For some reason I had a very bad experience with running plugins on VSCodium. IIRC, there was something about plugin support being a lot worse for some reason. But it might also have been related to something else.

The Vim keybindings for VSCode/VSCodium are ridiculously good

It indeed seems to be a lot better than what I was expecting.

As a diehard Vim user, VSCodium with VSCodeVim is a terrific no-nonsense combination.

But, once again, I'm afraid that eventually VS Code (and thus by extension VSCodium) will be forsaken for some reason. Thus making me, once again, deal with the pain of switching to another IDE, become accustomed to it. Not being as extensible as Emacs/Neo(Vim) anyway etc etc. Like, I believe we're always one 'evolution'/'development' removed from losing our favorite IDE. For example, Jetbrains has been developing their upcoming Fleet IDE. IIUC, it's their version of VS Code; which honestly is cool. But, does beg the question if it will one day replace the fleet of dedicated programming language IDEs that Jetbrains currently supports...

EDIT: lol I only noticed you had edited it after I had commented it.

Edit: Regarding Vim plugin packs, I honestly only ever had a bad time with curated plugin collections. I don’t think the default settings in Vim are that bad anymore, and are trivial to change as you go when something annoys you.

Would that only include Vim plugin packs like SpaceVim etc? Or actually the premade NeoVim 'configs'/'distributions'?

Regarding the ‘split’ in Vim options, Vim is growing up into a protocol, rather than just an editor. As a ‘trapped in Vim’ user, back in the day, I’m delighted that essentially every serious editor now supports Vim keybindings*.''

True. Great insight. But, it sometimes seems to me as if most implementation are rather lazy ones; in the sense that they only feature a very small feature set that Vi(m) provides. I might be wrong though*.

Are you managing dotfiles in rootless containers?

There's not a lot to it, but I like to have my stuff related to .zshrc and .vimrc around regardless of what environment I'm in.

IMO you shouldn’t install nix in a container. If you want to customize your container, run nix outside of the container and tell home manager to apply itself to the container’s file system (home-manager build will put the result into a result directory, which you can copy). Or, you could just mount your host ~/.config on the container maybe.

Very informative! Much appreciated!

Ansible is a big project, but at the end of the day it’s just a Python package. If you already have Python installed, it’s not really adding that much.

Perhaps I should look more into this. Thanks for enlightening me on this matter!

Also obligatory advice for anyone new to Nix: use flakes. Flakes are good and right. It sucks that Nix is in a confusing transition process to flakes, but if you just adopt them completely from the start it makes everything easier. Your home manager config can live in a single flake somewhere that you find convenient, and you can apply it from there.

Noted.

This has definitely opened up both Home Manager and Ansible as potential solutions. Perhaps somewhat random, but have you by any chance engaged with Guix' guix home?

Thanks a lot for your input; much appreciated!

Let me know if you have other questions.

• Is it possible to use Nix' Home Manager to manage dotfiles within a container in such a way that changes applied to said dotfiles within the container would be 'synced' with all the other configs for existing (and future) containers?

• Is it possible to continue to have said functionality if the host doesn't have Nix' Home Manager setup/installed? (So, like, can Nix and its Home Manager be installed within a (rootless) container?)

• Are you by any chance knowledgeable on how Guix' guix home relates to Nix` Home Manager and how either of the two might be more suitable in this situation and why?

Going to try the penguins-eggs method you posted. I would love to be able to turn a virtual box environment into an installable medium to make my own version of debian with all my gnome tweaks.

Good choice! The "penguins-eggs method" should fit the bill ;) !

I would also love a solution that doesn’t require booting into the OS first. So that I can take a root dir and turn it into a bootable iso.

Few questions :P :

1. If I understood you correctly, you mean that all of the files that will make up the bootable iso are contained -presumably under FHS- within a root dir of another distro? Or did you mean it as a partition? Or did you mean any tool that can build your iso from within another system based on (declarative) instructions?
2. Are we still talking about Debian with all your GNOME tweaks?
3. Is Debian a hard requirement? Or would you be open to say something like Fedora?
4. Is Live USB a hard requirement?
5. Might seem random, but what's your stance on declarative distros?

I tried a bunch of old tutorials for making a boot.iso and linking it into mkisofs with -b but it never worked.

Small nitpick; I generally recommend using xorriso over mkisofs, the latter is only packaged in most distros as part of xorriso anyways*. While genisoimage does 'provide' mksisofs as well, genisoimage is unmaintained and should therefore not be used.