[tommyage]

> - 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.

[rubenv]

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.

[jotaen]

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.

[sowbug]

Perhaps the spec could allow an implementation to support a run-time option to recognize alternate characters for syntactic elements. This would have the downside that one person's data might not be shareable with another person's [x]it installation. But that's not necessarily a bug, especially to people who don't plan to share their todo lists.

This run-time-option-only approach would be much better than the "be liberal in what you accept and strict in what you emit" philosophy that tends to cause fragmentation on lots of different levels.

[josephg]

> Perhaps the spec could allow an implementation to support a run-time option to recognize alternate characters for syntactic elements.

Please don't. The equivalent in programming languages would be localizing the syntactic elements ({}, (), [], '.', etc). Its much simpler for a language ecosystem to have the same syntax regardless of the programmer's language.

As far as I know, international keyboards can still type these characters just fine.

[tommyage]

You are right, I didn't wanted to imply that these lists can only be used by speakers fluent in english. I wanted to imply that grammars of languages are best represented in ASCII.

There are languages written from right to left or top to bottom. No standard I know of are supporting such flexibility in syntax. And it shouldnt be necessary - if the <user text> items within the grammar support unicode but the keywords are ASCII only it can MORE easily adapted than supporting unicode....

[NikolaNovak]

>>if English is your mother tongue

"mother or preferred"

-- I don't disagree with your basic point, but I like to be included :). There's a Lot of us around whose native / mother tongue is not English, but we prefer it for computing tasks (and frequently gaming / movies / entertainment too - Forums are littered with folks complaining of having to "enjoy" a horrible localized version of something, instead of the original English)