Correction: "30-40 year old clients" should be "20-30 year old clients"

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com
https://useplaintext.email/

Hi!

Your post was pretty interesting!

I have a comment on one small part of your post:
> perhaps even a clever protocol for "web forums" generally.

There's already a protocol for that!  It's called Usenet (built on the
UUCP protocol much like Gemini is built on the TLS protocol):
=> https://en.wikipedia.org/wiki/Usenet
=> https://en.wikipedia.org/wiki/UUCP

While the old Usenet network is inactive and filled with spam, there's
not much stopping a new Usenet network from rising.  It's federated,

This adds links back to the wiki root index in two places: on the
pseudo-breadcrumbs with the username and wiki name, and on the "article"
tab.  This makes it possible to navigate back to the wiki index from any
wiki page, whereas before it was impossible.  The new links also fixes
the most counterintuitive link on the page, as the "article" tab linking
back to the site root (/) is very strange and unexpected.
---
This fixes the issue I previously raised here:
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C20210628153158.ptjf4is5apfhj6lx%40GLaDOS.local%3E

 mansrht/templates/content.html | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/mansrht/templates/content.html b/mansrht/templates/content.html
[message trimmed]

The routes for `user_content` in mansrht/blueprints/html.py include a
tilde ('~') in them, which is required for the route to function
properly.  However, .canonical_name already includes a tilde[a].  This
causes in a bug where any usage of user_content with the
owner.canonical_name field will result in a generated url where the
username is prefixed with two tildes ("~~nytpu") rather than one.

This replaces the usages of owner.canonical_name with owner.username
which is identical to .canonical_name (see link [a]) except that it does
not have a leading tilde.

[a]: https://git.sr.ht/~sircmpwn/core.sr.ht/tree/99a8168de436c576ec98242d255a71a2b94c9658/item/srht/oauth/user.py#L37
---
 mansrht/templates/delete.html | 2 +-
[message trimmed]

Hello,

I've noticed a minor, but fairly annoying issue on man.sr.ht.

When you're navigating around various pages on the wiki, it is
impossible to get back to the root index of the wiki unless the wiki
author explicitly put navigation links in their markdown.

For instance, if you're on this subpage:
https://man.sr.ht/~nytpu/test-wiki/subpage1.md
it is impossible to get back to the wiki root[a] via a link.  The only
way to get back is by editing the URL in your browser, or clicking to
the user's man.sr.ht/~user page, then finding the wiki in the list, and
clicking back into it; and this latter option doesn't work on unlisted

On 2021-06-12 12:22AM, mieum wrote:
> Would you like me to wait on this until we decide about the gempub
> generation mechanism/syntax? 
Yeah, that'd be best IMO

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --auto-key-locate=wkd --locate-key alex@nytpu.com
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/

On 2021-06-11 09:41AM, mieum wrote:
> So, for instance, headings preceeded by a '%' could indicate a
> chapter?  The added bonus of doing something like this is being able
> to automatically generate a ToC or break up long texts by chapter for
> non-gempub versions.
I like this.  Simple, and it automatically includes chapter titles to
the index/ToC.  In that case then we'd either need to start numbering
headers in the gemtext itself or have the converter script auto-number
the chapters, because gemtext doesn't auto-number for us usually.

> Another option would be to have a ToC key in the YAML frontmatter that
> specifies the names of the chapters (with some default values for
> indicating that every heading is a chapter or that there are no
> chapters etc.). This would eliminate the need for extra markup, but I

Accidentally wrote directly to mieum instead of to the list.

On 2021-06-10 10:35AM, mieum wrote:
> Ah, I see. I guess having fewer quality gempubs is better than a ton
> of awkward ones that slaughter the content. In that case I will update
> the readme with a link to the gempub spec and some notes about
> contributing them.
So is that a nack on possibly adding YAML (or something) throughout the
document to indicate where to break apart a file into separate files?

Thinking about it more it wouldn't add that much more for contributors
(just add markup every chapter break while you're converting to gemtext)
and it'd be pretty easy to convert from the one-page format to gempub if
you have actual markers on where to split it up (and also some

---
Added title and byline to body text itself.
 cataloging/chambers_the-king-in-yellow.gmi | 4087 ++++++++++++++++++++
 1 file changed, 4087 insertions(+)
 create mode 100644 cataloging/chambers_the-king-in-yellow.gmi

diff --git a/cataloging/chambers_the-king-in-yellow.gmi b/cataloging/chambers_the-king-in-yellow.gmi
new file mode 100644
index 0000000..00d04d8
--- /dev/null
+++ b/cataloging/chambers_the-king-in-yellow.gmi
@@ -0,0 +1,4087 @@
+---
+
[message trimmed]

On 2021-06-09 01:43PM, mieum wrote:
> Should this file have a title heading + byline? Is it preferrable to
> programatically insert those using the metadata, or to have
> contributors format submissions with a title and byline themselves?
I think it should.  In my opinion (I don't know what you envisioned),
you should be able to strip out all YAML and other such elements and get
a standalone gemtext document without having to make any modifications,
which means it should include all title, byline, and possibly copyright
info at the bottom.

Depending on how you decide formatting should possibly be changed, I'll
probably make a revision once some more stuff is finalized.

Thanks!