Deshalb hatte ich heute morgen im Fediverse gefragt, welche Tastenkombination oder Taste andere Menschen für NeoVim bzw. Vim nutzen, um eine Alternative für Esc zu haben.

Im Netz hatte ich zuvor z. B. in einem Blogpost den Vorschlag jk gefunden und war überrascht, dass das funktioniert, schließlich befindet man sich im Insert-Modus und das erste j wird auch zuerst eingefügt. Nach dem Drücken von k verschwindet es allerdings direkt wieder.

Dann hat mir 0x17 geantwortet und geschrieben, dass er dafür die Capslock-Taste benutzt.

Genial. Diese Taste benutze ich vermutlich einmal im Jahr und sie liegt direkt nebem dem kleinen Finger und ist schneller erreichbar, ohne die perfekte Handposition verändern zu müssen.

Capslock als Esc in KDE

Um Capslock als Esc nutzen zu können, öffnet man die Systemeinstellungen von KDE bzw. direkt das Modul “Keyboard”. Im Reiter “Advanced” aktiviert man die Checkbox “Configure keyboard options” und öffnet den dritten Eintrag von oben und aktiviert dann “Make Caps Lock an additional Esc”.

Deshalb habe ich in meine Konfiguration die Möglichkeit hinzugefügt, diese Funktion pro Buffer abzuschalten und wieder einzuschalten.

Man kann das sicher schöner machen, z. B. als Toggle, aber ich bin ja faul und mir reicht das so erstmal aus.

In die Datei keymaps.lua kommt hinein:

vim.keymap.set("n", "<leader>nc0", function()
  require("cmp").setup.buffer({ enabled = false })
end, { desc = "Disable Autocompletion" })
vim.keymap.set("n", "<leader>nc1", function()
  require("cmp").setup.buffer({ enabled = true })
end, { desc = "Enable Autocompletion" })

Dann führt man die Datei entweder mit :source aus oder startet NeoVim neu und es gibt bei <leader>nc die beiden Auswahlmöglichkeiten:

Damit da “completion” steht und nicht nur “c -> +prefix”, muss man die Konfiguration des Plugins which-key anpassen:

return {
  "folke/which-key.nvim",
  opts = {
    defaults = {
      ["<leader>n"] = { name = "+natenom" },
      ["<leader>nc"] = { name = "+completion" },
    },
  },
}

Das kommt in die Datei whichkey.lua innerhalb von plugins/.

Ich schalte das meist beim Schreiben von Blogbeiträgen aus. In Einzelfällen kann man die Autovervollständigung trotzdem mit Ctrl + <space> einmalig anzeigen lassen.

Ich nutze Markdown schon eine ganze Weile und es gab nie Fehler beim Rendern von Websites. Aber es ist natürlich schöner, wenn man Markdown so schreibt, wie es vorgegeben ist und so hoffentlich Probleme mit anderen Programmen vermeiden kann.

Beispiele

Ein paar Beispiele für Fehler, die ich bisher falsch auch in älteren Beiträgen hatte und die durch das Plugin mit einer gelben Wellenlinie markiert werden:

• Keine Leerzeile zwischen Überschrift und nächstem Absatz.
• Unformatierte inline URLs ohne < … > an Anfang und Ende.
• Unnötige Leerzeilen.
• Anzahl Leerzeichen für Einrückungen.
• Fehlende Bildbeschreibung für eingebettete Bilder. Natürlich geht das nur, wenn man die Markdown-Syntax dafür nutzt, für Shortcodes von Hugo funktioniert das nicht.
• Fußnote am Ende des Dokuments hat keine Entsprechung im Fließtext.

Infos und Projektseite

Eine Liste der Regeln, die markdownlint kennt, gibt es hier.

Und hier die Projektseite.

Vielleicht ist für jemanden etwas Nützliches dabei.

"nat_sphere": {
    "scope": "markdown",
    "prefix": "md-nat-sphere",
    "body": [
        "{{< sphere src=\"$1\" caption=\"$2\" osmurl=\"$3\" osmembedurl=\"$4\" imgsize=\"$5\" >}}"
    ],
    "description": "360° Photosphere"
},

"nat_gallery": {
    "scope": "markdown",
    "prefix": "md-nat_gallery",
    "body": [
        "{{< nat_gallery match=\"images/*\" >}}"
    ],
    "description": "Natenoms own gallery"
},

"notice": {
    "scope": "markdown",
    "prefix": "md-notice",
    "body": [
    "{{< notice ${1|hinweis,tipp,info,warnung,update|} >}}",
    "${TM_SELECTED_TEXT}$0",
    "{{< /notice >}}"
    ],
    "description": "Notice, tip, info, …"
},

"codewarning": {
    "scope": "markdown",
    "prefix": "md-codewarning",
    "body": "{{< codewarning >}}",
    "description": "Codewarning wegen Copy & Paste in die Shell hinein."
},

"video": {
    "scope": "markdown",
    "prefix": "md-video",
    "body": [
        "{{< video src=\"$1\" caption=\"$2\" type=\"video/mp4\" linktext=\"\" >}}"
    ],
    "description": "Video"
},

"figure": {
    "scope": "markdown",
    "prefix": "md-figure",
    "body": [
        "{{< figure src=\"$1\" link=\"$2\" alt=\"$3\" title=\"$4\" caption=\"$5\" width=\"\" float=\"\" >}}"
    ],
    "description": "Bilder einfügen"
},

"disclaimer": {
    "scope": "markdown",
    "prefix": "md-disclaimer",
    "body": [
        "{{< disclaimer >}}"
    ],
    "description": "Disclaimer für Beiträge über Produkte"
},

"details": {
    "scope": "markdown",
    "prefix": "md-details",
    "body": [
        "{{< details title=\"$1\" >}}",
        "${TM_SELECTED_TEXT}$0",
        "{{< /details >}}"
    ],
    "description": "Ausklappbarer Details"
},

"clear": {
    "scope": "markdown",
    "prefix": "md-clear",
    "body": [
        "{{< clear >}}"
    ],
    "description": "Float clear"
},

