Add grammar for task lists

[burodepeper]

No description provided.

[kevinsawicki]

Thanks for adding this, would you mind adding some specs for this? You can find them in the spec/ directory at the root of the repository.

[burodepeper]

Sure, but I'm completely unfamiliar with that. Is there an Atom specific quickstart guide on that?

[kevinsawicki]

Yup, here is the raw guide https://github.com/atom/docs/blob/5d3d00a7c895b66d99a227067d3ecf5b0a20951c/book/03-hacking-atom/sections/03-a-basic-package.asc#running-tests

The hosted guide on https://atom.io/docs is currently down, apologies.

[burodepeper]

Thanks! I'll look into it

[burodepeper]

I've added the specs. I've noticed that on line 573, I've added an inline bold thing to try and break it, but it still passes the test. Is that intentional?

[kevinsawicki]

You need the following here if you want to parse markdown on the line itself:

'patterns': [
  {
    'include': '$self'
  }
]

This causes it to use all the existing patterns between the start and end patterns to further tokenize it.

[burodepeper]

Thanks for the tips. I'll take a look at them tomorrow.

[burodepeper]

Thanks again for the tips. I'm more of a trial-and-error kind of guy, than a first-read-the-manual one. I think I understand the 'patterns' addition. I had it on the wrong level/scope at first.

The (.*) is more a personal preference. This way I can visually target the text part of a task without touching the rest. What do you think about extending this behavior to normal (un)ordered lists?

[burodepeper]

Darn it, already found a bug;
- [ ] ### Header actually parses that as a header while it shouldn't.
In - ### Header it doesn't.

I am a bit at a loss here. The current lists only mark the - bit as the list, and leaves the rest as blank text inside the containing source.gfm I think.

I assumed the following is the behavior you'd want:

- Apples
- Bananas

becomes something similar to

<ul>
<li>- Apples</li>
<li>- Bananas</li>
</ul>

while it actually creates (something similar to)

<ul>
<li>- </li>Apples
<li>- </li>Bananas
</ul>

I tried to fix that in my attempt at task lists, but the patterns bit treats the content as a new line, and thus headings become valid again.

Since all four variants are lists, what should be the default behavior?

[burodepeper]

Okay, I've done some digging, and I think I know how to fix my issue with the headers. I need add something like:

'repository':
  'inline-stuff':
    'patterns': [
      // ...
    ]

and then modify the

'patterns': [
  {
    'include': '#inline-stuff'
  }
]

Still interested in what you think about the default behavior for lists

[kevinsawicki]

Since all four variants are lists, what should be the default behavior?

After giving this some thought, I think unordered lists and task lists should behave the same.

And since unordered lists currently just parse the * part, would you be okay having task lists do the same and just parse the * [ ]? Or were you looking to be able to style the full line differently based on whether it was a task list or not?

[burodepeper]

Or were you looking to be able to style the full line differently based on whether it was a task list or not?

Yup. For the placebo-effect of crossing something off of your list. Gives it more of a sense of purpose/progress than just deleting the completed items from a list.

I'll parse it in a simpler way for now (basically my first solution), and leave my specific styling preferences for perhaps another time.

[burodepeper]

Current version produces:

[burodepeper]

I've moved all inline markup to a repository, cleaned things up a bit, and updated the patterns of the task list parsing. Task lists are now tokenized in the same way normal lists are, with the exception for completed tasks (for styling purposes). And all include '$self' are replaced by a include '#inline-markup'.

[burodepeper]

Found this bug, is in the master repo, will fix it tomorrow.

[burodepeper]

Closing this because I need a clean master branch and this has gone stale anyway.