Task list inside table cells

[bkeepers]

Originally requested in github/markup#364

Task lists inside of table cells could be really interesting. I don't know exactly what the syntax would look like…

[x] | First Header  | Second Header
--- | ------------- | -------------
[ ] | Content Cell  | Content Cell
[ ] | Content Cell  | Content Cell

[mtodd]

No immediate plans to work on this. Would be good opportunity for community contribution, though.

[rex]

Hello Githubbers @bkeepers and @mtodd !

I apologize if my posting this comment is considered 'dead post resurrection' but as I currently have a use-case for this I searched and came across github/markup#364 which led me here.

Please don't judge me until the end. Conveying thoughts/feels/ideas in text is... limited.

I consider myself, like so many others amongst us, to be a prolific Gist user. Lately I've been finding more and more things that Gists just... do. And do them well.

Some very quick background: I listen to a lot of music podcasts while I'm working (predominantly electronic) and I frequently hear tracks that have me very "imustownthisomg". But in the spirit of taming my addiction to purchasing music on iTunes (which is serious. really serious.) I have kept a number of text files strewn about Dropbox collecting track information in hopes of having the wherewithal to force myself to wait to buy them.

Remember, you promised not to judge yet. The point is incoming.

These lists have ranged from overtly, almost uselessly simple text files:

Gabriel D'Or & Bordoy - Real Diamond [Bla Bla]
...

To overly-complex YAML files:

Podcasts:
  - Name: Phobiq Podcast 024 with Gabriel D'or & Bordoy
    Link: https://soundcloud.com/d2techno/phobiq-podcast-024-with
    Tracks:
      - Name: Gabriel D'Or & Bordoy - Real Diamond [Bla Bla]
        Link: https://itunes.apple.com/us/album/real-diamond/id829830612?i=829830635

Not only is managing these lists tedious and error-prone, but it's even more tedious to find a standard way to mark tracks as purchased once I actually do fork over my $1.29.

    Tracks:
      - Name: Gabriel D'Or & Bordoy - Real Diamond [Bla Bla]
        Link: https://itunes.apple.com/us/album/real-diamond/id829830612?i=829830635
        Purchased: true

Most importantly, the only thing keeping the list in my life is Dropbox, and if you have as much data in yours as I do in mine then you'll know what I mean when I say "where the hell did I put that file?...".

The Point, Finally