"datetime": {
    "prefix": "md-datetime",
    "body": [
        "$CURRENT_YEAR-$CURRENT_MONTH-${CURRENT_DATE}T${CURRENT_HOUR}:$CURRENT_MINUTE:$CURRENT_SECOND+02:00"
    ],
    "description": "Date/Time for blog post."
},

"blockquote": {
    "scope": "markdown",
    "prefix": "md-blockquote",
    "body": [
        "{{< blockquote cite=\"$1\" link=\"$2\" linktext=\"\" >}}",
        "${TM_SELECTED_TEXT}$0",
        "{{< /blockquote >}}"
    ],
    "description": "Zitat"
},

"frontmatter-blog": {
    "scope": "markdown",
    "prefix": "md-frontmatter-blog",
    "body": [
        "---",
        "title: \"$1\"",
        "# linkTitle: ",
        "slug: ${2/[\\ ]/-/g}",
        "date: $CURRENT_YEAR-$CURRENT_MONTH-${CURRENT_DATE}T${CURRENT_HOUR}:$CURRENT_MINUTE:$CURRENT_SECOND+02:00",
        "# featured: false",
        "draft: false",
        "# comment: true",
        "# toc: true",
        "# reward: false",
        "# pinned: false",
        "# carousel: false",
        "# reward: false",
        "author: Natenom",
        "#description: ",
        "categories:"
        "  - $3",
        "tags:",
        "  - $4",
        "# series: ",
        "#comments:",
        "#  host: social.anoxinon.de",
        "#  username: natenom",
        "#  id: ",
        "---"
    ],
    "description": "Front Matter Blog"
},

"blog-template-fahrradstatistik": {
    "scope": "markdown",
    "prefix": "md-blog-template-fahrradstatistik",
    "body": [
        "---",
        "title: \"Meine Fahrradstatistik für ${1:monat} ${CURRENT_YEAR}\"",
        "slug: fahrradstatistik-${1/(.*)/${1:/downcase}/}-${CURRENT_YEAR}",
        "author: Natenom",
        "date: $CURRENT_YEAR-$CURRENT_MONTH-${CURRENT_DATE}T${CURRENT_HOUR}:$CURRENT_MINUTE:$CURRENT_SECOND+02:00",
        "categories:",
        "- Mobilität",
        "tags:",
        "- ${1}",
        "- Fahrrad",
        "- Mobilität",
        "- Statistiken",
        "- Strecke",
        "",
        "---",
        "",
        "<!--more-->",
        "- Gefahrene Kilometer: ${0} km ([${1}]() 2022:  km)",
        "- Reine Fahrzeit: h (${1} 2022:  h  min)",
        "- Höhenmeter (nur hoch):  hm (${1} 2022:  hm)",
        "- Gesamtkilometer 2023:  km (gleicher Zeitraum 2022:  km)",
        "- Regentage: ",
        "- Schneetage: ",
        "- Kalorienverbrauch:  kcal",
        "- Durchschnittliche Geschwindigkeit:  km/h",
        "- Durchschnittlicher Puls: ",
        "- Höchster Puls: ",
        "- Aktuelles Gewicht:  kg"
    ],
    "description": "Blog Template Fahrradkilometer"
},

"blog-template-microblog": {
    "scope": "markdown",
    "prefix": "md-blog-template-microblog",
    "body": [
        "---",
        "title: \"Microblog: ${1:Titel}\"",
        "slug: ${2/[\\ ]/-/g}",
        "author: Natenom",
        "date: $CURRENT_YEAR-$CURRENT_MONTH-${CURRENT_DATE}T${CURRENT_HOUR}:$CURRENT_MINUTE:$CURRENT_SECOND+02:00",
        "categories:",
        "- ${3:Allgemein}",
        "tags:",
        "- Microblog",
        "",
        "---",
        "",
        "$0"
    ],
    "description": "Blog Template Microblog"
},

"more": {
    "scope": "markdown",
    "prefix": "md-more",
    "body": [
        "<!--more-->",
        "$0"
        ],
    "description": "More anchor"
},

"codefence": {
    "scope": "markdown",
    "prefix": "md-codefence",
    "body": [
        "```${1|apacheconf,awk,bash,c,c#,coffeescript,css,diff,go,html,ini,json,julia,markdown,plaintext,python,ruby,toml,xml,javascript|}",
        "${TM_SELECTED_TEXT}$0",
        "```"
    ],
    "description": "More anchor"
},

"table": {
    "scope": "markdown",
    "prefix": "md-table",
    "body": [
        "| ${1} | ${2} |",
        "| ------|------ |",
        "| ${3} | ${4} |",
        "|  |  |",
    ],
    "description": "Table"
}

Lag wohl am “Scope”, der auf “Markdown” eingestellt war und der Markdown-Bereich in einem Blogbeitrag für Hugo erst nach den drei --- anfängt. Habe das auf “FrontMatter” eingestellt und gehofft, aber das ging auch nicht.

Wenn man die “Eigenschaft” “Scope” ganz entfernt, geht es.

Hier das Snippet:

"datetime": {
    "prefix": "md-datetime",
    "body": [
      "$CURRENT_YEAR-$CURRENT_MONTH-${CURRENT_DATE}T${CURRENT_HOUR}:$CURRENT_MINUTE:$CURRENT_SECOND+02:00"
    ],
    "description": "Date/Time for blog post."
},

Hier alle meine Snippets fürs Schreiben von Blogbeiträgen in Hugo, vielleicht ist ja was Brauchbares für jemanden dabei. 😊

Ich beschreibe hier, wie ich meine Blogbeiträge schreibe, welche Werkzeuge ich dafür benutze, zeige, wie das im Einzelnen aussieht, was man beachten sollte und so weiter.

Statt eine Anwendung für alles zu verwenden, wie das der Fall bei einigen auf Electron basierenden Editoren für Markdown ist, nutze ich mehrere Tools, von denen jedes eine Sache gut kann. Und ich bin damit auch zufrieden.

Start eines Blogbeitrags

