From int 80h to ~adnano/gemini
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
From int 80h to ~adnano/gemini
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
From int 80h to ~adnano/gemini
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. >
From int 80h to ~adnano/gemini
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
From int 80h to ~adnano/gemini
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
From int 80h to ~adnano/gemini
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
From int 80h to ~adnano/gemini
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
From int 80h to ~adnano/gemini
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
From int 80h to ~adnano/gemini
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
From int 80h to ~adnano/gemini
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