Unfurl issue titles everywhere in Markdown

[azenMatt]

It's really nice that the full title of an issue, pull request, or discussion is unfurled in lists. I would love the title to unfurl anywhere the issue, pull request, or discussion is referenced.

[sdruskat]

I think that unfurling issue titles (especially using bold font plus the issue number) actually makes things less readable.

[joe-woolvett]

agree with this.

[sdruskat]

I can see why this has been implemented in task lists only, but I'd also argue that there is exactly one use case where this makes sense: building mini-Projects, e.g.:

- [ ] #213
- [ ] #17
- [ ] #6132

For everything else using Markdown checklists, this makes things less readable, e.g. in a PR's first comment:

### Related issues (but is this a "task list"?)

- [ ] #241
- [ ] Perhaps #242 as well, but not sure

### List changes you have made

- This will unfurl the title and keep the number, #243, although it isn't even strictly a "task list", just a list
- Another change, without referring to an issue
- And mentioning more than one issue (#245 and perhaps even #246) also make this look horrible

I think this feature would be great to have as opt-in/opt-out from the repo settings 🙂.

[matkoniecz]

Exactly, I would rather stop already added unfurling. It is really irritating - if I would want to mention title then I would mention it.

See #4321 "Automatic display of the issue title is a bad idea" asking to unbreak it.

[ElijahLynn]

I routinely copy paste issue titles and have to create markdown links so, yes, would love this feature to auto-unfurl.

[TimWolla]

I'm currently using this Firefox extension to add a bit of status to linked issue numbers: https://github.com/fregante/github-issue-link-status. While I agree with @sdruskat that having a full title everywhere can be distracting, I think that having a small icon indicating whether that issue number refers to an issue or PR and what's the status (open, closed, merged, draft) of that issue or PR is.

[p-jackson]

I wasn't expecting this and I felt it made my lists harder to read. I often write a list of todos in a list, and then as I create a PR for each todo, I'll edit the list and add a reference to the PR.

I'll write lists like this:

- [ ] fix padding on mobile (reported in #543)
- [ ] re-write auth module
- [ ] fix off-by-one error

Then edit later to add PR references

- [x] fix padding on mobile (reported in #543) #1234
- [ ] re-write auth module #5678
- [ ] fix off-by-one error

And I find the unfurled PR titles make the list harder to read.
The work around I've found is using sub-tasks

- [x] fix padding on mobile
   - reported in #543
   - #1234
- [ ] re-write auth module
   - #5678
- [ ] fix off-by-one error

[azenMatt]

Thanks for the feedback on this one, I'm curious on how you feel after using this for a couple of weeks? Now that you now the PR will unfurl, does that impact how you are writing these lists?

For example,

- [ ] re-write auth module #5678

just becomes

- [ ] #5678

[p-jackson]

Thanks for responding. I haven't noticed this particular case recently so probably have changed my behaviour. Chances are "re-write auth module" is written somewhere in the title for #5678, so it seems redundant to have both if the PR id gets unfurled.

Here's an example where I'm still finding it a little awkward: Automattic/wp-calypso#54578 (comment). Here I'm trying to quickly reference another issue without interrupting the flow of the prose. It's probably just a personal preference though, similar to which citation style one personally prefers in academic work, where you're also trying to correctly reference something without interrupting the prose.

What I do like about the change the improved accessibility. It's good for hyperlinks to describe where they link to, so that when assistive technology lists all the links on a page they have sensible titles. So that's a nice improvement.

[abernix]

For what it's worth (admittedly, perhaps not much as someone who knows nothing about your project!) I don't find it interrupts your prose at all.

I read right through the unfurled interpolation of the title to the remainder of your sentence, while buffering the additional title context on the way. In fact (perhaps also as someone not familiar with your project!), the additional information I buffered in reading it made it much easier for me to understand at a glance. This probably touches on the personal preference bit.

The thing I find personally quite interruptive is that without the unfurled interpolation, I find that I spend a lot of time pausing my reading to hover my mouse over #number links and discern their meaning from the hover box popup.

Anyhow, just my perspective!

[p-jackson]

I find that I spend a lot of time pausing my reading to hover my mouse over #number links

This is a really interesting point! I also do this, so I'll try to take notice of whether I hover more often than not!

For what it's worth [...] I don't find it interrupts your prose at all.

Admittedly I'm becoming more accustomed to reading it. So it could be both a preference and a familiarity thing.

[gnprice]

I've been wondering for weeks why my issue references sometimes get expanded with titles, and sometimes don't. TIL from this thread what the pattern is!

I'm glad to learn that, but maybe this is a sign that the current behavior is rather opaque and surprising.

#4321 is a discussion of this same feature but in the opposite direction. (I feel both ways at different times: sometimes I want the expansion in places where it currently isn't, and other times I find it just makes things less readable.)

[kevinwhoffman]

I personally like the expansion in all list types (numbered, bulleted, task) because I am typically just making lists of issue numbers. However, in reading the other comments, I can see why others find the unfurling to be bothersome when it happens in a list item that contains other content besides just the issue number.

The following conditions may satisfy both use cases.

Unfurl issue numbers that are by themselves

If the issue number is the only content on the line (excluding markdown formatting), then unfurl it.

For example, all of the following use cases should result in unfurled issue titles:

1. #123

- #123

- [ ] #123

#123

Do not unfurl issue numbers alongside other content

If there is any other content on the line besides an issue number, then do not unfurl. Leave the text alone and simply hyperlink the issue number—regardless of whether it's in a list or not.

For example, none of the following use cases should result in unfurled issue titles.

1. We should look at #123 first

- Then proceed to #234 if needed

- [ ] Merge after #345 is complete.

This is a sentence with an issue number in the middle #123 which should not be unfurled.

[kevinwhoffman]

GitHub's automatically generated release notes show why unfurling all issue titles is a problem.

I recently used the auto-generated release notes and used the option to create a discussion from the release. The result below shows how the release notes effectively duplicate themselves because the issue numbers are unfurled in addition to the plain text title. These are two GitHub features in direct conflict with each other, and having to manually edit the release notes takes away the whole convenience of the feature.

[dhalbert]

I often put the issue title in a list to unfurl it in a "Fixes #nnnn" line, so it's clear what issue is being fixed.

I think the decision to unfurl is often only semantically contextual. I was thinking that a simple double-# could force unfurling, leaving the decision up to the writer.

Fixes ##1234.