It would be amazing, amazing I tell you, if I could keep track of these in a gist. Now, that being said, I just created one earlier (https://gist.github.com/rex/20435e1783c585ebfa1b) which was awesome. "Finally", I said to myself, "Finally I have arrived at Providence! Badass text formatting and a badass checkbox that I can use to mark things as purchased in one click!". Well, that's when I tried to format it the way I really wanted to and came up empty.

See, it would be so, so amazing if I could turn this:

• Zack Roth - Sleep Talking [Andy Bianchini Remix] Jaytech Music 085

Into this:

$?	Artist	Track	Remixed By	Label	Source
- [ ]	Zack Roth	Sleep Talking	Andy Bianchini	Nueva Records	Jaytech Music 085

The Point: Episode 2 - The Conclusion

Now, I know what you're thinking. "Pierce, that's just about the biggest first world problem I've ever heard. There are people in the world that don't eat or have access to clean water, and you're coming at me with fucking checkboxes?!1"

And you'd be right. It's absurd for me to even actually give it a second thought. It's a 100% aesthetic difference that only saves me a few seconds (likely less) and makes precisely zero tangible, calculable difference in my life.

But you know what? This is 'Murrca! Where would we be without the endless pursuit of shaving a few seconds here and there? Internal combustion engine ring any bells?!

I'm sitting on top of a bomb covered in shrapnel and creating a never-ending rabbit hole of petroleum dependency, war, environmental devastation, and consumerism but HOT DAMN AM I GOIN FAST!!!

-- One Great 'Murrcan

You see those colors? Those colors don't run! Making things go fast is the 'Murrcan Way™. I'm pretty sure that's in the Bible [citation needed].

The Bottom Line

This is 'Murrca. So the following logic applies:

• If we don't 'Murrca, then the terrorists win.
• If we don't make things go fast, then we didn't 'Murrca.
• If we don't make formatting checkboxes in Gists fast, then we didn't make things go fast.

Thus, it follows logically that if we don't make formatting checkboxes in Gists fast then the terrorists win. And I for one am not going to stand by and let the terrorists win!

This means the only way for America to win is for you guys to let me help make formatting checkboxes in Gists exist. Give me a place to start hacking away and I'll go there with my Bald Eagle and emerge from the rubble victorious and unscathed.

Let's do this doggone thing.

Side note: I am sure there are more than a few great use cases for this functionality to exist, very likely better than mine. Heck, it wouldn't be hard to translate that type of functionality into something that would give parts of Basecamp a run for its money. But you know what, if 'Murrca isn't a good enough reason to make this happen then, well, the terrorists have already won.

Edit: After looking through the code, it seems most likely a RegEx thing. But you guys already knew that. If there is a way to be more forgiving in the optional prefix for the task list item regex then it becomes very possible to match the markup generated by the table that would precede each task list item.

If I am reading this right, and there's a nonzero chance that I'm not, it seems like the raw GFM is taken from the .js-task-list-field textarea, split by \n, and parsed individually. This would mean that you can safely assume that, even if indented, there will be nothing on the line before the - [ ] tag. What we would need to do is allow any amount of table markup and field content to come before and after the - [ ] string. There should be a relatively straightforward way to enhance the regex to just not care about the placement of the - [ ] (with a few notable exceptions, ex. fenced code blocks) and capture everything from the index of the - [ ] string until it terminates at the next instance of the | character.

Few possibilities here?

• https://github.com/github/task_list/blob/master/app/assets/javascripts/task_list.coffee#L117
• https://github.com/github/task_list/blob/master/app/assets/javascripts/task_list.coffee#L153
• https://github.com/github/task_list/blob/master/lib/task_list/filter.rb#L43-L45

I gave it a quick whirl (http://rubular.com/r/VQMr2vgkRZ), and the detection of the task-list-item is trivial (removing the start-of-string ^ character), which leads me to believe that there are deeper-seated reasons why this hasn't been implemented that are internal to GitHub. Or that there are any other number of pieces moving in this machine that I am blissfully unaware of that prevent this from happening. 😦

[jasonkeene]

👍 for this feature. I just ran into this and was very disappointed.

[mtodd]

Hi @rex, thanks for sharing your use case. And @jasonkeene for your support.

There's no contest that this would be a useful addition, I would love to have it. However, the problem isn't convincing me that it's a good idea: the problem is that it's a challenging feature to implement and isn't my top priority.

Anybody should feel free to contribute a Pull Request implementing this feature, I'll work with whomever to get it right. That said, I won't be tackling this problem any time soon.

Again, I agree this is a worthy feature addition, 👍s won't convince me further (or help me prioritize it higher). A PR is the only contribution that will help make progress on this.

I'm debating closing (and locking) this issue to set expectations clearly but will leave it open for a bit longer (I haven't decided if it warrants closing/locking yet).

[rex]

@mtodd Thanks for the honest reply. And for what it's worth, I at least somewhat apologize for the ridiculous first comment. There may have been a beer involved and it turns out that beer and GH issues are not great friends.

It makes complete sense to me why this isn't a very high priority. I wish it were different, but it's the way it is. Check boxes work fantastically in their current context/use case. I suppose I was hoping a picture of Ricky Bobby would sway your judgment.

All kidding aside, I would truly enjoy taking on the challenge of implementing this feature and submitting the PR, but I'm honestly not entirely sure how I would test it before submitting the PR. It seems most likely that the testing infrastructure for these task lists lies (correctly) behind the GitHub infrastructure wall. Is there a way that you can point me that would allow me to test the work before submitting? Specifically, to ensure that task list items marked as checked persist properly after page refresh?

I know you GitHubbers are busy people, I obviously don't expect your undivided attention. Any information you can give me regarding how best to test my changes would be appreciated, though!

Thanks again.

[mietek]

👍

[joebayles]

I'd love to see this functionality as well.

Totally understand that you all have priorities just like everyone else, but I thought I'd add my vote.

Thanks for doing everything you do.
👍

[bmeynell]

👍 Tried to use checkboxes in a table today :(

[anderssonjohan]

👍

[daldegam]

👍

[mtodd]

I'm going to lock this issue to prevent further 👍s. Agreed that this would be useful and the next step would be for someone to submit a PR to implement this functionality. Alternatively, a similar but distinct library could provide the behavior for tables (task_table?).

In any case, I won't be starting on this project and would encourage anybody interested in 👍ing this issue to instead dig in and put together a PR which I will be happy to review and pull in if it makes sense to.