Converting from markdown to gemtext requires making some decisions about features that don't exist in gemtext. Ideally these decisions would be offered to the user as options, but I'm not sure how willing the pandoc project will be to create more command line flags just for this one format.

The main example of something that is not clear cut is inline links. Gemtext doesn't support them, but most document/markup formats do. How should they be handled?

This is something I have had to deal with for md2gemini. I've outlined the different options available for converting inline links on the README, in the link modes section. I hope this is useful to whoever ends up implementing this writer, and that my tool can suffice for some people in the meantime.

Yeah, I did start trying to make my own converter in Rust. I found there isn't an obvious way to "correctly" handle a few things.
For example, I had a function to sort of just normalize/round all of the header levels to a set that would work, e.g. it yields a hashmap {2:1, 3:2, 4:2, 5:3} if the header levels 2-5 are used in a document.

I'll likely keep working on it a bit but it's clear that starting with a config system to determine how to handle several things is a good first step.

Yeah, header levels is another good point. In md2gemini I just leave higher level headers as is, so level 4 would appear as #### text and just not be valid gemtext, but still be somewhat understandable.

I would appreciate getting a link to your converter! You should also send it to the mailing list for other people to check out.

I would also like to see pandoc having Gemtext support - can I have a try at implementing the Writer?

I think gemini might not have enough adoption yet for a regular pandoc writer. I'd suggest creating a custom lua writer. (If in the future we wanted a regular writer, this work wouldn't be wasted.)

For now, I find connecting pandoc and md2gemini to work decently.

pandoc your_document.docx -t markdown | md2gemini

I think Gemini might not have enough adoption yet for a regular Pandoc writer

Won't there always be a chicken-egg situation here? Less people bother converting to Gemtext because Pandoc doesn't support it? If it were as easy as Pandoc -> HTML followed by Pandoc -> Gemtext, I think you'd see more people putting it in the build pipeline for their blogs and docs.

Won't there always be a chicken-egg situation here?

Yes, there will. That's a valid point, but think about the converse proposition for a second. If picking technologies we think should thrive and favoring those implementations were the driving force behind Pandoc, what would be to stop us from removing DOCX support, or for that matter removing all formats except Common Mark, SILE, and org-mode? Surely those are the three best formats for general prose content, typeset rendering, and interlinked personal wiki respectively. Web browsers should just render from CommonMark?

I jest — mostly. The point is exaggerated, but the point that picking implementations based on advocacy for a technology that isn't widely used rather than extant usage would completely reshape not just the current feature set but the actual utility (or lack thereof) and contributor pool (or shallowness thereof).

See also: #7353 (comment)

That's fair. Is there specific "bar" that needs to be met and is it documented? It seems this sort of request probably comes up a lot then for every sort of document language that wants to get adoption.

Where Gemini+Gemtext caught my eye is that SourceHut supports it natively for their 'Pages' which is a small endorsement (though unclear if it's for them or publishing for users, SourceHut's main maintainer says there will be more support in the future), but I would then assume that that doesn't count as a making the cut. This said, it appears there are a fairly large set of non-Pandoc tools for moving between some formats for now, like what was posted in a previous comment.

No I don't think there is an exact bar for this. Somebody interested in it that is willing to contribute the Haskell code to make it happen is probably the biggest factor, bonus points for prior activity in Pandoc development. A developer that wants to contribute something counts for more than a lot of people wanting it but needing somebody else to code it up for them. After that the availability of solid specs and other open source tooling makes a big difference. Finally of course lots of different people requesting/upvoting the same thing eventually gets more notice than one squeaky wheel.

Hi! Has this discussion been completely dropped or there is a chance for Pandoc to support importing and exporting from/to Gemtext?

I believe it would be extremely useful.

I think this still holds true: #6747 (comment).
Note that pandoc now supports custom readers, so support for reading and writing could be added by doing a bit of Lua coding.

I found a pandoc filter that can convert to gemtext https://github.com/kr1sp1n/gemini-pandoc-lua-filter