Okay, that's enough progress for today on the rewrite of my to conversion pipeline.

Added a pre-processor that allows me to add ,gemini=hidden to links I don't want to show up in the gmi document, and ,gemini=extend-to-eol for links I want to extend to the end of the line.

I don't expect others to find this useful, but so far it looks like it will help reduce link clutter in documents, without having to handcraft a version of the same blog post.

@FiXato You write your blogposts in asciidoc? That's unusual and interesting. What is your historical context for this preference?

I tried for a while to write hpr shownotes in asciidoc, but the html output upset @perloid 's sensibilities. When I dragged it through docbook and pandoc it came out a bit tidier, but in the end I went back to Markdown.

@clacke while I find markdown easier to write, I found it too limited for what I wanted to do with it for my blog, at least without resorting to including HTML in the source document, which would ruin legibility imho.

An example would be having collapsible blocks. I could include summary/details HTML tags in the (GFM) markdown document to achieve that, but that would defeat the purpose.

With I can do the following:

.Summary title for section
Expandable details for section block.

It's still not ideal, but I found it more in line with a legible plain text document.

(The primary planned use-case for this would be adding content-warnings to paragraphs/sections.)

@clacke as for the html output of asciidoc: I've found that the asciidoctor-html5s backend generates a more acceptable, semantic, HTML output.

@FiXato I see you found it through airing the same concerns and getting help from fedi as well. =)…

@clacke @FiXato I use asciidoc on a daily basis for my own purposes, and of course it's head and shoulders above Markdown as regards features. The problem we had on HPR was that our HTML notes get sent to (as the item description field) and their HTML filters are harsh (or were, I haven't checked lately) and tend to strip a lot of the "fancy" asciidoc stuff. So not my "sensibilities" more a pragmatic approach 😉

@perloid @FiXato Thank you for clarifying. =)

Frowning at asciidoc HTML output is pretty sensible either way. <div class="paragraph"> is not how you write a paragraph in HTML.

@clacke @perloid my "Now" page is generated with the asciidoctor-html5s backend, and while it could probably still be improved some, it's a lot more semantic than the default output.
(and actually uses p tags for paragraphs)

gemini:// would be an example of what my current conversion pipeline makes out of it.

If you don't have a gemini client (personally I'm fond of and ), then you can use f.e. the http proxy.

If you're interested, I can also put the source asciidoc file online.

@FiXato Is the code for your to conversion pipeline available somewhere? I'd love to use it and maybe help improve it, if I can!

@DuncanLock but it's been a while since I last pushed changes and it's fairly undocumented.

@DuncanLock yeah, looks like I have a whole bunch of uncommitted changes locally, including support for a config file and a bunch of replacement fixes; I'll see if I can clean those up and push them to the sourcehut repo today :)

@FiXato I got this working like this:

$ git clone
$ cd gemini-tools/
$ python3 -m venv ~/venv/gemini-tools
$ source ~/venv/gemini-tools/bin/activate
$ python -m pip install -r ./requirements.txt


$ python -m pip install xdg python-slugify md2gemini

.. and it seems to work pretty well! Thanks!

@DuncanLock yeah, that sounds about right :)
Reminds me that I need to add those last two packages to the requirements.txt :)

Sorry I haven't been able to add the latest changes yet though; haven't really had the headspace to code much the past couple of days :/

Sign in to participate in the conversation

On the internet, everyone knows you're a cat — and that's totally okay.