GFM Spice for issue comments

[nickl-]

Synopsis:

The expected behaviour is missing, instinctively you would attempt to link to a specific comment by appending the comment number to the issue number.

The work around, presented in the what is expected section is lacking since it fails to create the cross reference in the referring issue.

The gfm source to consider:

 * #Num-Comment:  #154-8795968
 * ~Author#Num-Comment: ~nickl-#154-8795968
 * User/Project#Num-Comment:  github/markup#154-8795968
 * User/Project~Author#Num-Comment:  github/markup~nickl-#154-8795968

What we currently get:

• #Num-Comment: Crossreferencing issues from other projects #154-8795968
• ~Author#Num-Comment: ~nickl-Crossreferencing issues from other projects #154-8795968
• User/Project#Num-Comment: Crossreferencing issues from other projects #154-8795968
• User/ProjectAuthor#Num-Comment: github/markupnickl-Crossreferencing issues from other projects #154-8795968

What is expected to happen:

• #Num-Comment: #154-8795968
• ~Author/#Num-Comment: ~nickl-#154-8795968
• User/Project#Num-Comment: github/markup#154-8795968
• User/Project~Author#Num-Comment: github/markup~nickl-#154-8795968

Nothing special needs to happen with the cross references in those issues and they can be treated as normal references would with only the ability to hyper link to a specific comment instead.

The use of ~ is purely for the sake of spice and explanation and you should in no way feel compelled to adopt it nor should you feel a need to excuse it, if you can't. Everything is already awesome! =)

Current Spice as per the gfm documentation

* SHA: be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
* User@SHA ref: mojombo@be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
* User/Project@SHA: mojombo/god@be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
* #Num: #154
* User/#Num: github#154
* User/Project#Num: github/markup#154

• SHA: be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
• User@SHA ref: mojombo@be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
• User/Project@SHA: mojombo/god@be6a8cc
• #Num: Crossreferencing issues from other projects #154
• User/#Num: Crossreferencing issues from other projects #154
• User/Project#Num: Crossreferencing issues from other projects #154

keep up the good work

[nickl-]

Synopsis

Another related bug is also found in the auto conversion of full github URLs into spice described link descriptions, if the url references an issue comment the result is an ambiguous hash -number for the issue.

The gfm source to consider:

 * #Num: https://github.com/github/markup/issues/154
 * #Num-Comment: https://github.com/github/markup/issues/154#issuecomment-8795968

What we currently get:

• #Num: Crossreferencing issues from other projects #154 [historically #154]
• #Num-Comment: Crossreferencing issues from other projects #154 (comment) [historically #154 (comment)]

These two links display no distinction yet point to two different locations.

What is expected to happen:

• #Num: Crossreferencing issues from other projects #154
• #Num-Comment: #154-8795968

[nickl-]

Bump =)

Is anyone even considering this? Kudos for adding the user \ project # issue markdown it rocks!

[jdavid]

+1

[nickl-]

@jdavid Tx for the response I was starting to think I ticked the invisible setting by mistake =)

[nickl-]

bump

[nickl-]

bump

[nickl-]

#154 (comment)

Is an improvement indeed

Is the comment number not handy though?

[nickl-]

#154-11622364

to link to issue comment instead

[bkeepers]

Thanks for the suggestion. I think we're going to stick with our current handling of this for now. The comment number is really to big to be useful. If anything, I could see using the index of the comment in that thread (#154 (Comment 1), #154 (Comment 2), etc), but I don't think that's a priority right now.

[nickl-]

@bkeepers a response wow one year later... you shouldn't have =)

When i saw the new #158 (Comment) link I thought to myself what is the point in that? The shortcuts are meant to work both ways, turning a url into the shortcut but more frequently useful is to simply be able to type the shortcut and have it turned into a link.

Too long? really?

#154-11622364
#154 (Comment 2)

even compared to commit hashes

11622364
 c5b7c11

and we never had a problem with those, did we? You do. =/

I agree with your index idea but then I would still vote for #154-1 or #153-2 imagining I had a vote when my opinion won't be considered, Do we really need to have it spelled out, when a simple - would convey the message. What's next? #12 turns into Issue 12 to keep up with the slow kids. You know what? Whatever!

@bkeepers thanks for the response much obliged.

[bkeepers]

@nickl- You make a very valid point. I'll reopen the issue and look into it.

a response wow one year later... you shouldn't have =)

I just became aware of the abandoned issues on this repo and am doing my best to make it right.

…imagining I had a vote when my opinion won't be considered…
… to keep up with the slow kids. You know what? Whatever!

Keep in mind that the avatars on these issues are people that are just trying to make the world a little better. A lot of people get burned out and quit working on open source because of stuff like this. A little respect would be appreciated, and a little tact would probably be more effective in communicating your point.

[nickl-]

Those were infact the most inoffensive, indirect and meticulous choice of words I could muster at the time in favour of the more colorful variety readily at my disposal by which to express my discontent. I will not retort as would be expected when attacking ones opponent by questioning their virtues but instead may I remind you that we are on the same team and trying to accomplish the same goals.

The "valid points" my teammate refers to in his previous post which compelled him to re-open the issue is not in fact my cunning expressions of discontent nor the ever so subtle reference to what appears to be a perceived deficiency in the average IQ possessed by the general github populous for which the current implementation of comment links aims to cater.

The "valid" arguments which may not be clear from the previous, and correct me if I am wrong @bkeepers, are as follows.

• shorthand links are both a semantic shortening of long urls as well as a shorthand for producing links
• issue comment ids ie. 12345678 are long but not in relation to commit hashes we currently use and love
• we may use an index number instead but this will require a substantial refactoring
• the current solution #1 (Comment) has no significance in the semantics or the production of links
• # is already the semantic equivalent of "Issue" we suggest - as a brief equivalent for "Comment"
• for reproducible and uniquely distinguishable semantic links for comment issue we suggest the format
• * #1-12345678 utilising the current comment unique id which requires very little change, or
• * #1-0 by implementing a sequential index of related comments per issue (this should be adequately attainable)
• There are no advantages to using the elaborate form of the current implementation even with disambiguity resolved by producing for example #1 (Comment 0) unless your argument is for legibility (read: questioning the intellect of githubbers) and the same arguments then holds for replacing the # to spell out Issue 1 (Comment 0) and @ to be replaced by User nickl- for example.

Not previously mentioned but another advantage to adopting the single character hyphen as apposed to (Comment)

• it simplifies implementation of the intellisense drop-down-menu lookup which is currently triggered by typing a hash to select the issue number and can easily be extended for child nodes which can be triggered by following up with a hyphen to produce a summary list of the comments in context to choose from.

Usually in absence of comments we'd assume it has the support of community but when issues are completely ignored, something smells. I would've already attempted to produce a PR but the utter lack of participation bears to question: Why bother?

I believe I stayed true to my last post, right the way down to throwing hands in the air. But it has very little to do about your opinion and everything to do with the work. We can all learn to keep our eyes on the ball, play the game and not the man.

@bkeepers glad to see someone taking the reigns, good luck!

[bkeepers]

This is not actually a feature that can be implemented by a change to this library. I agree with the argument being made here, but implementing this has not been a priority. Feel free to contact support@github.com to voice your support for this feature.