Zuerst erstelle ich ein sogenanntes Page Bundle. Das ist ein Verzeichnis, in welchem sich alle für einen Blogbeitrag relevanten Daten befinden. Das mache ich mit Dolphin, dem Dateibrowser von KDE.

In diesem Page Bundle erstelle ich zunächst die Datei index.md und öffne sie mit Kate. Diese Datei enthält den gesamten Markdown Quelltext des Blogbeitrags.

Dazu kommen während des Schreibens optional beliebige weitere Dateien wie Fotos, Screenshots oder Videos, die aber auch in Unterverzeichnissen organisiert werden können.

Hier die Verzeichnisstruktur (das Page Bundle) zu Beginn des Blogbeitrags:

2022-02-fixme-arbeitsweise-blog-hugo
└── index.md

Editor – Kate

Zuerst füge ich einen selbst erstellen Text Snippet (siehe nächster Abschnitt) für das Front Matter in die geöffnete index.md ein, das in etwa so aussieht:

title:
slug: FIXME # Würde ich hier nichts eintragen, würde Hugo den Namen des Page Bundles # verwenden, also "2022-02-fixme-arbeitsweise-blog-hugo".
date: FIXME
author: Natenom
description: FIXME
categories:

- tags:
- ***

Text Snippets

Seit ich Markdown für meinen Blog verwende, brauche ich immer wieder einen gewissen Satz von immer den selben Textbausteinen für Formatierungen, die Hugo nicht von Haus aus mitbringt und die als Shortcodes realisiert sind. Z. B. zum Einbinden von Bildern oder Videos oder für schöne Hinweis-Boxen. Dafür nutze ich Text Snippets.

Für Kate gibt es Text Snippets als Plugin und man muss dieses aktivieren unter Settings -> Configure Kate -> Plugins -> Snippets Tool View. Sofort erscheint rechts in der Seitenleiste Snippets. Klickt man dort drauf, werden bereits vordefinierte Snippets angezeigt. Diese habe ich gelöscht, da ich sie nicht benötige.

Zuerst legt man ein eigenes Snippet Repository an. Wichtig hierbei ist die Angabe eines Namensraums (Namespace). Innerhalb diesem sind die Snippets später auswählbar. Unten kann man noch auswählen, ob die Snippets für alle oder nur für bestimmte Dateitypen nutzbar sind.

Hier die Liste meiner Snippets zum Schreiben von Blogbeiträgen:

Dabei bedeuten die Abkürzungen:

• bi – builtin
• sc – shortcode
• th – theme (Für Shortcodes, die vom Theme bereitgestellt werden.)

Einfügen kann man die Snippets, in dem man in Kate die Tastenkombination Strg + Leertaste drückt. Es erscheint ein kleines Overlay, in dem man mit den Cursortasten den passenden Eintrag auswählt:

Rechtschreibkorrektur

Kate kann auch eine auf dem System installierte Rechtschreibkorrektur einbinden. Ich habe mich für Hunspell entschieden (apt install hunspell hunspell-de-de).

Zusätzlich zu den Systemeinstellungen kann in KDE (Systemsettings -> Regional Settings -> Spell Check) lässt sich die zu überprüfende Sprache auch in Kate unten in der Leiste einstellen (de_DE steht da in meinem Screenshot).

Konsole – für die Helferlein

Mit F4 wird im Kate-Fenster eine Shell gestartet und man kann dort Dinge tun, wie z. B. meine Helferlein für Hugo nutzen. Dabei wird die Shell automatisch in dem Verzeichnis gestartet, in dem sich auch die bearbeitete Datei befindet.

Man kann die Konsole ausblenden und später wieder einblenden (beides mit F4). Sie wird erst richtig geschlossen, wenn man sich dort ausloggt (Strg + d oder exit).

In dem Screenshot ist übrigens einer meiner Helferlein für Hugo zu sehen, mit dem ich nach bereits verwendeten Tags suchen kann.

Vorschau (Hugo + Browser)

Für die Vorschau verwende ich einen im Hintergrund laufenden Hugo-Server und Konqueror, den Webbrowser von KDE.

Hugo: Server mit eigenem Verzeichnis nur für Entwürfe

Da das Rendern meines gesamten Blogs relativ lange dauert, nutze ich fürs Schreiben von Blogbeiträgen ein eigenes Content-Verzeichnis /home/hugo-light/content, das ich Hugo als Parameter übergebe:

hugo server -E -D -F -v -c /home/hugo-light/content/

• -E rendert auch verfallene Beiträge (expired).
• -D rendert auch Entwürfe, die auf Entwurfsmodus eingestellt sind (tag draft:).
• -F rendert auch Beiträge, deren Datum in der Zukunft liegt.
• -c gibt das alternative Content-Verzeichnis an.

Da in diesem Verzeichnis nur ein paar wenige Entwürfe liegen, ist natürlich auch die Zahl der Kategorien und Tags entsprechend klein.

Der Server von Hugo läuft die ganze Zeit im Hintergrund, merkt automatisch, wenn eine Seite geändert wurde (nachdem man sie in Kate gespeichert hat) und rendert dann die gesamte Webseite lokal neu. Der Webbrowser lädt bei Änderungen die Seite neu, sodass man stehts den aktuellen Stand sieht.

Browser: Konqueror zeigt Vorschau an

Rechts neben Kate platziere ich in der benötigten Größe eine Instanz des KDE Browsers Konqueror, der mir die Webseite anzeigt und automatisch neu lädt, sobald Hugo im Hintergrund die Seite nach einer Änderung neu gerendert hat.

Schreiben, schreiben, schreiben …

Jetzt geht es nur noch um die Inhalte. Text schreiben, Screenshots machen und Bilder z. B. mit dem figure Shortcode in den Blogbeitrag einbinden.

Während des Schreibens füge ich auch immer wieder neue Tags zum Front Matter hinzu, falls ich bestimmte Programme erwähne oder neue Themen beschreibe.

Als dieser Blogbeitrag hier fertig war, sah das Page Bundle so aus:

