Closed nodingneu closed 3 years ago
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.
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.
.todo
seems too generic. How about .todo.txt
? For example myproject.todo.txt
.
That one could even serve for a migration path, if \.?todo.txt
would be searched for (meaning: existing todo.txt
files or those endings).
@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.
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.
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.
@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.
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?
@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.
I doubt that python has an extension requirement. The specification cannot guarantee that a *py file contains comprehensible data
You're right ig the spec doesn't need to (and perhaps shouldn't?) define the extension used.
@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.
The whole specification should apply to
.todo
files.I envision
~/Music/piano.todo
,~/Music/guitar.todo
,~/MyProject/project.todo