Correct the [fonts.gemini] heading to [fonts.gemini.text] in the example
configuration shown in the README.md
---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index f04ae48..0839693 100644
--- a/README.md
+++ b/README.md
@@ -92,7 +92,7 @@ list = "🌼 "
 [fonts.finger]
     family = "monospace"
     size = 11
[message trimmed]

On most programs, I can use my mouse's side buttons to navigate back or
forward, while on Castor, the back button on top is the only way I can
navigate back to the previous page.

If you don't have a mouse with said side buttons, here are the button
events from both wev (Wayland) and xev (X.Org)

ps. I remember some mice I used swapped the buttons, though not
entirely sure on that.

pps. According to this[1] bug, GTK uses the xorg button ids (8, 9)
[1]: https://gitlab.gnome.org/GNOME/gtk/issues/515

ppps. Feel free to send a patch if you want testing

Yup! Everything works fine :)

---
 admicos-newmailhost | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 admicos-newmailhost

diff --git a/admicos-newmailhost b/admicos-newmailhost
new file mode 100644
index 0000000..66cb3d4
--- /dev/null
+++ b/admicos-newmailhost
@@ -0,0 +1 @@
+I have successfully used git send-email!
[message trimmed]

Just testing if my new mail host is configured for Git patches

---
 admicos-newmailhost | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 admicos-newmailhost

diff --git a/admicos-newmailhost b/admicos-newmailhost
new file mode 100644
index 0000000..b4380e4
--- /dev/null
+++ b/admicos-newmailhost
@@ -0,0 +1 @@
+I'm about to try git send-email!
[message trimmed]

On 7/29/19 7:10 PM, Drew DeVault wrote:
> The reason I didn't answer this is because it doesn't fit in the space
> allocated for these links - and I didn't really have a good solution.
> With your patch the caret-right gets pushed off the edge and ends up
> alone on the next line.
> 
That makes sense.

I'm not sure on how sensible this would be, but I could move it to the
"clone" column, under a new "tarball" header, like what GitHub does with
its "Clone or Download" button. But that definitely feels a little off.

Aside from that, I don't have any idea either.

Normally, only tags have tarball download links. This patch adds a
download link for the tarball of the default branch (eg master) to the
the repository summary page.

The link will be added next to the browse and log links.
---
I asked about implementing this in [1], but got no response. I still decided
to create this patch anyway, as it's a *very* simple change.

[1]: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3Cf7af3c4e-ee62-95dd-a8fd-83fbd6a88ca7%40ecmelberk.com%3E

 gitsrht/templates/summary.html | 3 +++
 1 file changed, 3 insertions(+)
[message trimmed]

If I'm not missing anything, currently, you can only download tarballs 
via the web interface if the repo actually contains a tag.

I feel like this is a deliberate decision, but I'm not entirely sure 
why, and digging through the mailing lists didn't show any discussion 
about that.

The `/<owner>/<repo>/archive/<path:ref>.tar.gz` endpoint works on 
regular branches, and the summary page already seems to have a archive 
link for the latest tag anyway, so adding this feature would be as easy 
as adding another link for the branch archive itself.

I wouldn't mind sending a patch for this, just posting to see if there 
is a proper reason on why there isn't any link for the branch archive

Lately, I've been trying out alternatives to stuff I use, and found 
Sourcehut from it's excellent git send-email tutorial. Looking around 
the mailing lists, this definitely felt like something I'd use.

So I decided to try it out. Created an account (and found an issue in my 
MX records, but that's not relevant) and waited until I got an idea, 
which I did just a couple hours ago.

Here is the repo for anyone curious:
https://git.sr.ht/~admicos/huedance

Advertising aside, awesome work with Sourcehut, keep it up!

I'd love to help, but I'm kind of scared to try to do anything with