2022-02-fixme-arbeitsweise-blog-hugo
├── cover.png
├── images
│   ├── 2022-02-16-meine-snippets-in-kate-overlay.png
│   ├── 2022-02-16-meine-snippets-in-kate.png
│   ├── 2022-02-16-snippet-repo-in-kate.png
│   ├── 2022-02-17-konsole-innerhalb-von-kate.png
│   ├── 2022-02-17-screenshot-bildschirm-kate-und-konqueror-dark.png
│   └── 2022-02-17-screenshot-bildschirm-kate-und-konqueror-light.png
└── index.md

Das von mir verwendete Theme verwendet die Datei cover.png automatisch als Artikelbild, Details dazu gibt es hier.

Wenn der Blogbeitrag fertig geschrieben ist

Sobald der Blogbeitrag fertig geschrieben ist, fehlen nur noch wenige Schritte bis zur Veröffentlichung:

• Im Front Matter date: an die aktuelle Zeit anpassen. Den String fürs aktuelle Datum und der Uhrzeit im passenden Format liefert mein Helferlein hugo-date-now.
• Umbenennen des Verzeichnisnamens des Page Bundle (richtiges Datum statt fixme).
• Verschieben des Page Bundle in das Content-Verzeichnis der Produktivumgebung des Blogs, in dem alle Beiträge enthalten sind.
• In Git:
  • git add .
  • git commit -m "Neuer Blogbeitrag Arbeitsweise mit Kate, Konqueror und Hugo"
• Hugo den gesamten Blog rendern lassen: hugo --cleanDestinationDir --minify
• Alle Dateien per Rsync auf den Webserver hochladen.

Ab dann ist der Blogbeitrag öffentlich sichtbar und erscheint auch im Feed.

Und auf dem Smartphone?

Auf dem Smartphone kann ich auch Blogbeiträge schreiben, mit der App Markor. Dank Nextcloud werden meine Entwürfe synchronisiert.

Um sie zu veröffentlichen, muss ich aber erst an den PC und dort die letzten Schritte ausführen.

Verbesserungspotential

Da geht noch eine ganze Menge. Z. B. könnte man den Workflow so gestalten, dass ich neue Blogbeiträge nur mit git zu einen Repository pushen müsste, das dann einen Server dazu veranlasst, den Blog zu generieren und zu veröffentlichen.

Oder es ermöglichen, dass Blogbeiträge veröffentlicht werden, die man in einem Page Bundle an einen bestimmten Ort auf dem Server hochgeladen hat. Und noch Vieles mehr.

Dem Theme widme ich mich in den nächsten Tagen und werde berichten.

Tipps und Hinweise

• Verzeichnisstrukturen kann man sehr schön mit dem Kommando tree ausgeben lassen, das es in jeder gängigen Linux-Distribution als Paket geben sollte. In Debian im Paket tree.
• Ich habe mir auf eine Empfehlung hin auch Autokey angesehen. Das ist ein eigenes Tool zur Bereitstellung von Textsnippets. Es gefällt mir aber nicht, da es ein eigenes Fenster läuft, das zwar an der Position des Cursors geöffnet wird, jedoch den Editor überlagert und man die Maus benutzen muss, um das gewünschte Element auszuwählen. Ich mag die Maus jedoch nicht bedienen, wenn ich gerade schreibe. Auch gibt es noch z. B. Espanso, das mir aber auch nicht zusagt, weil es die ganze Zeit läuft und alles auswertet, was man per Tastatur eingibt.
• Es gibt auch die Möglichkeit, innerhalb von Snippets in Kate JavaScript zu verwenden, um Dinge zu tun. Hier ein Beispiel für ein Snippet mit JavaScript.
• Eine Liste der verschiedenen Rechtschreibkorrekturen gibt es hier.
• Eine Liste der Markdown-Formatierungen, die Hugo von Haus aus unterstützt.

Was mir in Kate besonders fehlt:

• Live-Vorschau beziehungsweise Ausblendung der für Fließtext nicht relevanten Teile.
• Übersicht des Textes durch ein Inhaltsverzeichnis

Deshalb habe ich in den vergangenen Wochen immer wieder verschiedene andere Programme ausprobiert, mit denen man Blogbeiträge in Markdown schreiben kann.

Erst heute habe ich alles aufgeschrieben, was mir gefällt und nicht gefällt, daher dieser Blogbeitrag.

So richtig gefallen hat mir bisher nichts. Die Programme, die schön aussehen und z. B. eine Live-Vorschau bieten, sind keine nativen Anwendungen basieren auf Electron. Solche Software will ich gar nicht laufen lassen, aus verschiedenen Gründen, die ich hier nicht erläutern werde.

Trotzdem habe ich z. B. den Editor “Mark Text” getestet, weil ich erst später auf der Projektseite gesehen habe, dass auch dieses auf Electron basiert.

Es folgt eine Liste der Editoren, die ich ausprobiert habe. Ich habe nicht alles in jeder Software getestet sondern nur das, was mir wichtig ist. Und wenn etwas davon nicht erfüllt war, habe ich den Test beendet. Ich habe nur Editoren getestet, die für Linux verfügbar sind.

Mein Fazit

Programme mit einer Live-Vorschau sind sehr angenehm fürs Schreiben, weil sie alles ausblenden, was nicht Fließtext ist. Hier ein Vergleich zwischen Kate, was immer den Quelltext anzeigt und “Mark Text”, das die Live-Vorschau anzeigt und nur den Quelltext des Elements, an dem sich der Cursor aktuell befindet. Der Cursor befindet sich in beiden Dokumenten an der selben Stelle.

Dafür hat aber jedes der getesteten Programme Bugs/Features/Eigenheiten, mit denen ich so nicht dauerhaft arbeiten will (siehe unten).

Außerdem will ich mich weiterhin nicht mit dem Aussehen von etwas beschäftigen, sondern mit Inhalten. Und in jedem Editor sieht die Vorschau je nach verwendetem Stil/CSS ganz anders aus.

Ich wollte mal prüfen, was es außer Kate sonst noch so gibt und habe festgestellt, dass nichts davon für mich nutzbar ist. Daher bleibe ich bei Kate und werde mir das weiterhin schön einrichten.

