Make and support .todo file extension and data format

[ghost]

The whole specification should apply to .todo files.

I envision ~/Music/piano.todo, ~/Music/guitar.todo, ~/MyProject/project.todo

[bobwhitelock]

I always use files with a todo extension when using the todo.txt format, that way I can easily see what format these files should be written in, and conditionally enable todo.txt editor features based on this.

I don't think there's anything specific to the spec that says what your todo.txt-formatted file is required to be called though (apart from todo.txt being an obvious option), and you should be able to configure every (well written) program that uses the todo.txt format to use whichever file you like. So I can't see that anything needs to change for this issue, apart from maybe adding a sentence making it more explicit that the file name doesn't matter.

[ghost]

I consider todo.txt a misnomer...

This specification describes a data format, and .txt is for unformatted text (afaik). Just because it contains text doesn't make it .txt (.json.txt).

I guess you are right that nothing needs to change to just use this format in my own *.todo files, I just wish this spec specified it was defining a new file format and extension .todo and didn't encourage using todo.txt, because it is different to plaintext, and I bet it would encourage more editor plugins—perhaps builtins—to support the .todo file format.

[xuhcc]

.todo seems too generic. How about .todo.txt? For example myproject.todo.txt.

[Ryuno-Ki]

That one could even serve for a migration path, if \.?todo.txt would be searched for (meaning: existing todo.txt files or those endings).

[bobwhitelock]

@theonlygusti

I consider todo.txt a misnomer...

This specification describes a data format, and .txt is for unformatted text (afaik). Just because it contains text doesn't make it .txt (.json.txt).

Somewhat agreed, though a point to note is, I believe one difference between the todo.txt format and most other plaintext but structured files is that any plaintext file is literally a valid todo.txt file, and should be able to be loaded and used by any spec-compliant program that works with todo.txt files. It might not be a todo.txt where tasks have much useful metadata (creation dates, projects, contexts etc.), but at minimum every plaintext file can be interpreted as a todo.txt file where each line is a task containing just the text of that line as a description.

This is in contrast to most other structured plaintext files, e.g. a JSON file needs to conform to a very particular format, which most plaintext files do not. And so in that sense a todo.txt file can be considered a plaintext .txt file like any other, you just might tend to work with it in particular ways and using particular tools.

With that said, I do like being able to easily distinguish files I intend to work with in the todo.txt format vs those I don't, and so I give my own files a todo extension. I think the todo.txt specification is established enough that recommending a particular new extension or changing the usual default file name is unlikely to happen, but that shouldn't really effect how you name your own files using the format.

[arcturus140]

the specification states that todo.txt is a plain text file. Many systems rely on file extension to identify the file type. This is especially true for todo.txt files as there is no other method to identify the type.

A non-standard file extension like todo can only lead to conflicts with other tools.

[ghost]

A "non-standard" i.e. specific-purpose extension like todo means that bespoke tools can be built to handle it.

It also indicates what type of data is in the file (as any file extension is meant to do).

For example ~/shopping.todo, ~/singing.todo, ~/sports.todo, etc. — how can you implement such organisation using only todo.txt?

And if you write your own tool for your own computer to handle *.todo as if they were following the todo.txt specification (or just use this *.todo extension and organisation scheme despite not having filetype handlers for it, as bobwhitelock may be doing)... do you not see how the public at large would be better served if app developers could depend on a consistent meaning of the *.todo filetype? Saves users reinventing the wheel every time they want to use todo.txt's format for any kind of organisation mildly more complex than a single filename.

Why can't this specification just define the .todo extension. I think an entire ecosystem could be built around it.

[bobwhitelock]

@theonlygusti What would be functionally different in programs implementing the todo.txt spec if this did define a todo extension?

Any program implementing the spec should already let you choose the file to operate on, and this could have any extension - .txt, .todo, .py etc., or nothing (so long as a program is well written and doesn't arbitrarily prevent using certain files).

There's nothing special about any particular extension, it's just another part of a file name, apart from as a heuristic to know how you might want to use the data in that file.

[ghost]

Why don't you save all your JSON files with a .exe extension? Why not save all your python source files with a .txt extension?

Why did JSON and Python define their own extensions? Why do you feel it is inappropriate for this specification to do so?

[bobwhitelock]

@theonlygusti I'm not necessarily saying I disagree with you, I'm just trying to establish what it would mean for the specification to actually recommend/require a particular file extension.

E.g. using your examples, I imagine the key reason Python defines its own extension is to allow a smooth experience when importing other Python files, so import .bar in a foo.py file will import an adjacent bar.py file. It also helps people and software to know when they're working with a Python file, but this is only a heuristic; it's perfectly possible, and I often do, to not end Python files with .py - usually this is for scripts which will contain a #!/usr/bin/python line instead.

For JSON, I don't think the spec does recommend any particular extension, or at least I can't see it here: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf. Like the todo.txt spec this just defines the data format, and this can be stored in many ways: in files with and without a .json extension, embedded within code in other files, in a database etc.

[arcturus140]

I doubt that python has an extension requirement. The specification cannot guarantee that a *py file contains comprehensible data

[ghost]

You're right ig the spec doesn't need to (and perhaps shouldn't?) define the extension used.

[bobwhitelock]

@arcturus140

I doubt that python has an extension requirement. The specification cannot guarantee that a *py file contains comprehensible data

Depends what you mean by requirement - while Python scripts can be written in a file with any extension, or none, you do have to jump through a lot of hoops if you want to use the import keyword with a non-.py file. There's probably other things that would break as well if you tried to write everything in non-.py files, e.g. __init__.py being used to define packages.