💾 Archived View for gemi.dev › gemini-mailing-list › 000117.gmi captured on 2023-12-28 at 15:41:30. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-04)

🚧 View Differences

-=-=-=-=-=-=-

gemini-fmt idea

1. ✈個展 (jetkoten (a) gmail.com)

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>

Link to individual message.

2. jan6 (a) tilde.ninja (jan6 (a) tilde.ninja)

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...

Link to individual message.

3. Martin Keegan (martin (a) no.ucant.org)

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

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.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

Link to individual message.

4. Nicole Mazzuca (nicole (a) strega-nil.co)

> 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>

Link to individual message.

5. ✈個展 (jetkoten (a) gmail.com)

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>

Link to individual message.

6. ✈個展 (jetkoten (a) gmail.com)

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>

Link to individual message.

7. Brian Evans (b__m__e (a) mailfence.com)

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


## get


## spec


## version


## serve (coming soon)




If people would like anything else let me know. I dug through the 
`text/gemini` to make sure
I was getting everything within spec for the formatting. The only place I 
break from the spec
is w/ regard to alt text on the opening line of a preformatted block (I 
allow it and format it). I
have included it, but specifically state in the README.md that it is an 
experimental feature
that may be removed or changed in the future.

Anyway, hopefully it is useful to someone eventually. I have definitely 
liked the consistent
output that it provides. It lets me write with a lot of extra spacing and 
organize my thoughts
how I want, but then cleans it all up nicely. :)

Link to individual message.

---

Previous Thread: [ANN] Moonlander: The fanciest Gemini client in the entiresolar system

Next Thread: Emacs mode for text/gemini?