Und ich habe letztlich beim Testen der Editoren und beim Schreiben dieses Blogbeitrags auch einen für mich gut funktionierenden Workflow gefunden. Dazu werde ich einen weiteren Blogbeitrag schreiben und ihn hier verlinken: Hier ist der Blogbeitrag zu meiner Arbeitsweise mit Hugo.

Getestete Programme

Ich lasse diese Liste der getesteten Programme liegen, damit ich hier nachschauen kann, was ich bereits getestet hatte und weshalb ich es nicht benutzen will. Falls mir mal jemand etwas empfiehlt.

Apostrophe

Link zur Website.

• Pro
  • Kein Browser.
• Contra
  • Scrollt nicht synchron.
  • Auch hier sind Formatierungen in der Vorschau nur sehr zurückhaltend gestaltet und daher kann ich verschiedene Elemente nicht gut unterscheiden.
  • Keine Textsnippets.

Formiko

Das Vorschaufenster enthielt nur Python-Fehlermeldungen. Habe das Paket aus den Debian-Quellen installiert.

Ghostwriter

Link zur Website.

• Pro
  • Kein Browser.
• Contra
  • Dokument und Vorschau leider nicht synchron scrollbar. Bei großen Dokumenten ist das sehr unübersichtlich.
  • Aussehen der Vorschau gefällt mir nicht. Elemente wie <code>xxx</code> erkennt man kaum als solche. Formatierungen sind sehr rudimentär.
  • Keine Textsnippets.

Kate

Link zur Website.

• Pro
  • Kein Browser.
  • Extrem viele Möglichkeiten, unabhängig von Markdown, z. B. kann man markierte Bereiche mittels Shellkommandos bearbeiten (sort, uniq, …), Tools -> Filter Through Command.
  • Schönes Syntaxhighlighting.
  • Autovervollständigung für bereits verwendete Strings.
  • Klein und schnell.
  • Konsole lässt sich im Programm öffnen (F4).
  • Standardeditor von KDE/Plasma, dadurch gut in den Desktop integriert.
  • Textsnippets gibt es, sie werden aber nur zuverlässig eingefügt, wenn man am Ende einer Zeile ist. Wenn nicht, dann fehlt ein Teil des Snippets.
• Contra
  • Keine Liste von möglichen Formatierungen sichtbar. Sollte aber nach einiger Zeit nicht mehr relevant sein, da man das irgendwann gelernt hat.
  • Es gibt ein Plugin für eine Vorschau. Dieses erzeugt aber nur sehr rudimentäre Ausgaben und das auf auf Seitenbasis. Für mich unbenutzbar.

Mark Text

Link zur Website.

Wie man sieht, habe ich diesen Editor nach Kate am längsten benutzt.

• Pro
  • Live-Vorschau des Dokuments. Nur dort, wo gerade der Cursor ist, wird der Quelltext angezeigt.
  • Benutzerinterface und Vorschau gefallen mir sehr gut.
  • Kleines Overlay zur Anwendung von Formatierungen an.
  • Es gibt eine Ansicht für den Quelltext und eine Live-Vorschau. In der Live-Vorschau lässt sich zusätzlich noch ein “Focus Mode” aktivieren. Dadurch tritt alles farblich in den Hintergrund und nur der aktuelle Absatz ist normal zu sehen.
  • Keine störenden Elemente, keine Menüleiste. Nur oben wird als Breadcrumbs der Pfad zur aktuellen Datei angezeigt und links oben gibt es ein Hamburger-Menü. Optional kann man aber eine Sidebar und eine Tab Bar aktivieren.
  • In der Sidebar gibt es eine Liste der aktuell geöffneten Dokumente, eine Suchfunktion innerhalb eines geöffneten Verzeichnisses und ein Inhaltsverzeichnis des aktuellen Dokuments.
  • Am Anfang einer neuen Zeile kann man mit dem @-Zeichen ein Menü öffnen, in dem man aus einer Liste von Formatierung etwas auswählen kann.
  • Sprachen für die Rechtschreibkorrektur sind innerhalb der Anwendung herunterladbar.
  • Mit der Tastenkombination Strg + Shift + P öffnet man die Befehlspalette.
• Contra
  • Basiert auf Electron.
  • Tastaturnavigation mit Strg + Shift + Pfeiltaste hoch funktioniert nicht mehr, sobald das kleine Overlay mit Formatierungsoptionen (automatisch) geöffnet wurde.
  • Scrollen mit Bild hoch funktioniert manchmal nicht und die Ansicht springt immer wieder nach unten zurück.
  • Keine Textsnippets.
  • Shift + Tab innerhalb eines Listenpunktes rückt den Listenpunkt nach rechts statt nach links, wie es in allen anderen Editoren funktioniert. Listen mit Unterpunkten kann man dadurch nicht wirklich bearbeiten.
  • Sobald man Klammern oder Anführungszeichen eingegeben hat, wird ein zweites dahinter gesetzt. Wenn man Texte erst schreibt, ist das super, wie auch bei anderen Programmen. Will man jedoch ein Anführungszeichen vor einen bestehenden String setzen, so werden trotzdem immer zwei Zeichen gesetzt. Löscht man das erste, werden beide gelöscht. Es ist dann nur möglich, das zweite zu löschen, damit das erste übrig bleibt.
  • Beim Löschen von mehreren markierten Zeilen mit Shift + Pfeiltaste hoch wurde schon mehrfach alles bis zum Ende des Dokuments gelöscht statt nur der markierte Bereich.
  • Manchmal dauert länger also normalerweise, bis sich bei einem markierten Wort das Rechtsklick-Menü öffnet, sofern dieses von der Rechtschreibkorrektur als falsch eingestuft und markiert wurde.
  • In vielen Bereich werden unnötige Leerzeilen generiert, z. B. auch in Listen.
  • Ich hatte zeitweise den Eindruck, dass die Anwendung etwas träge reagierte.
  • Keine Textsnippets.

Marker

Link zur Website.

