Hi all, I just joined the list but have read some of the recent messages and wondered if having a gemini-fmt tool like Go and Rust use to conform a source document to a pre-existing spec might solve some of the issues around Gemini documents meeting the spec and around properly configuring the meta headers. I feel like the people writing servers and clients are doing a huge service to the community, so having this gemini-fmt tool would help ease the load on them by ensuring that the Gemini documents that get uploaded to servers for public consumption and are then served to clients are more or less guaranteed to conform to the spec. This will save the people who write the servers and clients from having to spend time handling all kinds of edge cases. I'm including a preliminary outline of what I have in mind here below. Comments are welcome. Thanks, J -- # gemini-fmt idea ## Summary A tool for Gemini authors that automatically conforms their Gemini texts to the Gemini spec and also applies the author's preferences for meta headings such as spoken language and robot indexing/proxying. Should likely be written in Python 3, so that it can run just about everywhere and be very lightweight. Could also be hosted on a website, where a Gemini author could cut and paste their text and indicate their meta preferences (see below) and recieve a spec compliant Gemini text to paste back into their editor to then save and upload to a server. ## On first run gemini-fmt will ask the Gemini author to input their preferences for the following: ### Language - Enter the spoken language that your Gemini texts will usually be published in ### Robots - archiving - Should your Gemini texts be allowed to be archived long-term on a third party website? - proxy-gopher - Should your Gemini texts be allowed to be accessible over gopher through Gemini to gopher translator services? - proxy-html - Should your Gemini texts be allowed to be accessible through Gemini to html translator services? - research - Should your Gemini texts be allowed to be scanned by third parties conducting research that will access your texts but not re-publish the contents? - search-engine - Should your Gemini texts be allowed to be scanned for use and/or re-publishing in search engines? ## Other ideas - Simple mode/expert mode - let a more technical user that might like to otherwise configure their own settings just run a spec check that won't automatically change their text but just warn of errors and point them to relavent parts of the spec - Override general settings - a Gemini author might want to give full robots permissions to one text but no others, maybe there needs to be some kind of index for robots that shows the file path for those? - Something like the preformatted tag to indicate a second language within a text already tagged as another language -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/b502 7d1c/attachment.htm>
May 19, 2020 10:07 PM, "???" <jetkoten at gmail.com> wrote: > Hi all, > > I just joined the list but have read some of the recent messages and wondered if having a > gemini-fmt tool like Go and Rust use to conform a source document to a pre-existing spec might > solve some of the issues around Gemini documents meeting the spec and around properly configuring > the meta headers. > > I feel like the people writing servers and clients are doing a huge service to the community, so > having this gemini-fmt tool would help ease the load on them by ensuring that the Gemini documents > that get uploaded to servers for public consumption and are then served to clients are more or less > guaranteed to conform to the spec. This will save the people who write the servers and clients from > having to spend time handling all kinds of edge cases. I'm including a preliminary outline of what > I have in mind here below. Comments are welcome. > > Thanks, > > J Sounds cool, as a tool unrelated to the official spec, just as a utility... Right now, the verification load is put on the servers anyway, but this could also double as an easy way to get started with writing a gemini server, as you can just take the "verify" part, and not need to re-implement all the checks (and since you can cache the files with some simple checksum, it probably wouldn't be too bad performance-wise to run it as an external executable, even) for being portable and embeddable, C is also a good choice, mostly because practically every platform has a C compiler, and a LOT of languages have some sort of "CFFI" or similar thing, "C Foreign Function Interface", which lets you call C functions from that language, you can use a C library in python through that, for example... python3 is probably very much OK for practical usage by humans > - Something like the preformatted tag to indicate a second language within a text already tagged as > another language I...don't think this is part of the spec, but I'd LOVE if there was a way to indicate multiple languages in one document... if you write parts in different languages (maybe are writing articles about conlangs, or want to have some quotes from another language, or something), then it would be really useful to allow signifying the change...
On Tue, 19 May 2020, jan6 at tilde.ninja wrote: > Sounds cool, as a tool unrelated to the official spec, just as a utility... > > Right now, the verification load is put on the servers anyway, but this could also double as an easy way to get started with writing a gemini server, as you can just take the "verify" part, and not need to re-implement all the checks (and since you can cache the files with some simple checksum, it probably wouldn't be too bad performance-wise to run it as an external executable, even) > for being portable and embeddable, C is also a good choice, mostly because practically every platform has a C compiler, and a LOT of languages have some sort of "CFFI" or similar thing, "C Foreign Function Interface", which lets you call C functions from that language, you can use a C library in python through that, for example... > python3 is probably very much OK for practical usage by humans For the time being, it'd be a good step forward just to have a tool in
> I...don't think this is part of the spec, but I'd > LOVE if there was a way to indicate multiple > languages in one document... if you write > parts in different languages (maybe are > writing articles about conlangs, or want to > have some quotes from another language, or > something), then it would be really useful to > allow signifying the change... FWIW, this is also a necessity for writing both Chinese and Japanese in the same document, due to the Han unification of Unicode. Nicole -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/a6a1 1690/attachment.htm>
On Tue, May 19, 2020, 14:46 Martin Keegan <martin at no.ucant.org> wrote: > On Tue, 19 May 2020, jan6 at tilde.ninja wrote: > > C is also a good choice [?] python3 is probably very much OK for practical > usage by humans Sorry Jan, I didn't get your email from the list so I have to double quote it here. Oops, yeah, I meant to say that about python too. Just to make it easier for less technical would be Gemini authors. pip install gemini-fmt and then gemini-fmt mytext.gemini is super easy, in addition to the lightweight and portable parts. Makes a lot of sense to look at an embeddable similar verify tool. > > For the time being, it'd be a good step forward just to have a tool in > *any* language which reliably answered the question whether a file/string > were conformant with the spec. It'd be nice to be able to say > sendfile(readfile()) and know that one's not breaking the strict reading > of the spec. > > For this, it suffices to have a gemini-check tool rather than a gemini-fmt > tool, which presumably would be able to output a new, conformant file. > Yes, gemini-fmt in "simple mode" would output a new file but "expert mode" would be a gemini-check with friendly error output that would say what didn't match the spec Thank you both for the comments. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/fd2c b72b/attachment-0001.htm>
On Tue, May 19, 2020, 15:01 Nicole Mazzuca <nicole at strega-nil.co> wrote: > > I...don't think this is part of the spec, but I'd > > LOVE if there was a way to indicate multiple > > languages in one document... if you write > > parts in different languages (maybe are > > writing articles about conlangs, or want to > > have some quotes from another language, or > > something), then it would be really useful to > > allow signifying the change... > > FWIW, this is also a necessity for writing both Chinese and Japanese in > the same document, due to the Han unification of Unicode. > > Nicole > Yes, and I don't know for sure but I would think, for instance, among lesser known Romance languages it would be difficult to autodetect them and much easier to have the author tag them. Thanks, J > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/c6e6 269d/attachment.htm>
I liked this idea. I use the go toolchain a lot and really appreciate the
options available.
In particular `go fmt`. I think consistent code is readable code. The same is possible
for `text/gemini` documents.
In that spirit I have made a tool (it is still a work in progress):
https://tildegit.org/sloum/gemini
(I'm open to changing the name, but I liked the idea of running:
`gemini fmt ./index.gmi`
Current features:
## fmt
---
Previous Thread: [ANN] Moonlander: The fanciest Gemini client in the entiresolar system