On Sun Jul 5, 2020 at 9:49 PM EDT, Hannu Hartikainen wrote:
> The general idea is that a single line of input[1] works for very few
> text
> editing interfaces, yet most of us know one: sed. Mostly people use a
> very
> small subset of sed. Here I've implemented a slightly larger subset and
> I
> feel you could actually edit pages quite well if the browser showed line
> numbers.

I really like the idea of using sed for a wiki interface. Nice work.

int 80h

On Mon Jun 8, 2020 at 1:26 PM EDT, solderpunk wrote:
> Oh, sorry, I misunderstood! That seems perfectly cromulent, although
> I'd be a bit wary myself of tying my content to a specific server
> (unless this convention became widely adopted).

True that could get annoying if it wasn't widely adopted.

int 80h

On Mon Jun 8, 2020 at 3:36 AM EDT, solderpunk wrote:
> No, the "lang" parameter is a parameter to the text/gemini MIME type
> which is part of the response header. It doesn't go in the document
> itself. Server software will need to provide admins and/or users some
> way to configure this.

The way I was thinking is have the server look at the first line for
"#lang" then strip it and put it in the response header. That way it
could be an implementation of the server and not the spec itself.

> Multi-lingual sites would probably work best with content in different
> languages separated by the path hierarchy, and servers could let people
> designate different languages depending on which regex the path matches.
>

On Sun Jun 7, 2020 at 3:06 PM EDT, Matthew Graybosch wrote:
> I just read the relevant part of the spec, but I'm still not clear on
> how I should go about specifying that my text is US English. Do I just
> have to add "lang=en_US" on the first line of a text/gemini file?

I'm not sure how other server writers did it but I added "lang" as an
option per vhost, currently on the dev branch.

I've suggested adding "lang" to the first line before[1] but I need to
reread that discussion to see if anyone else commented on it.

[1] https://lists.orbitalfox.eu/archives/gemini/2020/000845.html

int 80h

On Sat Jun 6, 2020 at 7:37 PM EDT, Luke Emmet wrote:
> I'm now decoding the query on the server side. Does it work for you now?
>
> This may have revealed a client bug I need to fix

Just a heads up, bombadillo doesn't encode the query string.

int 80h

On Sat Jun 6, 2020 at 2:40 PM EDT, Matthew Graybosch wrote:
> That's exactly what I needed. Thanks again.

And thank you

int 80h

On Sat Jun 6, 2020 at 11:08 AM EDT, Matthew Graybosch wrote:
> You're welcome. I'd be happy to patch Gemserv next as I mentioned
> before, but I'll need a versioned tarball whenever you've got one
> ready (no rush, of course). Slackbuilds isn't like AUR on Arch Linux;
> they don't take scripts that involve cloning git repos. :)

I pushed a tag so you can download a tarball from srht. Does that work?

int 80h

On Thu Jun 4, 2020 at 3:41 PM EDT, Matthew Graybosch wrote:
> Hi, everybody. I was reluctant to use the [ANN] tag in the subject
> because I don't have a new Gemini server to announce *yet*, but I
> wanted to let everybody know that I've started packaging some Gemini
> software for Slackware as Slackbuilds.

That's cool. Just want to say thanks to you and anyone else that
packages software.

int 80h

On Thu May 28, 2020 at 11:38 AM EDT, tastytea wrote:
> For example, <gemini://tastytea.de/dotfiles/.emacs.d/init.el> returns
> ?20 text/gemini??. Files without a file extension are also returned
> as
> text/gemini.
>
> I think text/plain is better suited as the default type for unknown
> files.

That's probably a good idea. The only difference is formatting so that
that would make more sense. Thanks.

int 80h

On Sat May 23, 2020 at 5:58 PM EDT, Sean Conner wrote:
> //hostname:port/filename
>
> Per the URL spec (RFC-3986), the '//' is part of the host portion of the
> URL.

That's also what gemini-diagnostics[1] uses in its URLSchemeMissing test.

[1] https://github.com/michael-lazar/gemini-diagnostics

int 80h