Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A plain-text file format for todos and check lists

github.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: A plain-text file format for todos and check lists

#51

Post by 0xbadcafebee »

jotaen wrote: post #50
0xbadcafebee wrote: post #39

I like it. Few issues: - doesn't describe handling spaces or other characters before the checkbox - doesn't support UTF-8 checkbox emoji - doesn't support nested lists - specifies a specific space character when a character class would be better - not clear what "item must not contain blank lines" means - description indentation limit of four space characters is a problem for nested items - description supporting bla…

Thanks for sharing your notes. Nesting of items is not supported, although the idea has come up. It’s on hold right now – that’s mostly due to practical reasons, because it’s relatively hard to implement in tooling. Allow me to clarify a few details regarding the spec: - There can’t be any character before the checkbox. (An item “MUST start at the beginning of a line with a checkbox.”) - A blank line is defined as “a…

It would be simpler to just use the ISO date format. Otherwise people have to implement their own date parser for your stricter format, which adds code (and therefore bugs) and increases probability that people will incorrectly implement the spec.

Why wouldn't you allow space before the checkbox? If somebody accidentally has a space because it's not obvious in their editor (esp. if items can be separated by two newlines) what happens? Undefined behavior? Your format looks a lot like Markdown so I wouldn't have assumed this was a spec requirement unless I looked closely (most people don't look at specs closely)

Re: A plain-text file format for todos and check lists

#52

Post by tommyage »

0xbadcafebee wrote: post #39

I like it. Few issues: - doesn't describe handling spaces or other characters before the checkbox - doesn't support UTF-8 checkbox emoji - doesn't support nested lists - specifies a specific space character when a character class would be better - not clear what "item must not contain blank lines" means - description indentation limit of four space characters is a problem for nested items - description supporting bla…

> - doesn't support UTF-8 checkbox emoji

That's a good thing. Its also unicode, not utf-8. Your plugin can display it with a unicode character. Having a simple ASCII char set helps portability _a lot_. No benefit in supporting unicode code points.

> - doesn't support nested lists

If you can tick all items within a nested list, why bother writing it with dedicated TODO items? Additionally, you can just create more files for elaboration. Your file system is at your dispense. Additionally, that can be implemented in your plugin of choice. Goes with your first point in hand.

> - specifies a specific space character when a character class would be better

ASCII has no official character class. If your are refering to tabs; I don't think this is bad or good. Maybe you can follow uo on the use case..

> - not clear what "item must not contain blank lines" means

Probably that a blank line is used as a separator

> - description indentation limit of four space characters is a problem for nested items

I don't see why. The fixed amout of four characters obviously lines up to the start of the text from an item. This helps readability a lot. And is a simple standard for identation rules.

> - description supporting blank lines (properly indented) would be useful for longer descriptions

I disagree. A TODO list should be simple to grasp. Details and elaborations can be put in a dedicated directoy and refered to. Also, it is a _very bad_ idea to work with invisible lines. Users are dump and quick to judge.

> - date should support an ISO or other standard date format

This is the most portable standard, but extended for human editing..

> - timezone is necessary for events happening in specific timezones or across timezones

I tend to agree. But the person hosting the list should probably be the one defining the time zone. But I haven't read anythinf about time zones in the primer. Nothing stops one to simply append it to a time. No need for the standard to define such.

I think it is well put and the first one which checks all the boxes for me. Congratz to the author.

I don't see why such a comment is #1.

Re: A plain-text file format for todos and check lists

#53

Post by kstrauser »

jotaen wrote: post #48
kstrauser wrote: post #46

Earlier quoted context omitted.

That's fair. I could've sworn that TaskPaper was an actual spec, but when looking just now I couldn't find it.

The maintainer wrote something about this here: https://support.hogbaysoftware.com/t/where-is-taskpapers-fil...

I saw that, and neither of those repos have been updated in the last 6 years. (Maybe they're still up to date? I have no idea.)

Re: A plain-text file format for todos and check lists

#56

Post by rubenv »

tommyage wrote: post #52
0xbadcafebee wrote: post #39

I like it. Few issues: - doesn't describe handling spaces or other characters before the checkbox - doesn't support UTF-8 checkbox emoji - doesn't support nested lists - specifies a specific space character when a character class would be better - not clear what "item must not contain blank lines" means - description indentation limit of four space characters is a problem for nested items - description supporting bla…

> - doesn't support UTF-8 checkbox emoji That's a good thing. Its also unicode, not utf-8. Your plugin can display it with a unicode character. Having a simple ASCII char set helps portability _a lot_. No benefit in supporting unicode code points. > - doesn't support nested lists If you can tick all items within a nested list, why bother writing it with dedicated TODO items? Additionally, you can just create more fil…

Sticking to ASCII in this day and age is nice and fun if English is your mother tongue, but it's a big middle finger to the rest of the world. Please don't.

Re: A plain-text file format for todos and check lists

#57

Post by jotaen »

0xbadcafebee wrote: post #51
jotaen wrote: post #50

Earlier quoted context omitted.

Thanks for sharing your notes. Nesting of items is not supported, although the idea has come up. It’s on hold right now – that’s mostly due to practical reasons, because it’s relatively hard to implement in tooling. Allow me to clarify a few details regarding the spec: - There can’t be any character before the checkbox. (An item “MUST start at the beginning of a line with a checkbox.”) - A blank line is defined as “a…

It would be simpler to just use the ISO date format. Otherwise people have to implement their own date parser for your stricter format, which adds code (and therefore bugs) and increases probability that people will incorrectly implement the spec. Why wouldn't you allow space before the checkbox? If somebody accidentally has a space because it's not obvious in their editor (esp. if items can be separated by two newli…

> It would be simpler to just use the ISO date format.

[x]it! is supposed to be edited (editable) by hand, and from an end-user perspective, I personally find ISO-8601 in its entirety relatively complex to grasp. The currently supported date formats aim to be a tradeoff between “flexible enough” but “not too complex yet”.

> Why wouldn't you allow space before the checkbox?

To enforce a tidy layout of the file. Whitespace before the checkbox (i.e. on the same line) is undefined behaviour. The idea is that editor plugins help users with compliance of the rules. For example, I think that all available [x]it! editor plugins would highlight it if there was illegal whitespace in front of a checkbox.

Re: A plain-text file format for todos and check lists

#58

Post by jotaen »

rubenv wrote: post #56
tommyage wrote: post #52

Earlier quoted context omitted.

> - doesn't support UTF-8 checkbox emoji That's a good thing. Its also unicode, not utf-8. Your plugin can display it with a unicode character. Having a simple ASCII char set helps portability _a lot_. No benefit in supporting unicode code points. > - doesn't support nested lists If you can tick all items within a nested list, why bother writing it with dedicated TODO items? Additionally, you can just create more fil…

Sticking to ASCII in this day and age is nice and fun if English is your mother tongue, but it's a big middle finger to the rest of the world. Please don't.

Per specification, [x]it! files must be UTF-8 encoded. (See https://github.com/jotaen/xit/blob/main/Specification.md#fil...)

You can use Unicode characters in item descriptions, so you can write these texts in Japanese, Finnish, or Greek. Only the “syntactical elements” (like checkboxes, priority, due dates) are made up from ASCII characters, to ensure that they are easy to type.

Re: A plain-text file format for todos and check lists

#59

Post by jotaen »

NoboruWataya wrote: post #55

I like the simplicity of it. Sorry if I've missed it but are there already good tools built around this?

There currently are a bunch of editor plugins and one CLI tool. You find a collection of tools (all third-party) linked from the project website: https://xit.jotaen.net
Post reply on HN