commit 9317d3ea271dd9e1daff1abccbf7886a38b9551a Author: dexta Date: Sat Jul 11 01:10:09 2026 +0200 lets do it diff --git a/.nvim.lua b/.nvim.lua new file mode 100644 index 0000000..381d4d3 --- /dev/null +++ b/.nvim.lua @@ -0,0 +1,8 @@ +-- Erstellt ein Neovim-Kommando :BuildLore +vim.api.nvim_create_user_command('BuildLore', function() + -- Führt das Skript im Hintergrund aus und zeigt den Output an + vim.cmd('!./build.sh') +end, {}) + +-- Optional: Legt den Build-Vorgang auf die Taste b (z.B. Leertaste + b) +vim.keymap.set('n', 'b', ':BuildLore', { noremap = true, silent = false }) diff --git a/00_aMeta/01_neovim_setup.adoc b/00_aMeta/01_neovim_setup.adoc new file mode 100644 index 0000000..fbf3917 --- /dev/null +++ b/00_aMeta/01_neovim_setup.adoc @@ -0,0 +1,65 @@ += Meta: Neovim Setup & Projekt-Bedienung = +:toc: +:icons: font + +Dieser Abschnitt dokumentiert die technische Infrastruktur des Projekts. Da wir auf einem Lenovo X220 mit Window Maker arbeiten, ist das Setup auf maximale lokale Effizienz und saubere, flüchtige Docker-Builds ausgelegt. + +== 1. Starten des Workflows + +Das gesamte Worldbuilding ist terminalbasiert. Um an der Lore zu arbeiten, öffne dein Terminal (z. B. rxvt oder xterm) im Projektverzeichnis und starte Neovim: + +[source,bash] +---- +cd ~/Projekte/Maschinen-Instanzen +nvim . +---- +_(Der Punkt öffnet direkt den internen Dateibrowser Netrw in Neovim)_ + +== 2. Lokale Konfiguration (`.nvim.lua`) + +Damit Neovim weiß, wie es unser spezifisches Projekt kompilieren soll, liegt im Hauptverzeichnis eine verborgene `.nvim.lua`. +Damit diese geladen wird, muss in deiner globalen `~/.config/nvim/init.lua` folgender Parameter gesetzt sein: + +[source,lua] +---- +vim.o.exrc = true +---- + +== 3. Tastenkürzel & Bedienung + +Wir halten Neovim nah am Default. Die wichtigsten projektspezifischen Befehle: + +[cols="1,3", options="header"] +|=== +| Kürzel / Befehl | Aktion +| `:BuildLore` | Ruft das Docker-Bash-Skript auf und baut das finale Markdown. +| `b` | (Meist `Leertaste` + `b`) Der Shortcut für `:BuildLore`. +| `:e datei.adoc` | Öffnet oder erstellt eine neue AsciiDoc-Datei. +| `:Lex` | Öffnet/Schließt die Dateibaum-Ansicht (Netrw) an der Seite. +|=== + +== 4. Die Build-Pipeline (Docker) + +Wir verunreinigen unser Host-System nicht mit Ruby (für Asciidoctor) oder Haskell (für Pandoc). Alles läuft über ein flüchtiges Docker-Skript (`build.sh`). + +*Was passiert, wenn du `b` drückst?* +1. Neovim ruft `build.sh` auf. +2. Ein winziger Alpine-Linux-Container wird gestartet. +3. Der Container liest die `master.adoc` und löst alle `include::`-Befehle auf. +4. Asciidoctor erzeugt ein XML, Pandoc wandelt dieses in `final_worldbuilding.md` um. +5. Der Container löscht sich selbst rückstandslos. + +== 5. Das Tag-System (Redaktionelle Notizen) + +Um Notizen in den Dateien zu behalten, die **nicht** im finalen Export landen sollen, nutzen wir das AsciiDoc-Tag-System. + +Schreibe deinen Lore-Text immer in diesen Block: + +[source,asciidoc] +---- +// tag::export[] +Die Ernteschiffe bremsen in der Oortschen Wolke ab... +// end::export[] +---- + +Alles, was *außerhalb* dieser Tags steht (wie To-Do-Listen, alte Ideen oder Konzept-Müll), bleibt sicher in der `.adoc`-Datei, wird aber beim Build-Prozess vom Container ignoriert. diff --git a/build.sh b/build.sh new file mode 100755 index 0000000..bd85797 --- /dev/null +++ b/build.sh @@ -0,0 +1,31 @@ +#!/bin/bash + +# Name des lokalen Docker-Images +IMAGE_NAME="lore-builder" + +# 1. Prüfen, ob das Image existiert, ansonsten on-the-fly bauen +if [[ "$(docker images -q $IMAGE_NAME 2> /dev/null)" == "" ]]; then + echo "Baue flüchtiges Docker-Image '$IMAGE_NAME' (Alpine, Asciidoctor, Pandoc)..." + docker build -t $IMAGE_NAME - <