• Pro
  • Viele verschiedene CSS für die Vorschau, z. B. die von Github.
  • Kein Browser.
• Contra
  • Ähnlich rudimentär wie ReText.
  • Vorschau scrollt nicht synchron mit.
  • Editor kann nicht einmal “Suchen und Ersetzen”.
  • Keine Textsnippets.

ReText

Link zur Website.

• Pro
  • Kein Browser
• Contra
  • Drag and Drop zum Öffnen von Dokumenten funktioniert in KDE nicht.
  • Syntaxhighlighting so gut wie nicht vorhanden. Daher sind Texte schwieriger zu lesen.
  • Keine Textsnippets.

Typora

Link zur Website.

• Pro
  • Tastaturnavigation und scrollen funktionieren sehr gut.
• Contra
  • Basiert auf Electron.
  • In der Beta kostenlos, danach wird es kostenpflichtig werden.
  • Live Rendering wie auch bei Mark Text, aber nicht so schön, wie ich finde.
  • Auch in der “Distraction Free”-Ansicht sieht man noch eine Menüleiste
  • Keine Textsnippets.

VSCode, VSCodium, Obsidian, Atom, …

Editoren wie VSCode, VSCodium, Obsidian und Atom habe ich gar nicht erst ausprobiert, da sie alle auf Electron basieren.

Vorteil dieser Editoren ist jedoch, dass es extrem viele Erweiterungen gibt.

Dabei habe ich bemerkt, dass der Editor, der per Voreinstellung sowohl im Browser in Nextcloud als auch in der Android-App benutzt wird, das Front Matter der Dateien nach dem Bearbeiten zerstört.

Aus:

title: Linkdump KW FIXME/2022
url: /2022/xx-linkdump-kw-FIXME-2022
date: 2022-02-06T14:16:09+01:00
author: Natenom
description: Linkdump für Kalenderwoche FIXME/2022
#disable_lightbox: true
images:

- featured.png
  categories:
- Linkdump
  tags:
- FIXME

---

wird:

---

title: Linkdump KW FIXME/2022 url: /2022/xx-linkdump-kw-FIXME-2022 date: 2022-02-06T14:16:09+01:00 author: Natenom description: Linkdump für Kalenderwoche FIXME/2022 #disable_lightbox: true images:

- featured.png categories:
- Linkdump tags:
- FIXME

---

Bei Verwendung der Nextcloud-App sollte man also besser eine eigene App zur Bearbeitung verwenden. Ich nutze auf Android den Editor Markor.

Möchte man Markdown-Dateien auch im Browser bearbeiten, so kann man zusätzlich zum Standardeditor auch einen anderen installieren. Z. B. files_markdown.

Über die drei Punkte rechts wählt man ihn zum Öffnen der Datei aus:

Der Editor zeigt wahlweise nur den Quelltext an, Quelltext und Vorschau oder nur die Vorschau.

Für mich passt das. So kann ich auch mal im Browser meine Blogbeiträge bearbeiten.

Schön wäre, wenn man in Nextcloud einstellen könnte, dass Dateien immer mit dem neuen Editor geöffnet werden, damit man nicht versehentlich doch mal eine Datei kaputt macht. Weiß jemand, wie das geht? Falls ja, bitte unten bei “Kommentar” eine E-Mail schicken :) Danke.

Um die Breite an die des tatsächlich im Blog verwendeten Themes anzupassen, muss man ein paar Dinge anpassen.

Welche genau das sind, kann man hier nachlesen.

Unter „Einstellungen“ -> „Allgemein“ sind sowohl „WordPress-Adresse (URL)“ als auch „Website-Adresse (URL)“ auf http eingestellt und dadurch sollte eigentlich auch im gesamten Blog alles nur per HTTP eingebunden werden; dies hat in der Vergangenheit auch funktioniert.

Menschen, die auch einen Blog mit selbst signiertem Zertifikat betreiben, können das ja mal im eigenen Blog überprüfen.

Ich weiss nicht genau, ob das erst seit dem Update auf 4.2 so ist oder schon länger.

Alte Artikel korrigieren

Um die Bilder in allen bisherigen Beiträge von https auf http umzustellen, habe ich das WordPress Plugin Search Regex verwendet und damit die Strings „/wp-content/uploads/“ durch „/wp-content/uploads/“ ersetzen lassen:

Problem insgesamt beheben?

Eine Lösung für das Problem konnte ich bisher leider nicht finden und ein kostenpflichtiges SSL-Zertifikat ist mir viel zu teuer. Auch kenne ich mich mit WordPress nicht wirklich aus, um das Problem zu lokalisieren.

Deshalb begnüge ich mich zunächst damit, nach dem Erstellen eines Artikels mit dem oben genannten Plugin alle neuen URLs von Grafiken mit http zu ersetzen.

Melde mich, wenn es was Neues diesbezüglich gibt. Vielleicht weiss ja jemand, wie man das lösen kann :)

Update vom 11.05.2015:
Es gab in der Zwischenzeit zwei Sicherheitsupdates für WordPress und heute gerade ist mir aufgefallen, dass das Problem nicht mehr auftritt.

Die Lösung gibt es in den Kommentaren des Bugreports, siehe hier. Es gibt je ein Vorkommen beider Strings in der genannten Datei und die Anführungszeichen gehören dazu.

Weitere Informationen zum Plugin gibt es hier und zum DokuWiki-Update hier.

Im weiteren Text werden für beide Wikis nur noch Abkürzungen verwendet, DW für DokuWiki und MW für MediaWiki.

Editor

Der als Erweiterung mitgelieferte Editor WikiEditor bietet nur die wichtigsten Elemente an, wie auch der Editor in DW; macht aber nichts, schließlich kann man sich an die neue Syntax ziemlich schnell gewöhnen.

Syntax-Highlighting von Haus aus gibt es in keinem der Wiki-Systeme. Für DW kann man sich dafür z. B. den Ace-Editor installieren.

Für MW bietet sich wikEd an. Es gibt mehrere Möglichkeiten, diesen Editor System-weit, pro Benutzer, etc. zu installieren, siehe hier. Den WikiEditor benötigt man dann nicht mehr und kann diesen in LocalSettings.php deaktivieren.

