-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
To do lists #107
Comments
Just testing so I can see the HTML.
|
Oh, weird. I can't click on your tasks at all. they're read only. Probably because, I'm assuming, when you check one it sends an edit XHR request and adds an "X" inside the bracket.
|
Yeah, you're right, that's very github specific. It generates checkboxes without a form. List items with certain data attr's and classes, catering to githubs specific stylesheet. Not to mention the js which adds the dynamic behavior. I see this as being really hard to standardize. ...maybe if they were renamed to just "GFM checkboxes" instead of "todo lists", since the "todo" list part entails the dynamic behavior. edit: Anyway, I'll leave this open if anyone else wants to comment. |
I like the idea to simply render checkboxes using this markup. In app you can add event handler to manage specific behaviour. |
IMO - something like this would be good as an extension. |
another option maybe would be to render them as unicode entities since there's no implied interaction... http://www.fileformat.info/info/unicode/char/2610/index.htm |
But it would require a new markdown format for checkboxes, which is non standard even in gfm mode. |
I think this actually is useful, even in contexts where an HTML checkbox doesn't make sense. +1 for generating unicode characters as in here and here. In non-HTML environments, editors could choose to draw them as a bulleted list with strikethroughs for completed items. I've been hoping for someone to cross Taskpaper's text-based todo lists with Markdown for a little while, and this seems a little more user-friendly. Taskpaper requires you to add an @done tag to the end of each line, which makes scanning plaintext to see what is done w/o syntax highlighting somewhat difficult. The GFM syntax is arguably more readable. Yes, Github uses this feature to power some crazy custom features for Github Issues, but it's also generally useful. |
Note: in GFM, |
GitHub has announced (in June 25) that task lists are supported in gists as well as in repositories. This announcement widens (and generalizes) the area of their application, making more reasonable to support these lists in GFM-flavoured mode of marked. |
I'm curious, though. If you do this, and there's no commensurate back-end to handle them, what good are they besides eye-candy? In Github, there is a running JavaScript observer waiting for you to click one of these, and backing that choice to a persistence layer somehow. Marked doesn't provide that, so who will? Walter On Jul 3, 2013, at 1:33 AM, Mithgol wrote:
|
An eye-candy would already be as good as on GitHub where you cannot click other people's task lists (unless you are an owner of the repo). |
@walterdavis Marked doesn't provide any backend service at all. All it does is parse out HTML. Without a backend you can't save anything anyway. Even if it's just an H1, it doesn't persist in any way. |
Right. That was my understanding as well, and I was asking to make the point that adding the GFM checkboxes only does half the job. Walter On Jul 3, 2013, at 12:37 PM, Oscar Godson wrote:
|
Added a rough implementation for task lists that's been sitting in my todo list file for several months. Let's see how it works on master for now. |
+1 |
@chjj What was the reason for the revert? |
+1 for unicode characters rather than checkboxes (for renderer default behaviour). Anyone can customize it to add checkboxes with the current api renderer.whateverNameHasTheFeature = function customizeIt( ){ /* ... */ }; @chjj Maybe the implementation makes more sense thinking on a inline level method rather than a block level method? I've noticed the check marks can be ommited on any list items:
This leads me to think marked doesn't need a new inline level method at all, featuring an enhancement to the current block-level
That is
Does this make sense? |
So it's quite easy to build your own. Here's one I'm using in vue-github: var renderer = new marked.Renderer();
renderer.listitem = function(text) {
if (/^\s*\[[x ]\]\s*/.test(text)) {
text = text
.replace(/^\s*\[ \]\s*/, '<i class="empty checkbox icon"></i> ')
.replace(/^\s*\[x\]\s*/, '<i class="checked checkbox icon"></i> ');
return '<li style="list-style: none">' + text + '</li>';
} else {
return '<li>' + text + '</li>';
}
}; Changing it to output the Unicode characters should be trivial. |
👍 For another perspective, I'm coming at this as a user of marked's lexer. My use case is extracting complete and incomplete tasks from I'm hoping task list support isn't implemented exclusively in the renderer. Something akin to this from the lexer:
This would be a non-breaking change. Custom renderers can opt-in by testing for a defined value of the Exampledoc = """
* [x] my completed task
* [ ] my incomplete task
"""
coffee> new Lexer({ gfm: false }).lex(doc)
[ { type: 'list_start', ordered: false },
{ type: 'list_item_start' },
{ type: 'text',
text: '[x] my completed task' },
{ type: 'list_item_end' },
{ type: 'list_item_start' },
{ type: 'text',
text: '[ ] my incomplete task' },
{ type: 'list_item_end' },
{ type: 'list_end' },
links: {} ]
coffee> new Lexer({ gfm: true }).lex(doc)
[ { type: 'list_start', ordered: false },
{ type: 'list_item_start', completed: true },
{ type: 'text',
text: '[x] my completed task',
task: 'my completed task' },
{ type: 'list_item_end' },
{ type: 'list_item_start', completed: false },
{ type: 'text',
text: '[ ] my incomplete task',
task: 'my incomplete task' },
{ type: 'list_item_end' },
{ type: 'list_end' },
links: {} ] This is a pretty big request on my part. If you're favorable to the idea of changing the lexer I'd be happy to work on a PR for just that part, leaving rendering alone for now. |
github task list support is not implemented yet, right? It's kind of hard to follow the situation about them. This issue calling them Rename it to |
It's a GFM task list if you want to be pedantic. Simply "GitHub task list" implies some integration into github's systems(which is undesirable for something as simple as a mark/unmarked checkbox list). |
If you really want to be pedantic, it is integrated into GitHub's systems: it has special rendering in all places Markdown is accepted; in a few places the task list is interactive. |
Add support for Github Task Lists under the gfm flag. Changes to API * list(*string* body, *boolean* ordered, *boolean* taskList) * listitem(*string* text, [*boolean* checked]). `checked` is defined when you have a list item which starts with `[ ] ` or `[x] `.If defined its a boolean depending on whether the `x` is present. When checked is defined we add a input type type `checkbox` to the list item and add the class `task-list-item-checkbox`. `taskList` is true if a list has any list items where `checked` is defined. When true we add the class `task-list` to the list. Resolves markedjs#107
I've just opened #587 which should resolve this issue |
Add support for Github Task Lists under the gfm flag. Changes to API * list(*string* body, *boolean* ordered, *boolean* taskList) * listitem(*string* text, [*boolean* checked]). `checked` is defined when you have a list item which starts with `[ ] ` or `[x] `.If defined its a boolean depending on whether the `x` is present. When checked is defined we add a input type type `checkbox` to the list item and add the class `task-list-item-checkbox`. `taskList` is true if a list has any list items where `checked` is defined. When true we add the class `task-list` to the list. Resolves markedjs#107
This reverts commit a5e39a6.
Add support for Github Task Lists under the gfm flag. Changes to API * list(*string* body, *boolean* ordered, *boolean* taskList) * listitem(*string* text, [*boolean* checked]). `checked` is defined when you have a list item which starts with `[ ] ` or `[x] `.If defined its a boolean depending on whether the `x` is present. When checked is defined we add a input type type `checkbox` to the list item and add the class `task-list-item-checkbox`. `taskList` is true if a list has any list items where `checked` is defined. When true we add the class `task-list` to the list. Resolves markedjs#107
👍 for unicode substitution. I use a great many things that take advantage of marked, including Visual Studio Code's markdown preview. Would love the ability to render a ☐ and a ☑ and maybe even a ☒. I often use markdown that includes lists of tasks, even for things that don't end up on Github. Due to using Github I expected this to just work out of the box. |
This works for me... renderer.listitem = function (text, level) {
let isCheckedTaskItem = checkedTaskItemPtn.test(text);
let isUncheckedTaskItem = uncheckedTaskItemPtn.test(text);
if (isCheckedTaskItem) text = text.replace(checkedTaskItemPtn, '<i class="fa fa-check-square" aria-hidden="true"></i>')+'\n';
if (isUncheckedTaskItem) text = text.replace(uncheckedTaskItemPtn, '<i class="fa fa-square-o" aria-hidden="true"></i>')+'\n';
let cls = (isCheckedTaskItem || isUncheckedTaskItem) ? ' class="todo-list-item"' : '';
return '<li'+ cls + '>' + text + '</li>\n';
}; I use icons from |
Closing as it appears a fix was merged, but may not be working. |
https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments
To be honest, I'm not entirely sure if Markdown should support this or not. Seems very, very Github centric, but curious what your thoughts are.
The text was updated successfully, but these errors were encountered: