turboponyy

Sorry for the late reply!

I'm not sure why you think there is any 'config' involved. Perhaps you're conflating Nix the package manager with NixOS? Nix is many things, but it's also just a package manager like any other. For example:

    nix profile install nixpkgs#vim # installs a package into your environment

    nix shell nixpkgs#binwalk nixpkgs#vim # drops you into a shell with the given packages

    nix run nixpkgs#firefox # runs the mainProgram of the given package

A couple of things to note:

The aforementioned commands are the "experimental" Nix 2.4 CLI commands that integrate with Nix Flakes. They are only experimental in name though, their status of being experimental being sort of a meme at this point. I recommend using these new commands (you can opt in by supplying a command-line flag or by tweaking the package manager config).

Packages that are not in active use (e.g. packages that you've referred to in 'nix shell' or 'nix run' invocations that are not installed using 'nix profile') are due for garbage collection. The garbage collection settings can be configured (either through NixOS, home-manager or the package manager's standalone configuration). The garbage collection can also be triggred manually. This makes experimenting with programs that you don't necessarily want to keep a joy.

The 'nixpkgs' in the aforementioned invocations is a default input that is set during installation. It refers to the nixpkgs package archive's flake's master branch's latest revision (https://github.com/nixos/nixpkgs). The available inputs are configurable (again, either through NixOS, home-manager or the package manager's standalone configuration).

I think they definitely should, as this is where the greatest value lies in NixOS for personal use.

You don't need to learn the DSL to use Nix as a package manager.

It sounds like you'd benefit a lot from Nix/NixOS [1], if not just home-manager[2].

1. https://nixos.org/

2. https://github.com/nix-community/home-manager

The correct nomenclature is spray or recoil pattern, not spread - spread is the inherent inaccuracy applied to each bullet that can not be compensated for.

I don't understand this sentiment. The majority of Dependabot's commits that I've seen are 1 or 2 line diffs that just bump a version number in a workflow file. Why wouldn't you want to accept those after a quick review?

No, the automated workflow would be something like this:

- Run dependabot workflow (outputs: $pr_number)

- Automerge $pr_number

There's also ranger and yazi.

Vi-style binds are moderately unintuitive, but they are the lingua franca of keybind languages, and knowing them has value in and of itself. I'm glad I learned vi-style binds just before Kakoune and Helix gained popularity, as I use them in dozens of contexts other than my text editor.

Depending on the package manager / distribution, 'python' might be symlinked to either Python 2 or Python 3. If you don't have Python 3 installed, it might very well point to Python 2. These days it will almost certainly prefer Python 3, but I am also in the habit of actually typing 'python3' instead of 'python' because of what I assume are issues I've had in the past.

Blackcurrant leaves are widely used in the pickling liquid for pickles where I live.

Seems like something that could be solved using tree-sitter[1], though it would probably be pretty involved.

1. https://tree-sitter.github.io/tree-sitter/

I can vouch for general.el[1]. It's easy to use and it integrates with use-package clauses, which-key and evil states. You can look at my config[2] for examples.

1. https://github.com/noctuid/general.el

2. https://github.com/gekoke/dotfiles/blob/main/modules/program...

Personally, I've always found algebra the most difficult - it's just symbol soup with no apparent concepts to latch onto. Perhaps it's just the way it's usually presented, but I don't "get it" at all. It's still by far the most daunting part of math for me, even after taking 5 math courses in university.

The function name is misleading you into thinking that it is imperative. In reality, the function just returns a path to a file in the Nix store with the specified contents. The derivation then returns a container in which Nginx is pointed to that same config file. Nothing is temporal or happening in any particular order - you declare some inputs, and you get some outputs (a Docker container, in this case).

You could use the Neovim plugin[1] which allows you to use Neovim as a backend server and access editing plugins[2][3] that way.

1. https://github.com/vscode-neovim/vscode-neovim

2. https://github.com/tpope/vim-surround

3. https://github.com/andymass/vim-matchup

You know you're not supposed to write the symbols in and around the tags by hand, right?

https://github.com/aca/emmet-ls

Pure functions can't perform side effects, but they can describe them.

For a functional shell, your program's entry point would be composed of pure functions describing effectful actions to take. The necessary computations get bubbled up to the entry point during evaluation, at which point the runtime / compiled program executes them.

(At least, this is the abstracted perspective you should view the purely functional source code from. The final program itself in practice is, of course, effectful throughout).

> I can't count the number of times I wish I could drop out of insert mode in normal web browser text boxes.

You can, if you really want to:

https://github.com/glacambre/firenvim

The programmer's builds are already there, e.g. Librewolf.

Firefox's defaults are terrible, but most unhelpful behavior can be disabled in about:config.

So how exactly does finding a 41p state prove omniperiodicity?

It's obvious - Dr Pepper tastes like marzipan.

Exactly - if you have Xs that are foolike, and Xs that are barlike, the perhaps you should have Yz and Zs instead.

Further, if you want to validate that your X is barlike, all you have to do now is make sure you have some function f : Y -> Z. If you want to scrutinize your validation logic, then you need only look at all functions of that specific type in your program.

Admittedly, go is probably not a language with the best support for these kinds of constructs.

This is just using Github's terminology - https://docs.github.com/en/communities/setting-up-your-proje...

This is a point I completely agree with. Firefox is the perfect example of a context where you would want vi binds, but the implementation ends up being half-baked.

The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one.

Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers.

For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine.

Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs.

The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.

Oops - you're correct, of course.

In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perform linewise vertical motions (compared to a standard WASD "grip"). Navigating within a line using left and right is uncommon when using vi bindings, since there are usually better ways to jump between locations within a line, so it makes more sense to pay the cost of having to move your fingers in this case.

Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.).

As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better.

That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.

fd sounds much worse as now you can't jump to d characters.

NixOS, whilst being a huge time sink, delivers exactly on that promise and then some.

A Wine prefix - the configuration and filesystem for a single Wine Windows installation.