Das Ergebnis sieht zwar etwas altbacken aus, aber dafür gibt es viele nützliche Funktionen:

[][8]

Durch das Script von wikEd werden externe Daten im Wiki eingebunden, auch wenn man das Wiki nur betrachtet. Daher sollte man aus Datenschutzgründen die Installation pro Benutzer vorziehen. Hierfür muss die Einstellung wgAllowUserJs aktiviert werden.

Wer einen WYSIWYG-Editor benötigt kann sich z. B. den noch in der Beta-Phase befindlichen VisualEditor installieren. Dann muss aber zusätzlich noch ein Daemon namens Parsoid auf dem Webserver installiert werden.

Responsive Design

Der Standard-Skin namens Vector ist nicht „responsive„, d. h. die Anordnung der Elemente ändert sich nicht auf kleinen Bildschirmen von Mobilgeräten; bei DW ist dies Standard.

Als umständliche Lösung kann man auf die Erweiterung MobileFrontend zurückgreifen, die über PHP anhand des User Agents herausfindet, ob es sich um ein Mobilgerät handelt. Ist dies der Fall, wird die mobile Variante des MediaWikis angezeigt, die man auch von Wikipedia.org kennt:

[][16]

Alternativ können Benutzer selbst die mobile Variante aufrufen.

In der Liste der verfügbaren Skins gibt es nur einen, der als „stable“ gekennzeichnet und „responsive“ ist, dieser hier.

Navigationsbaum

Am meisten fehlt mir eine Art Navigationsbaum, wie z. B. Indexmenu von DW. Hier konnte ich bisher nur die Erweiterung TreeandMenu finden, habe mich aber noch nicht weiter damit beschäftigt.

Tags

Von DW kenne und nutze ich gerne sogenannte Tags, die es z. B. auch in WordPress gibt. Dadurch lassen sich gleichartige Artikel sehr gut gruppieren. Bei MW gibt es diese Funktionalität gar nicht.

Kategorien

Dafür kann man in MW Seiten mittels Kategorien gruppieren, die es wiederum in DW nicht gibt bzw. nur sehr umständlich.

Wie man eine sinnvolle Struktur mit Kategorien aufbaut hat sich mir noch nicht offenbart, vielleicht kommt das noch nach dem Studium der umfangreichen Dokumentation. Hier gibt es ein paar Überlegungen dazu.

Es gibt auch Unterkategorien, siehe hier.

Eine interessante Erweiterung für Kategorien ist CategoryTree.

Templates / Vorlagen

Einer der gewichtigsten Gründe, wieso ich mich mit MW beschäftigen wollte, sind Templates. Diese arbeiten im Prinzip wie eine Funktion, der man Werte übergeben kann. Die Ausgabe erscheint dann an der Stelle, an der das Template in anderen Seiten verwendet wird.

Mit Templates hat man ein gutes Mittel, um z. B. Infoboxen zu erstellen, Videos einzubetten usw. In DW wird dafür je ein eigenes Plugin benötigt.

Es gibt zwei Möglichkeiten, um an Templates zu kommen…

Möglichkeit 1 – Templates aus anderen Wikis exportieren

Über die Export-Funktion von MW kann man sich prinzipiell aus jedem MW die gewünschten Templates exportieren und in das eigene Wiki importieren. Dies funktionert optional mitsamt Abhängigkeiten von anderen Templates und Modulen ziemlich gut. Es fehlen jedoch Style Sheets (CSS), JavaScript und Bilder. Diese muss man sich selbst besorgen. Vielleicht geht es doch und ich habe es nur nicht gefunden.

Mitsamt Abhängigkeiten importiert man z. B. für das Template Infobox von Wikipedia eben mal um die 50 weitere Templates und Module, um in meinem Fall festzustellen, dass es am Ende doch nicht funktioniert. Schade, denn dieses Template war einer der Gründe, dass ich mich näher mit MW beschäftigen wollte.

Möglichkeit 2 –Templates selbst erstellen

Wegen der Problematik mit den Abhängigkeiten bin ich ziemlich schnell dazu übergegangen, Templates selbst zu erstellen. Das bedeutet jedoch ziemlich viel Arbeit und ich habe diesbezüglich noch Einiges vor mir.

Man kann es durchaus als Vorteil ansehen, wenn man sein Wiki dadurch individueller gestalten kann, z. B. mit an das Wrap-Plugin angelehnten Boxen:

[][31]

Die verwendeten Icons stammen übrigens vom Oxygen Projekt (siehe hier).

Programmierung

Ist die Erweiterung ParserFunctions installiert, kann man sogar aus der Programmierung bekannte Dinge wie if, switch und mehr verwenden – in Templates und auch in normalen Seiten. Noch mehr Möglichkeiten erhält man durch die Erweiterung Scribunto, mit der es möglich ist, die Scriptsprache Lua zu nutzen.

Verschieben

Mir gefällt es, dass beim Verschieben von Inhalten per Voreinstellung eine Weiterleitung von der alten Position zur neuen erstellt wird, egal ob man Seiten, Templates oder Dateien verschiebt bzw. umbenennt. In DW muss man dazu die Ursprungsseite löschen, die Zielseite erstellen und dann z. B. mit dem Plugin Redirect eine Weiterleitung einrichten. (Für experimentierfreudige Menschen gibt es für DW ein in Entwicklung befindliches Plugin namens Move, siehe hier.)

Mit Dateien arbeiten

Habe mir für DW öfters die Möglichkeit gewünscht, bestimmte Informationen direkt an die Datei zu binden; in MW geht dies, da letztlich die Übersichtsseite einer Datei auch nur eine normale Seite ist. Außerdem sieht man dort auch, auf welchen Seiten die Datei verwendet wird.

Was mir gar nicht gefällt ist die Tatsache, dass alle hochgeladenen Dateien aus Wiki-Sicht in demselben Pfad liegen (auf dem Server natürlich nicht). Es ist nach meinem aktuellen Kenntnisstand nicht möglich, Dateien über Verzeichnisse zu strukturieren. Das bedeutet, dass jeder Dateiname eindeutig im gesamten Wiki sein muss. (Habe ich da etwas übersehen?)

