Markdown formatting rendering

[ijm8710]

Bullets (and sub-bullets), indentation and spacing are not being picked up as well

[rnystrom]

Can you link to the comment or post an example?

[ijm8710]

Sure @rnystrom photos reference comments in this post https://github.com/RoyaleAPI/cr-api-ux/issues/315

[BasThomas]

Specifically this post.

[rnystrom]

The markdown isn’t correct. Check it out on GotHub, looks the same.

https://github.com/RoyaleAPI/cr-api-ux/issues/315#issuecomment-428951319

List items require spaces between dashes and words.

_{Sent with GitHawk}

[ijm8710]

@rnystrom

Not following are you saying the app so doing it right or acknowledging it’s incorrect

My original part of this post did compare githawk rendering to github mobile site.

Some differences:

• spacing between bulleted lists
• bulleted items should be indented slightly in by default
• indentation of “-“ items below bulleted top line list items

[ijm8710]

@Rnystrom do u agree that there are render inconstancies? Should this ticket be reopened?

[rnystrom]

The markdown rendered in the app looks the same as on GitHub.com

_{Sent with GitHawk}

[ijm8710]

@rnystrom that is not true. Look at the two images I upload in the op them and x-ref them vs my bulleted list 3 comments up

[ijm8710]

@Huddie mind taking a look at this maybe can confirm if I’m crazy or accurate before I continue pushing harder with ryan

[Huddie]

@ijm8710

1. Personally, even if this was an issue, I'd classify at as low-pri if I had that ability just because I think the markdown is rendering fine atm. I say this just because I'm suggesting it's not worth pushing Ryan in either case.
2. I don't think the markdown needs to be 1-1 with GitHub. Certain features I agree should be 1-1 but the spacing between bullets is not something I feel needs to be 1-1 with Github
3. I do see what you mean about the "-" not being indented after an, "*", unordered list bullet. But, sub-lists, from my limited knowledge, are supposed to be written as I wrote below. Not really sure what the "-" is. See how the sub-list below renders properly.

• Win % seems inconsistent:
  • On analytics page, a war miss counts as a loss.
  • On the new addition, a war miss is just factored out. (I lean towards the latter, since you already have misses in red. Ultimately your call but should be consistent, no?)

[ijm8710]

Agree and im not asking for priority I’m stating the ticket should be reopened as it’s still something that should be attended to at some point whenever that is. Yes some of these are minor but if you combine all 3 listed issues and compare he images I feel one loooks signicabtly more clean

[rnystrom]

@ijm8710 can you point out what is wrong in the images? I see paragraph spacing differences but that’s it.

If you’re passionate about a design or feature, we encourage you to make it and send a PR. This is an open source and free app made in everyone’s spare time, anyone has the power to make a change.

I don’t see a point to re-opening this since paragraph layout is all working as intended atm. If someone wants to champion list indentation, go for it.

_{Sent with GitHawk}

[ijm8710]

• there is a line space between each bullet
• bulleted items should be indented slightly in by default but more importantly, align by text block and not the bullet (most important of these 3 items)
• based off this second item, the indentation of “-“ items should align with the text block for the bullet it’s contained in and not the bullet mark (this may fix itself if/when the item above is corrected)

My coding knowledge is very limited, it’s something I’m starting to learn now so For now there’s the answer to your first paragraph

I don’t see how this is any less trivial than #2293 or #2264

[ijm8710]

@rnystrom sorry for the tag, last one. Did my last comment shed any additional light. I think my second bullet in last comment at the very least is legitimate

[rnystrom]

Ya makes sense, but i don’t think chasing these nit picky spacing issues adds a ton of value over how it works today tbh. I’d rather us all spend time on impactful features/fixes.

But that’s why the project is open source. Everyone has the power to make changes they feel strongly about!

_{Sent with GitHawk}

[ijm8710]

@rnystrom more markdown formatting weirdness. I know you considered the earlier reports insignificant, but not sure where you draw the line as this new item is def incorrect rendering.

https://github.com/RoyaleAPI/cr-api-ux/issues/357#issuecomment-5

^in githawk it renders the numbers as 1 and 1, while on github it renders as 1 and 2 (intended)

I actually just stumbled upon #2129 which coincidentally references my two biggest issues here (see post for the first and his f/u comment for the second). Surprisingly, you actually had kept this ticket open :)

[rnystrom]

in githawk it renders the numbers as 1 and 1, while on github it renders as 1 and 2 (intended)

Can you elaborate? The only thing I see missing is the (comment). Is that what you mean?

[ijm8710]

In githawk, second bullet incorrectly renders markdown as a 1 In github, second bullet correctly renders markdown as a 2

#2129, basically nailed my same pinpoints here:

• Markdown lists don’t always number down correctly
• Indentation for subbullets is off when they are more than one line in length and also for this comment top-level bullets should have an even-less slight indent as well
• I also added a third item that github (but not githawk) adds a slight space between 1st level- bullet items

I know you didn’t consider these priority, but they make a major difference in markdown looking cleaner and was recognizing that I was not the only one to ticket this (found later)

Lastly, never noticed the (comment) at the end of a comment link. I won’t push you hard, but it is indeed a nice touch

[ijm8710]

@rnystrom I know I’m beating a dead horse, goal is just to have this at least be an open ticket.

Here’s another example of a post that looks WAYY worse formatted in the app than on native GitHub https://github.com/RoyaleAPI/cr-api-ux/issues/376 I’ve seen a ton of small changes to spacing, emoji ordering, bar resizing and such that you continually make so I feel it’s moreso I’m doing a poor job relaying what is not rendering great as opposed to focusing on a nothing issue. My previous comment summarized the top items for it.

[rnystrom]

My time is extremely limited and I want to work on things I enjoy. Being constantly pinged to work on something isn’t fun at all and in fact is draining my motivation to work on GitHawk.

This isn’t my job, I’m not being paid to work on this, and I’d rather tinker and polish the stuff that I am impacted by in my daily use of the app.

I strongly encourage you to learn iOS and contribute to the things you clearly care about.

Please consider this a warning that continued pinging without contribution may result in removal from the project.

_{Sent with GitHawk}

[ijm8710]

Sorry I was not asking you to work on it at all. I was just asking that the issue be reopened. It is a legit issue. I appreciate the work everyone tries to do and think I’ve contributed as well. I totallly understand where you are coming from and a lot of it seems for your motivation for making this open source and a team collab. I just did not understand why this is considered closed; I am not arguing it’s priority. Will not ping you again on this issue

[tripleee]

https://github.com/tripleee/sloshy renders incorrectly; the README.md contains newlines for internal formatting which should not be displayed when rendering the file.

Compare the screenshot against the fluid rendering you get when you visit the page with a regular web browser. The second line in the body text in the screen shot is an example; it should not be split with a newline between "chat bot" and "which".