Info bar

[makew0rld]

It'd be nice to be able to see additional info about the current page. This could be achieved by having a separate bar above the bottom bar, that can be toggled with i.

Information that could be displayed

• TLS version: 1.2
• Where the page is from: cache or network
• Media type only
• Media type params
• For gemtext, parse the lang param using golang.org/x/text/language/display and display an English language version of the tag(s): English, Japanese
• Server certificate key type: ECDSA
• Humanized server certificate size
• Current line (from bottom), total lines, and percentage
• Humanized page size
• Client cert info
  • Humanized size
  • Common Name field
  • Humanized time to expiry
  • Key type: ECDSA
• Time taken to download document
• Title (assumed to be first header in gemini document)
• Decoded query string
• Unicode domain, maybe - depends if I decide I want domains to be Unicode in the URL bar. Probably not
• Humanized cache size
• Number of pages in cache
• Total number of subscriptions
• Number of pages subscribed to
• Number of feeds subscribed to
• Proxy host, if this page is proxied

Questions

• Should non-network information be stored as part of structs.Page so it can be displayed again when the page is cached?
• Should the toggle be applied for the whole application or per-tab? Probably the former
• How to handle the total info string being longer than the user's terminal width?

---

See below for discussion on configuration and formatting.

[sudobash1]

Could this be something user configurable? I am thinking of the status bar configurations that vim and tmux have. For example perhaps configuration could look like this:

[statusbar]
left = "TLS %t, Cert Size: %s"
center = "[%m]"
right = "%l/%L %p%%"
display = true # Display by default or not?

And the statusbar could be rendered as:

Security: TLS 1.2, Cert Size: 1KiB                      [text/gemini]                                 50/200 25%

Where (just for example)

item	meaning
%t	tls version
%s	cert size
%m	mediatype
%l	current line
%L	total number of lines
%p	percentage through the document
%%	A literal percent sign

Ideas of other items which could be included:

• Information about client TLS certificate (if any)
• Favicon emoji
• Time taken to download document
• Title (assumed to be first header in gemini document)
• URL
• URL root
• URL path
• Amfora version

And perhaps at a later time:

• Style tags to colorize & format individual items the statusbar (similar to tmux #[fg=red] format tags)
• Conditionals (similar to tmux #{?cond,yes-value,no-value}
  • eg perhaps displaying different information depending on whether there is a client cert or not

[makew0rld]

Your proposal changes it from what I was picturing, mostly a debugging bar, into a full-blown feature. I like it. 😄

Going through your comment:

I find "Info Bar" not a great name, but I don't know if "Status Bar" really fits either. Thoughts?

Being able to align text is a nice thing to have, again it turns it into a UI element rather than just some debugging info. I'm still unsure what to do if the terminal width is less that the space needed to display the info though. I mentioned this in my original comment but it's a bit more confusing when there's text-alignment. I don't want the bar to be more than one line, I don't want the user to have to somehow select and scroll through it, I don't want it to move on its own marquee-style... maybe the user will just have increase their terminal size if they really want all that info.

display = true # Display by default or not?

This^^ is a good idea. I'm thinking off by default, so as not to change the way Amfora looks now. Those who want extra info can have it.

• Information about client TLS certificate (if any)

Good one, added to the top comment. See the possible infos I've added there, got ideas for any others?

• Favicon emoji

This will be displayed at the top if favicons are enabled, I don't see the point.

• Time taken to download document
• Title (assumed to be first header in gemini document)

Both sound good, added.

• URL
• URL root
• URL path

I don't understand these. I was thinking of having this as a second bar, right above the URL bar (aka the "bottom bar"), so the URL and all its parts are easily visible to the user. I've added an option for a decoded query string though, because that is not easily available. I also added one for Unicode domain, because likely I will have Unicode domains show up as punycoded in the URL bar.

• Amfora version

Once #126 is added you'll be able to see this from about:version. I don't think it's needed.

Style tags to colorize & format individual items the statusbar (similar to tmux #[fg=red] format tags)

Good idea. This is easy to do right away if I use cview's format strings. cview is the library Amfora uses to create a TUI, and its format strings are defined here. This allows for nice things like italics and bold out of the box.

Conditionals

I'm not really interested in this, it seems a bit over the top complexity-wise. For the example you give about client certs, I'm thinking any data that doesn't apply will just be an empty string, so everything should look fine.

Thanks for taking the time to think about this! It's gonna be a good feature.

---

Note to self: The config format proposed should be able to be easily parsed by a regex that captures all percentage signs followed by letter(s), excluding double percentage signs.

[sudobash1]

I find "Info Bar" not a great name, but I don't know if "Status Bar" really fits either. Thoughts?

I wrote status bar because that was what I am most used to seeing being a heavy vim and tmux user. I wasn't trying to make a point by not using "info bar". I just have it in my head as "status bar" But info bar does have the advantage of working well with i. I don't have much of an opinion on the matter.

I'm still unsure what to do if the terminal width is less that the space needed to display the info though. I mentioned this in my original comment but it's a bit more confusing when there's text-alignment. I don't want the bar to be more than one line, I don't want the user to have to somehow select and scroll through it, I don't want it to move on its own marquee-style...

Yes, please no marquee. It's the only thing worse than a <blink> tag 😉

maybe the user will just have increase their terminal size if they really want all that info.

That's the behavior I am used to from vim and tmux. I think that if users want to use a very narrow terminal, then they should make sure their format is very compact and barebones (perhaps using emoji as abbreviations). I could see an info line looking like this:

🔒1.2 [1.2 KiB] ⏱️0.8322 [text/gemini] 🕮12% This is a long title which is g…

That's 74 characters, and I don't imagine too many people use smaller terminal widths. The only other thing I could think of to help would be to have versions of the mediatype tag split so that a users with a compact terminal do not need to display the parameters.

With alignment, I would think that if/when the terminal is too small to fit it all , start chopping off information from the right field. Once that is gone, chop from the center. Then the left. If users use too narrow of a terminal, then they could put the most important info on the left, and less important on the right.

...its format strings are defined here. This allows for nice things like italics and bold out of the box.

That's really sweet. That makes implementation very convenient.

Conditionals

I'm not really interested in this, it seems a bit over the top complexity-wise. For the example you give about client certs, I'm thinking any data that doesn't apply will just be an empty string, so everything should look fine.

That's fair. It's a lot of work for little benefit. The thing I was thinking with client certs was: what if I have a format string which displays a client cert like this: [🔏 expires: 2021-3-12]? If I didn't have a client cert, it would display as [🔏 expires: ] which is confusing.

Thanks for taking the time to think about this! It's gonna be a good feature.

You bet. I'm excited for it!

As an aside: Do you think that information about proxies in use would be helpful? I've not tried proxies yet myself.

[makew0rld]

perhaps using emoji as abbreviations

This looks great! Might do it in my own config.

The only other thing I could think of to help would be to have versions of the mediatype tag split so that a users with a compact terminal do not need to display the parameters.

Done, I have one for the media type and one for the params now.

With alignment, I would think that if/when the terminal is too small to fit it all , start chopping off information from the right field. Once that is gone, chop from the center. Then the left. If users use too narrow of a terminal, then they could put the most important info on the left, and less important on the right.

Sounds good to me.

Conditionals

I'm not really interested in this, it seems a bit over the top complexity-wise. For the example you give about client certs, I'm thinking any data that doesn't apply will just be an empty string, so everything should look fine.

That's fair. It's a lot of work for little benefit. The thing I was thinking with client certs was: what if I have a format string which displays a client cert like this: [🔏 expires: 2021-3-12]? If I didn't have a client cert, it would display as [🔏 expires: ] which is confusing.

No you're totally right. Adding a text or emoji prefix before the data will be very common, and there needs to be a way to remove that part entirely. I need to figure out a very simple format to define display text under a certain condition, and have no text otherwise. I don't think displaying another bit of text if a variable doesn't exist is needed, let me know if I'm wrong though.

Would appreciate hearing about any formats that already have Go parsers, or a simple one you could make up. The Go template library could do this but I find ugly and too verbose for this use case.

Do you think that information about proxies in use would be helpful? I've not tried proxies yet myself

Yep, on a proxied page it good be helpful to know what host the content is being proxied from, like localhost or example.com:1234. I added it. I've also added infos for cache and subscription (#61) information.

[sudobash1]

Would appreciate hearing about any formats that already have Go parsers, or a simple one you could make up.

I don't know of any existing go parsers that would be useful here.

The simplest format I can think of is what Vim uses. It has "group" format marks %( and %). They can do several things in vim, but the most important is if they don't contain any non-empty formatting fields, they get removed entirely. So for the client cert example it could be written as:

%([🔏 expires: %E]%)

If the client cert expiration time (%E in this example) does not exist / is empty, that would evaluate to an empty string.

The Go template library could do this but I find ugly and too verbose for this use case.

I have never tried this, but I think you can make it a bit better by using Delims("<", ">"). Then the template could be written out like this:

<if .clientCertExp>[🔏 expires: <.clientCertExp>]<end>

[makew0rld]

Thanks for the suggestions! Both of these look good, and I didn't know about Delims. I will probably ending up going with the former suggestion, using %( and %), as long as I can figure out the regexes. That format seems a lot easier to read and write to me.