SpecialPages

Im Bereich „Special:SpecialPages“ findet man Vieles, was man in DW nur teilweise über Plugins realisieren kann, z. B. Listen von ungenutzen Dateien, gewünschten (weil in einer Seite verwendeten aber nicht existierenden) Seiten, sehr kleinen Artikeln, Seiten ohne Kategorie usw.

Upgrade

Ein Upgrade ist bei MW etwas aufwendiger, siehe hier. In DW lässt sich das gesamte Update mittels des Plugins Upgrade im Interface selbst erledigen.

Update: Mit dem richtigen Weg per Patchfile lässt sich ein MW sehr viel einfacher upgraden als ein Dokuwiki; habe das erst später erfahren dürfen :)

Feeds

In MW lässt sich bei Ansicht der Versionsgeschichte jeder Seite über das kleine RSS-Symbol in der Toolbox ein eigener Feed abrufen:

[][42]

In DW geht das zwar auch, jedoch nur umständlich, da man sich den URL für den Feed selbst zusammenstellen muss, wenn man nicht das ganze Wiki beobachten möchte, siehe hier.

Änderungen an CSS und JS

In DW muss man für Änderungen am Design die entsprechenden CSS- oder JavaScript-Dateien direkt auf dem Webserver bearbeiten. In MW dagegen lässt sich dies im Wiki selbst erledigen (z. B. im Bereich „MediaWiki:Vector.css“) und man erhält dadurch auch eine Versionierung der Dateien; das gefällt mir sehr gut.

\o/

Habe ich schon gesagt, dass ich MediaWiki und DokuWiki mag?

Passt.

Da bestimmt noch mehr zu MediaWiki kommen wird, gibt es jetzt eine neue Kategorie hier im Blog.

Die beiden Icons im Artikelbild stammen von hier und hier.

Deshalb verwendet ich schon sehr lange das Plugin „Ace Editor“ von „Albert Gasset“, das beim Bearbeitung von Inhalten zwar immer noch den Quelltext anzeigt, den Bearbeiter jedoch mit Syntax-Highlighting, Farbschemata, Tastenkürzeln und neuen Funktionen unterstützt.

Änderungen im Editor

• Links sind unterstrichen und die Link-Beschreibungen werden farbig dargestellt
• Die aktuelle Zeile wird hervorgehoben
• Zeilennummern werden angezeigt
• Verbesserungen beim Bearbeiten von Tabellenstrukturen, siehe unten

Farbschemata

Verwende selbst das Farbschema „Terminal“, welches zusätzlich noch den Hintergrund des Editors dunkel darstellt; es gibt viele weitere Farbeschemata, die man über die Einstellungen des Plugins aktivieren kann.

Vergleich

Hier zwei Screenshots, erst mit dem Standard-Editor von DokuWiki, dann mit dem „Ace Editor“:

[][4]

[][5]

Sehr viel übersichtlicher – vorausgesetzt man kennt die Syntax :)

Der neue Editor lässt sich beim Bearbeiten jederzeit über das kleine Wolken-Icon rechts unten deaktivieren.

Die Einstellungen, die man rechts unten ändern kann, werden übrigens per Cookie gespeichert.

Tastenkürzel

Interessant sind ein paar Tastenkürzel, von einige leider einige nicht nutzbar sind, da sie bereits vom Browser verwendet werden. So z. B. [Strg]+[R], was schade ist, da man damit „Suchen und Ersetzen“ nutzen könnte. Habe für Firefox schon diverse Addons ausprobiert, mit denen es möglich sein soll, Tastenkürzel zu deaktivieren – bisher hat keines davon funktioniert.

Update: Wenn man zweimal [Strg]+[F] nacheinander drückt, erreicht man auch den Ersetzen-Dialog.

Nutze z. B. folgende Tastenkürzel:

• [Strg] + [L] – springe zu einer bestimmten Zeilennummer
• [Strg] + [D] – löscht die aktuelle Zeile
• [Strg] + [T] – vertauscht die Positionen der beiden Buchstaben, zwischen denen sich der Cursor aktuell befindet

Andere genannte Tastenkürzel in der Referenz funktionieren dagegen mit allen Editoren und sind Standard.

Etwas nervig ist zu Beginn die geänderte Funktionsweise von [Strg]+[Cursor links] und [Strg]+[Cursor rechts], hier springt der Cursor normalerweise zum Ende/Anfang des letzten/nächsten Wortes. Beim Ace-Editor wird das Ende eines Wortes, dann der Anfang des nächsten Wortes angesprungen, usw. Die Navigation mit diesen Tastenkürzeln dauert deshalb etwas länger; aber daran gewöhnt man sich.

Unterstützung in Tabellen

Beim Bearbeiten von Tabellen gibt es zusätzliche Tastenkürzel, die sehr hilfreich sind. Abgesehen davon werden Tabellen schön formatiert dargestellt, wenn man über das kleine Pfeil-Symbol rechts unten den automatischen Zeilenumbruch deaktiviert:

[][8]

Ist die Tablle noch normal zu sehen, reicht das Drücken der [Enter]-Taste innerhalb einer Zelle aus, um die verbesserte Ansicht zu erhalten.

Ganz besonders zu empfehlen sind die Tastenkürzel [Alt]+[Cursor links] und [Alt]+[Cursor rechts], mit denen man die Reihenfolge von Spalten ändern kann; mit solche „kleinen“ Änderungen ist man sonst ewig beschäftigt.

Erweiterte Suche

Die Suchfunktion ([Strg]+[F]) ermöglicht eine normale Suche, eine nach Regulären Ausdrücken, einem ganzen Wort oder unterschieden nach Groß-/Kleinschreibung.

[][9]

Einstellungen

[][10]

\o/

Das Plugin gibt es hier; es funktioniert mit der aktuellen Version „Binky„.

Sehr zu empfehlen :)