diff --git a/posts/been-a-while.norg b/posts/been-a-while.norg new file mode 100644 index 0000000..f251819 --- /dev/null +++ b/posts/been-a-while.norg @@ -0,0 +1,108 @@ +@document.meta +title: Been a While +description: time passes thats crazy +authors: [ + Adumh00man +] +categories: [ + neovim + nix + blog +] +created: 2026-05-20T15:49:16+01:00 +updated: 2026-05-20T15:49:16+01:00 +draft: false +layout: post +version: 1.1.1 +@end + +* Been a While + So. Nvim 0.12 dropped and kind of made neorg die. + +** What the hell, Neorg? + This blog is written using norg, a neovim org mode analog. For those of you unfamiliar with emacs terminology (ew), org mode is basically + what jupyter notebooks were written with before jupyter notebooks existed. It's an enhanced markup language that relies heavily on lisp, + the scripting language for emacs, in order to do some really cool stuff. + + For starters, you can write and run code directly within the file, which is pretty useful if that's what you want do do I guess. However, + because of how emacs works, this isn't limeted to a certain file type. Let me explain. + +*** Emacs is really cool, but also awful + Emacs, as far as people have told me, is a glorified lisp interpreter. Of course, you have your config, like in neovim, but unlike + neovim, emacs has near to no limits. For starters, there's no lua api nonsense. In the same way that everything on linux is a file, + everything on emacs is a mode. There are major modes, which are analogous to nvim's insert and command modes, and then minor modes, + which alter the functionality of a major mode. But, this isn't just limited to the text buffer. When I said everything, I meant + *everything*. The menu bar is a minor mode for the window, which itself is technically a mode. The buttons within the bar are minor + modes, too! The cursor is a mode, the font is a mode, you get the picture. All of these modes are accesible at runtime, through the + equivalent of the command pallete, alt-x. + + Anyway, the point I'm trying to make is that emacs is for insane people. If you ever wanted to edit text in the title of the window as + if it were an intentional feature (totally possible, the window title is just a buffer), then emacs is the editor for you. This + extensible nature is what lets org mode exist. The features are just as insane as emacs itself. It starts simple, with being able to + fold sections based on structured headings, but then extends to transparent tables, that have full function support that you would + expect from something like excel. Not to mention that the whole file can be exported natively to html or latex with the click + of a button. All of this within a text editor, may I remind you. So, what does this have to do with whatever I'm talking about? + +*** Neorg is a step in the right direction + Neorg is supposed to be a replacement for this incredible power, just in neovim. The concept is simple, just rewrite everything in lua, + right? Wrong. Unlike emacs, neovim config is surprisingly restrictive. Emacs itself is basically written in lisp, which is what makes + it so powerful. Of course, there's some baseline c code to interpret the initial steps, but the rest is custom built. That means that + everything the developers can do, an end user can do just as easily. There's nothing stopping you from writing a whole new text editor + in lisp, or even something more complex (check out {https://github.com/emacs-exwm/exwm}[exwm], a whole ass window manager in lisp). + It goes without saying that neovim has nowhere near the extensibility to be able to make a whole window manager, which makes it much + harder to make an org mode replacement. + + In nvim, you're stuck with whatever the devs give you, through the lua api. This is enough to make something like Telescope, or a + dired ripoff like oil.nvim, but comes way short when trying to rival emacs in extensibility. For instance, when making a plugin, + especially something to do with filetypes, many of the features found in org mode (folding, embedded code blocks) don't have proper + implementations. There are folds in nvim, but they rely on treesitter and lsp heavily, meaning that before long your dependancy tree + is insane, and you need 5 different plugins just to highlight the headers and embed properly. Emacs? Of course, they have an entire + treesitter implementation written in lisp, that also defines languages in lisp, which means that it can be configured at runtime. + + Damn, I might have to switch to emacs. + +** The neorg problem + Neorg is an incredible project. It works how I want it to, basically as a better markdown, but that means that most of the plugins I'm + installing are useless to me. For one, norg refuses to work at all without treesitter. Due to lack of compliancy with the new spec, + all neorg users are forced to use the old master branch for treesitter, because the main branch no longer accepts scanners written in + cpp. Take a wild guess what language the neorg scanner is written in. The plugin also has an lsp, for all 4 of the different blocks, + one of which isn't even implemented, meaning I have to install a whole lsp stack, which is about 10 plugins by itself, depending on what + you use. Neorg also isn't supported on 0.12, meaning that you have to use an old version of neovim on a seperate config, and set up lazy + because vim.pack isn't supported yet. And then there are the non-negotiable plugins that I use on neovim just to edit files, adding about + 10 more random quality of life features (I'm not editing anything without my mini.surround). + + This still isn't counting Latex support, by the way, which was a norg feature, but now has to follow a different spec because their + renderer broke. They now advise using snacks' renderer, which works, but adds another plugin and messes up the syntax highlighting for + said latex, or sometimes just doesn't highlight at all. Not that latex is implemented on this website, anyway. + + Right now, I have 40 plugins, just to edit a markdown file. To someone who prides themselves in having a clean config, the whole setup + feels bloated and slow. + +** The theoretical solution + I could write my own nonsense file type, but I don't have the time or knowledge to come up with anything remotely functional. On top of + making a whole file type, spec and all, from scratch, I would also basically have to write a static site generator for it, so that I + could keep writing this blog, as well as make some kind of transition script so that I can move all of my notes that are written in + neorg over to whatever file type I would end up making. Did I mention I've never even made a neovim plugin? + + The real issue is lack of support. Nobody cares about a niche replacement for an already niche file type on a specialist editor, which + means that nobody wants to rewrite the treesitter integration so that it's compliant with the main branch, nobody wants to make a + proper lsp and find some way to distribute it, and nobody wants to implement tables properly for all of the four people out there that + would use them. Other than the creator of the site generator I'm using, {https://norgolith.amartin.beer/}[Norgolith], I might be the only + person on the internet writing a blog in norg. There are alternatives, but they suffer the same problem of overbuilding and the same + lack of modularity. Projects like orgmode for nvim exist, sure, but all the site generators for proper org mode files are intended to be + used from within emacs, meaning that I can't easily publish anything anyway. + + What I've been forced to do for now is clone an older version of my repo and use that config. After gutting out all of the lsp nonsense + and some code-specific plugins, everything works as intended again, as is the intention with flakes. Just load up the nix shell and have + everything as you left it. + +** Some kind of resolution + After messing about with svelte, I might just make a typescript norg parser and turn this blog into a dynamic site. For starters, I could + remove the direct norgolith input from my flake, which I don't particularly like, and I would also have full control over the look, + unlike whatever stolen theme this is, just refreshed with a catppuccin css file. Worth looking into, but, for now, norg is here to stay. + Atleast until I get bored. + + Next up: why I hate neovim + + See ya! + diff --git a/posts/cool-nix-shit.norg b/posts/cool-nix-shit.norg new file mode 100644 index 0000000..1c18eef --- /dev/null +++ b/posts/cool-nix-shit.norg @@ -0,0 +1,183 @@ +@document.meta +title: Cool shit you can do with nix +description: Nix is surprisingly versatile +authors: [ + Adumh00man +] +categories: [ + nix + linux + blog +] +created: 2026-03-28T19:03:27+00:00 +updated: 2026-03-28T19:59:57+0100 +draft: false +layout: post +version: 1.1.1 +@end + +* Nix is hard + Nix is supposed to be a solve-all to the "it runs on my machine" problem. And it is. If it didn't do that, then there would be no point in + it existing. But, the syntax is a pain in the ass, and the documentation is half baked at best. For reference, everything I talk about + here is coming from my {https://git.voidarc.co.uk/voidarc/nixos}[nixos config repo], so if you need some context, then everything in + there should be functional enough, at least to serve as some kind of guide. + + +html.class note + > I am not a professional. If you want to get your info from someone that knows what they're talking about, look on youtube, idiot. + +** Starting out + This whole guide is coming from the perspective of someone who has never used nix outside of nixos. I decided to switch one day and had + to learn as I went ({:/posts/nix:}[/If only there was a post about that/]). Of course, at the beginning, my config was very simple. I + basically tried to replicate my arch config, which I already managed the dotfiles for through git. I managed, but my main issue was that + my nixos config had to be edited by the root user, because it was in the `/etc/nixos` directory. This is the default location, which makes + sense, because most linux systems need to be oriented toward having multiple users, and you don't want every person on the system to be + able to change the underlying programs. However, this is irritating, because you have to manage a git repo as the root user, which *sucks*. + There are some workarounds, mostly involving symlinks, that, if broken, will brick your system, so they aren't recommended. The real way + you're supposed to do it is with flakes. + +*** Flakes + Flakes aren't real. They can't hurt you. But, they can let you manage your config outside of the `/etc` directory. + + @code nix +{ + description = "My example flake"; + + inputs = { + nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable"; + }; + + outputs = { self, nixpkgs }: { + packages.x86_64-linux = { + default = self.packages.x86_64-linux.hello; + hello = nixpkgs.legacyPackages.x86_64-linux.hello; + }; + }; +} + @end + + This is the default flake that you get upon running `nix flake init` in a project. What you'll immediately notice is that there are only + 2 sections: inputs and outputs (there are more but idk how to use them, except the description). These are not as explanatory as you + might first expect, so I tend to think about it like this: + + - Inputs + -- External links / projects + -- Immutable (for the most part) + - Outputs + -- Generated / built code + -- Changable + -- Where you would put anything of interest + + I am aware this clears up nothing, so let me explain slightly further. + +**** Inputs + Without inputs, you basically can't build anything outside of a hello world with no dependancies. They are the main reason that flakes + were made in the first place. This is because every input is stored in the lock file as a hash of the git repo it is a part of. I went + more in depth in the article I linked to at the start, but for now I'll give you some examples. + + The main input that you would need to + know about is the `nixpkgs` input, which provides a fixed version of the nixpkgs git repo that you can use to access whatever packages + you need. This can be unstable, which, as the name suggests, is newer and less supported, a fixed hash, like + `nixpkgs.url = "github:nixos/nixpkgs?ref=f5da6d7f24b8565882487ce7f45c2a7d9d8afdeb";`, or just a branch, like the one in my config: + `nixpkgs.url = "github:nixos/nixpkgs/nixos-25.11";`. All have different use cases, which I may or may not get to. + + Another common form of input is a repo input. Nixpkgs uses this kind, so it follows the same rules. + @code nix + omnisearch = { + url = "git+https://git.voidarc.co.uk/voidarc/omnisearch"; + inputs.nixpkgs.follows = "nixpkgs"; + }; + @end + The url is slightly different because the repo isn't hosted on github, but the `github:` from before is just a shortcut that expands + into `git+https://github.com/` when you build the flake. Notice that there is another line in the input. This tells nix to use the + version of nixpkgs that the whole system is running on, the one in this repo's flake.lock, instead of the one in the called flake's + repo. This saves storage and prevents you from installing needless copies of apps that are basically the same. Using this syntax is + best practice unless there is a specific version of a dependancy that the app needs. + + The last kind of input you're probably going to see is the local input. These come in the form of local paths, relative to the current flake. + These are used when you have submodules that aren't large enough to deserve a whole repo, or modules that you need to reload on the fly. + @code nix +chataigne.url = "./modules/chataigne"; +nvim-wrapped = { + url = "git+file:///home/user01/.dotfiles/.config/nvim"; + inputs.nixpkgs.follows = "nixpkgs"; + }; + @end + The first input here is just a relative path, with a specific set of dependancies, hence it doesn't follow nixpkgs like the other. + The second input is still a local module, but it isn't relative. The flake is located in a path above the system flake, that I want + to call it from, so I needed to use a workaround and use the repo input type with a `file://` prefix. This lets me test my nvim config + without pushing to git beforehand, which is useful when I've only added one dependancy and don't want to make a whole commit for 3 + lines of code. (don't worry, we'll get back to why it's called nvim-wrapped later) + +**** Outputs + Outputs, as I said, are what's produced when the flake is run. There are different types of these, too, so let's start simple. + + Before you can even think about compiling an app, you have to allow the outputs access to the inputs. This can be seen as the + function call at the beginning of the output section: + @code nix + outputs = + { self, nixpkgs }: + { + # Whatever app + }; + @end + However, this only allows the outputs to access nixpkgs, which is ok for the first type of output: The humble binary. + + Binaries are defined by system. This allows you to have different build instructions for x64 and arm systems in the same flake, but with + modern programming languages that isn't much of an issue. As an example, this flake output would provide fastfetch + @code nix +packages.${system}.default = pkgs.fastfetch; + @end + Simple, right? the `nixpkgs` input provides `pkgs` as a callable parameter, so that would be all you need. This is on display with + the example flake from earlier, providing the `hello` package for x86_64-linux. + This can be added to, by providing a devshell with this package, although that requires slightly more boilerplate. + @code nix + devShells.${system}.default = pkgs.mkShell { + # Packages you want available in your shell + buildInputs = [ + pkgs.fastfetch + ]; + + # Environmental variables or shell hooks that you want to run + # when the shell starts + shellHook = '' + export SOME_VAR=foo + echo "Shell started" + ''; + }; + @end + Of course, a whole shell for fastfetch is a solved issue, with `nix shell` and everything, but for explanatory purposes that's all you + would need to read flakes, and understand what you would need to call in order to get the right package from a repo. There are obviously + building tools, but I have no idea how those work. This is supposed to be from a fully nixos user perspective, and I don't tend to write + too much code. + + Finally, there's the main thing that you would need to manage your system, `pkgs.lib.nixosSystem`. Of course, you could use the + function directly, but that's boring, so I made a function to make a system instead: + @code nix + outputs = + { + self, + nixpkgs, + ... + }@inputs: + let + mkSystem = + extraModules: + nixpkgs.lib.nixosSystem { + inherit system; + specialArgs = { inherit inputs; }; + modules = [ + common + hardwareConfig + ] + ++ extraModules; + }; + in + { + nixosConfigurations = { + mobile02 = mkSystem [ ./configs/configuration-laptop.nix ]; + }; + @end + There are a few things to note here. This is from my system flake, I've just omitted my pc config, because you only really need one to + see what's going on. Starting from the top, there is an extra `@inputs` after the output function. This allows for the `inherit inputs` + inside the mkSystem function, so that you can dynamically access any input from whatever module you're calling for your system. +