The rCLproblemrCY is that I canrCOt just point a Gopher server at that same generic content and call it done.
IrCOm willing to find some middle ground
and adapt my web site generation, but that has me wondering what other people out there might be using (if anything!) in 2026 for their own
setups.
So back to the question: does anything remotely *like* those approaches already exist? Any thoughts/pointers would be appreciated. Thanks!
I recently played around with setting up a Gopher server, and as much as I like the old-school-simplicity of the protocol, what discourages me from maintaining public-facing spaces is that I can?t seem to find any sorts of authoring tools that integrate well with my non-1990s work flow.
For reference, I do have a couple bare bones web sites. They use Apache `autoindex`, which sets up navigation ?menus? for me much like Gopher. My new content is mainly Markdown these days, which gets converted to HTML
for the browser. A bit of CSS gets it looking (I think) a little bit
better than the default render. Done. I do also have some much more advanced dynamic sites, but for publishing basic content, I?d really like
to not have to deal with *any* of the everything-and-the-kitchen-sink web.
The ?problem? is that I can?t just point a Gopher server at that same generic content and call it done. I?m willing to find some middle ground and adapt my web site generation, but that has me wondering what other people out there might be using (if anything!) in 2026 for their own
setups.
In particular, Gopher menus/maps may have somehow seemed like a good
format choice at the time, but I find them to be *terribly* dated. At
least conceptually, I could see an easy lateral move to actual TSV
support, allowing Gopher to maybe be seen as ?the web, but using spreadsheets?.
One other thing I tried that worked well was using YAML as the base
format, with the document being a list of text nodes mixed in with the
links as arrays. The raw text file was itself *very* readable/editable,
and it was almost trivial to convert it to a gophermap file that the
server was happy with. And with YAML being a superset of JSON, I could
see that method making integration with a lot of existing web pipelines
very doable.
So back to the question: does anything remotely *like* those approaches already exist? Any thoughts/pointers would be appreciated. Thanks!
It was thus said that the Great Doc O'Leary , <droleary.usenet@2023.impossiblystupid.com> once stated:
The rCLproblemrCY is that I canrCOt just point a Gopher server at that same
generic content and call it done.
Perhaps get a better gopher server?
but the "index.port70" is
an easier format to author that my gopher server will translate on the fly.
I also wrote a module (similar to an Apache module) that will convert my blog entries [3] from HTML to plain text (wrapping with a margin of 80 characters) [4].
So are you wanting to just poing a gopher server to an existing web site and have it "just work?" Or just to an existing directory and have it "just work?" Because the approach for one isn't the same as the other.
Authoring tools? It's text, for which most use a text editor...
I also markdown format my text files, in case I want to convert to another document type which allows for more formatting options, and just point my gopher server at them and call it done.
You just need to generate your gopher maps programmatically.
[1|Search (Quarry gopher search engine and more ...)|/quarry|server|port]
I use the same format.
Keep it simple, have fun.
For your reference, records indicate that
IanJ <SPAMian_jones_01@yahoo.co.uk.invalid> wrote:
Authoring tools? It's text, for which most use a text editor...
Well, most *don?t* use Gopher at all. Most who publish other formats
that work in a text editor also make use of things like syntax
highlighting, preview panes, and other aids to help get the format
correct.
I also markdown format my text files, in case I want to convert to another >> document type which allows for more formatting options, and just point my
gopher server at them and call it done.
And if it were just *formatting*, that would be my approach, too. But,
as you know, [Markdown](https://en.wikipedia.org/wiki/Markdown) supports links and
that would be more friendly rendered as a gophermap.
You just need to generate your gopher maps programmatically.
And that?s the software stack I?m asking about. If there?s nothing
commonly used and/or it?s all baked into server projects, that is useful
to know.
[1|Search (Quarry gopher search engine and more ...)|/quarry|server|port]
I use the same format.
Why another custom format?
Keep it simple, have fun.
That?s exactly what I?m trying to do. I?m just not sold on that idea
when it seems like everyone had to implement their own custom server!
For your reference, records indicate that
IanJ <SPAMian_jones_01@yahoo.co.uk.invalid> wrote:
Authoring tools? It's text, for which most use a text editor...
Well, most *donrCOt* use Gopher at all. Most who publish other formats
that work in a text editor also make use of things like syntax
highlighting, preview panes, and other aids to help get the format
correct.
I also markdown format my text files, in case I want to convert to another >> document type which allows for more formatting options, and just point my
gopher server at them and call it done.
And if it were just *formatting*, that would be my approach, too. But,
as you know, [Markdown](https://en.wikipedia.org/wiki/Markdown) supports links and
that would be more friendly rendered as a gophermap.
[...][removing the rest of the quoted text as I don't have answers to go with
For your reference, records indicate that
sean@conman.org wrote:
I also wrote a module (similar to an Apache module) that will convert my
blog entries [3] from HTML to plain text (wrapping with a margin of 80
characters) [4].
Why plain text instead of gophermap? I see Gopherpedia seems to take the same approach, and it doesn't make much sense to me to strip out links completely like that.
One thing I really like about Gopher is that the navigation and
content is (meant to be) separate, so you can navigate around
a Gopher hole quickly with the keyboard, and with minimal thought.
There are some gopher clients that do render markdown files, do your homework.
Weren't you talking about a custom TSV format or using YAML?
For your reference, records indicate that
IanJ <SPAMian_jones_01@yahoo.co.uk.invalid> wrote:
There are some gopher clients that do render markdown files, do your homework.
That?s exactly what I?m trying to do here, and frankly your dismissive attitude isn?t reflecting particularly well on the Gopher community.
Maybe you know the ecosystem inside and out, but some of us don?t and
our ?homework? turns up a lot of unrelated things (e.g., the Gopher name
has been adopted by the Go programming language for something, which
makes searches on even techie places like GitHub practically worthless).
Weren't you talking about a custom TSV format or using YAML?
I was talking about the ?standard? formats for both. What would be Gopher-specific would be how the content data is interpreted and used to generate the ?standard? gophermap format. The point being that, from an authoring/parsing/whatever perspective, the stack would be built on that common format and require little extra retooling, whereas everyone
having their own fiddly format makes adoption just that much more unfriendly.
Doc O'Leary , <droleary.usenet@2023.impossiblystupid.com> wrote:
For your reference, records indicate that
sean@conman.org wrote:
I also wrote a module (similar to an Apache module) that will convert my >>> blog entries [3] from HTML to plain text (wrapping with a margin of 80
characters) [4].
Why plain text instead of gophermap? I see Gopherpedia seems to take the
same approach, and it doesn't make much sense to me to strip out links
completely like that.
One thing I really like about Gopher is that the navigation and
content is (meant to be) separate, so you can navigate around
a Gopher hole quickly with the keyboard, and with minimal thought.
First search on duckduckgo 'gopher client markdown support':
Your standard format
My, and probably many others, menu generation is automated by scripts
to avoid directly working with them. The content is all hand crafted so, there is no tooling required but a text editor. *If* you don't go
down the path of making everything a menu...
Have you considered Gemini? You will probably find that more to your
liking. :)
For your reference, records indicate that
IanJ <SPAMian_jones_01@yahoo.co.uk.invalid> wrote:
First search on duckduckgo 'gopher client markdown support':
Not for me. There are no links to the mentioned clients in my first two pages of results. I don?t know why anyone would think in 2026 that web search results are going to be the same for everyone. Look, if *you* can and do want to help, I will thank you for doing so. If you are just
trying to be a jerk trying to dunk on anybody stupid enough to be curious about Gopher (on *Usenet* of all places! :-), I can do without that.
No, Gopher itself still seems just fine, if I can work out the
navigation kinks. I am still not a fan of any approach that does not
allow citations in text to easily link to their source.
Extreme Kobolds, Boca Raton edition
As my tires were being addressed at a local tire shop [1], I meandered
across the street to have lunch and browse at some stores to kill some time. At a gaming store, I came across this little fellow defending this terroritory:
[A life sized and colored statue of a D&D kobold in a defensive stance] He spoke softly and carried a very big and pointy stick to make his point. [2]
He seemed very keen on keeping this corner of the store to himself. I let him be.
[1] gopher://gopher.conman.org/0Phlog:2026/06/11.1
[2] gopher://gopher.conman.org/IPhlog:2026/06/12/kobold.jpg
Here's an example of an entry (as a plain text file) that contains links:
spoke softly and carried a very big and pointy stick to make his point. [2] >>
He seemed very keen on keeping this corner of the store to himself. I let >> him be.
[1] gopher://gopher.conman.org/0Phlog:2026/06/11.1
[2] gopher://gopher.conman.org/IPhlog:2026/06/12/kobold.jpg
It was a tradeoff. I could have made this into a gopher map, but the
links would have still to be on their own line (as is done here), and
there's still some out there that dislike the 'i' type (as it's not technically a link and gopher clients can simply ignore and not display them if they don't understand them, but that's probably very old clients not in use anymore).
I opted for plain text because I could make use of an assumed 80-column display (controversial today, if because most people use phones for
browsing) and not the 65ish that you can "safely" use on a gopher map.
One other tradeoff---displaying the links as URLs, assuming the gopher client can understand it, and that one can cut-n-paste the url.
-spc
Frankly you appear incredibly arrogant.
unless you start
to attempt to work in ways that gopher wasn't designed for.
For your reference, records indicate that
IanJ <SPAMian_jones_01@yahoo.co.uk.invalid> wrote:
My, and probably many others, menu generation is automated by
scripts to avoid directly working with them. The content is all
hand crafted so, there is no tooling required but a text editor.
*If* you don't go down the path of making everything a menu...
Again, my aim is not to be Gopher-centric anymore than I want to be Web-centric. Since there is no base format (beyond ASCII text) that
is universally supported across all/most publishing platforms, some
form of tooling *will* be necessary to give the best experience to
users of each one.
No, Gopher itself still seems just fine, if I can work out the
navigation kinks. I am still not a fan of any approach that does not
allow citations in text to easily link to their source. At best,
using Wikipedia as an example, I could see the initial result page
being a map that had the top text followed by links to the text of
each section in the TOC (which would help with the rCLwall of textrCY feeling I got trying Gopherpedia), with the sections that are mainly
links anyway (References, See Also, etc.) also being maps.
I think you already understood that there's no "stack" commonly used
for what you ask.
Because, what you ask is, even if you don't want it
to be, clearly web-centric since you ask for hyperlinks within files
easily usable (like you click on it, or hit enter and your client
redirect you like on the http web).
Gopher wasn't meant to work like
this. As already said by others, it just shares files (whatever they
are) inside directories (selectors). You browse the selectors and open
the files to read/download them, and that's it (yes, I'm aware of the
2, 7, 8, + and T items but that's for an other discussion).
The blog generator is named cl-yag and can be found here:
git://bitreich.org/cl-yag
In the hope that it helps you.
And maybe, one day, you'll just say to yourself: "heck, I don't want
to bother myself anymore with all this. All I need is a text editor!
So I will from now on just put good ol' plain text in directories and
edit my gophermap by hand from within my TTY like those cavemen from
the 90's. Really, my visitors are here for the content, they know how
to navigate by themselves and, if not, well I'm confident enough
they'll figure it out."
For your reference, records indicate that
f6k <f6k@huld.re> wrote:
I think you already understood that there's no "stack" commonly used
for what you ask.
No, I didnrCOt. And I still donrCOt! Maybe being deep into the Gopher ecosystem makes people think that everyone just *knows* what is broadly available, but those of us on the outside looking in who are still only Gopher-curious (possibly, if theyrCOre old enough, with vague memories of what it was back in the day) donrCOt understand what best practices are.
I disagree. I mean, it would not surprise me *at all* if someone had
said thererCOs a Jekyll-like tool that generates rCLproperrCY Gopher spaces from some Markdown and associated metadata. Personally, I use reference links (*often* in the form of footnotes) in my Markdown all the time!
It would not bother me one whit if they were all collected up in some
sort of rCLFurther ReadingrCY menu that slotted in at a higher level in the map.
But, yes, to the extent that you have everything as files of a type
that was around in the early 1990s, I get that you donrCOt need much of a stack. But thatrCOs not where most people are starting from these days. And quite a bit of what IrCOd like to make available is in SQLite
databases, so itrCOd be *real* handy if there were already some easy way
to make a happy Gopher experience out of it.
The blog generator is named cl-yag and can be found here:
git://bitreich.org/cl-yag
In the hope that it helps you.
Thank you for this pointer. Although I doubt IrCOll be using it directly (since itrCOs pretty Lisp-centric), the ideas behind it could be useful
in what I might end up coding myself.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 45:25:43 |
| Calls: | 1,100 |
| Files: | 1,339 |
| Messages: | 275,372 |
