Adds spacing to gemini docs to normalize the formatting with gopher docs #188
No reviewers
Labels
No Label
blocked
bug
build
documentation
duplicate
enhancement
finger
gemini
gopher
help wanted
http
in progress
invalid
local
needs-info
non-code
non-functional
non-urgent
question
release
rendering
suggestion
telnet
terminal
urgent
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sloum/bombadillo#188
Loading…
Reference in New Issue
No description provided.
Delete Branch "gemini-gutter"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR would bring the display of text/gemini documents in line with how gopher displays things:
This creates a situation where all content is still left aligned, but the link numbers do not throw things off. This will allow preformatted art that is meant to line up in a certain way with link lines (that reside outside the pre block) to line up as expected.
As an added bonus, I added a little snipped that will make heading lines (
#
,##
,###
) appear in bold iftheme
is set tocolor
. Technically it will bold any line that starts with#
... which is a naive way of handling it... but it was done on a whim and I think it should be ok for the moment.I think this improves the visual experience of browsing gemini space at the cost of 5 chars of display... given that tradeoff is already made for gopher I see it as acceptable.
@asdf if you end up with a spare moment I'd love an extra set of eyes on this. The code is a little sloppy and not my best (I dont have a lot of time these days with baby, work, and pandemic... but I thought it would be nice to get this in even if it was a little rushed). Definitely feel free to make changes or point out anything that should be done differently.
Once things with the pandemic wind down I may start thinking seriously about a version 3.0 as this codebase is starting to feel a little unweildy and I can see areas that could be so very much improved and simplified by a full rebuild with better data structures. Anyway, that is a story for another time ;)
Did some quick tests - compatible with Go 1.11.13, no new linting issues. It seems to be implemented well, but I do have some notes I'll add on the code.
Visually it looks pretty cool and is a good result.
Is it correct that this will only work when viewing content served as a Gemini formatted document? I viewed a few different documents on our server and only the .gmi file displayed in this way, while .txt and .md were not. This is the behaviour I would expect, the same as gopher maps and gopher text documents.
Do you think longer term it might be possible to make the link styling for each protocol more similar?
Great job!
@ -126,8 +127,11 @@ func (p *Page) WrapContent(width int, color bool) {
content.WriteRune('\n')
counter = 0
if p.Location.Mime == "1" {
Maybe this
if
andelse if
block could be changed so we don't runstrings.HasSuffix
for each line of a document that isn't a gopher map.The mime type check could be done before the loop in this function, followed by setting the appropriate spacer value for the document type. This block could then become a test of the spacer value itself. A bit like:
I'm not sure if this is easy to understand, so I can make these changes for you to review if it helps.
Setting the spacer to
0
to start with wont work due to typing issues, but aside from that this is a very practical change. I'll do this. 👍I have updated to more or less this exact thing and I just always write the spacer for each new with no link inside the for loop, it is just often set to
""
and thus has no effect. This is much improved in a very confusing area of the codebase. Thanks for the suggestion!I'm not sure exactly what you mean. Since gemini does not have an equivalent to gophertypes and I dont want to prefetch the mime for each link (so as to not break geminis "one page one request" simplicity), so there would not really be much to put in a
(MAP)
kind of identifier like gopher. I used different spacer lengths in order to not take up horizontal space in a gemini document needlessly, but I definitely could make them the same spacing.Let me know if that addressed your question correctly or if you were thinking of it in a different way.
Once we get to 3.0.0 I'd like each protocol module to have its own wrapping function I think... then we can do more individualized complex things.
Sorry for not being clearer before. That does answer the question, as I was thinking about alignment. The other thing was the difference in link styling - we use different brackets, sometimes surrounding the gopher type and sometimes around the link number:
Some alternatives might be:
This is really just a nitpick. I like it the way it is, just wanted to run this by you in case you hadn't considered it.
@asdf What do you think of this:
That way the numbers are noted in the same way and can be visually greped more easily accross protocols, but without taking up additional line space for gopher (since the parens got removed from the type).
I like your idea. I had a play around with implementing it to see how it would look. Two things I found:
Maybe try with parens or no wrapping characters, instead of brackets on the link numbers, to see how you feel about readability.
These link numbers are number data in a column, so should probably be right aligned? Gopher currently does this, padding for 2 digits. It works well with pages like gemini://gus.guru:1965/known-hosts
The problem with padding two digits if the brackets around the number. It looks bad having an empty space inside the brackets. I need to work out an efficient way of adding a space before (or maybe after) the brackets rather than having it inside.
Yeah padding bracketed numbers is a problem, although the method you used for Gemini avoids this problem:
I don't know enough about performance to say - maybe the double sprintf is another problem, and I can't think of anything better. If it's too hard, don't worry about it.
@asdf I copied over that formatting idea to gopher. Give it a pull/build and let me know what you think. I think it looks good and has a much more unified look between the two main protocols now.
Yeah that looks great. Gemini link numbers are left aligned, but it looks like the better choice. Let's push it.