mastodon.gamedev.place is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server focused on game development and related topics.

Server stats:

5.1K
active users

#asciidoc

1 post1 participant0 posts today

Should I dare to do a "why #Markdown is one of the worst lightweight markup syntax languages there is"-session at a UX/UI-dominant #barcamp? 😜

C'mon, do push me over that cliff! 😆

Background: karl-voit.at/2017/09/23/orgmod 👉 it's related but would be a different focus since I won't push #orgdown that much - people can be happier with other LMLs as well as long as it's not the #MD hell. (Sneak preview: I'm writing a long article on all the MD issues in order to explain it once and for all since the Mastodon discussions are really annoying to me.)

public voit - Web-page of Karl Voit · Org Mode Syntax Is One of the Most Reasonable Markup Languages to Use for TextOrg Mode Syntax Is One of the Most Reasonable Markup Languages to Use for Text
#LML#AsciiDoc#rSt
Replied in thread

@ajlewis2 @ellane @feralthoughts @hbowie @reichenstein

Just for clarification: same holds true for any other markup supported by pandoc, not just #Markdown.

However, if you stick with a syntax language that doesn't come with this explosion of flavors, you have less issues converting your data - in some cases you don't even have to convert at all any more.

The issue with Markdown is that its original form defined a small minimum of elements and each tool defined its own potentially incompatible extensions. With other #LML, the "original" or its standard defines the maximum set of elements and therefore, there is no need for "flavors" and no data loss or conversion effort.

HTH

Suche eine Stelle als techn. Redakteurin
im GR Nürnberg oder remote.

Arbeite aktuell in der SW-Doku (v.a. #AsciiDoc, MS-Office), bin als Quereinsteiger mit Physikstudium, Testinghintergrund und Reqiurementsengineering breit aufgestellt und in der Tekom engagiert.
Ich arbeite mich schnell in neue Themen, Techniken und Tools ein und bin für (beinahe) jedes Thema zu begeistern.

Freue mich auf Fragen, Angebote, Hinweise und Teilen des Beitrags.
#Nurnberg #fuerth #erlangen #fedijobs #fedihired

@david_megginson

This opposition of org-mode vs. (LaTeX, SGML) XML in publishing is something that resonates very strongly with me - though I'm afraid it's hard for many org users to understand.

I do almost all of my daily work in org-mode, but whenever I start a writing project that needs to be published, I use XML. There are all kinds of reasons for this, some very specific to my case of academic writing, where the handling of citations, footnotes and bibliography can get very complex and specific. But I feel that in the end it comes down to something much simpler.

For decades I have been using docbook-xml for all my writing projects, starting with drafting in asciidoc (and this co-existence of asciidoc and org-mode as two "markdown" dialects still leaves me unsatisfied). The deeper reasons however seem to be that in org-mode you start designing your text from an outline. For me, this is the wrong approach, as I need to write a text as a stream-of-consciousness, adding paragraph after paragraph, and only later get to an outline. The way I'm used to using org-mode seems to make this impossible for me.

Moved instance, so time for a new #introduction!

I'm Alex and I have a PDA problem.

In 2018, after 16 years of using various #Psion portables, I decided to try my hand at developing hardware and software for my beloved Series 3c to help me with journalling and creative writing.

6 years and repeated sidequests later, I've ended up doing a lot of research into the SIBO/EPOC16 platform, and done my best to document it when I can. I've also nudged former developers into open sourcing their old Psion apps.

My current main projects are:

  • #PsiDrive, an #RP2040-based USB drive for SIBO SSDs.
  • Rewriting the Psion SIBO (16-bit 8086) C SDK, including updating the docs (with #AsciiDoc) and rewriting the original DOS tools as FOSS apps. I'm currently using #FreePascal to create a drop-in replacement for #CTRAN, the Psion OO C preprocessor. (I want to eventually write a new compiler targeting EPOC16. Eventually.)
  • Anything else that tickles my bouncy brain.

Outside of #retrocomputing, I'm your common-or-garden British nerd. I'm a Linux user - mostly Arch, but I dabble with others. I also like a bit of #HaikuOS and I'm planning on giving #FreeBSD a go very soon.

I used to be a senior computer monkey, specialising in on-prem SME infrastructure (I lament the loss of vSphere). Now I train others to become computer monkeys (for better or worse). As a result, sometimes you'll see me wrestling with old Cisco ASAs, Ubiquiti APs, or modded kit running #OpenWrt.

Generally, I like making things do stuff, especially if it's stuff that the thing wasn't originally designed to do.

Replied in thread

@daniel My #notetaking system consists in writing #plaintext notes using the #vi editor. They are mostly structureless by design (i.e. no #Markdown, #Asciidoc or other markup), although I do follow certain conventions in writing them.

Notes are completely free of metadata, also by design. Metadata is stored in a separate, single JSON file. It allows for tagging and linking notes (linking only on note-level, since - as mentioned above - notes do not contain any metadata).

A #Ruby script provides convenience functions for performing operations on notes (like creating, editing, tagging, linking, viewing etc.).

Notes are tracked via git. Each operation which modifies a note (either the content of the note or its associated metadata stored in the separate file) and is performed via the convenience functions automatically leads to a commit to a git repo.

To conclude: My notetaking system is designed to be as independent of anything as possible. Without the Ruby script providing the convenience functions and the git repo, it would still be fully functional (the only difference being that operations on notes would be slightly more tedious, and their history would not be tracked) and depend only on an editor capable of editing text.

Ich habe es nach längerer Pause mal wieder geschafft fünf Minuten über ein Thema zu sprechen, das mich regelmäßig umtreibt: Dokumentation mit AsciiDoc 😉
Aber diesmal ohne viel Aufwand und Platzbedarf.

media.ccc.de/v/2024-07-03-joha

Es geht um den #TechStackCanvas, #ArchitectureInceptionCanvas und #ArchitectureCommunicationCanvas als #AsciiDoc Vorlage.