Given topydo just provides/conflicts with devtodo to provide the "todo"
binary, this seems to violate Policy 10.1 "Binaries" unless they provide
the same functionality.
Note that there is a Conflicts because the current devtodo
does not support alternatives.
As I've said elsewhere, I claim they do provide the same functionality, and are
not in violation of 10.1. I say "topydo and devtodo provide the same
functionality - the ability to add, delete, modify, and display discrete
tasking information". That is not a false statement. The question is, does
it reflect the intent of the Policy?
From where I stand, I would expect the Policy to use a different word to
indicate something along the lines of greater API compatibility. I have no
additional background information, though. Are you aware of any expansions
on this text, or of any precedents that could help with a consensus process?
Different "todo" managers should be coinstallable as different users
might want to use different ones.
The scheme I propose allows that.
From the messages I thought todo.txt is a standard *text* format, but
now you say it is a standard command-line interface? What can they do
if they depend on todo.txt?
Todo.txt is an ecosystem of tools built around a file format. There is a canonical
CLI implementation. Topydo was built as an alternative to that. I'm sorry, but I'm
not sure I understand your question beyond that.
For the most part, todo.txt is an end user tool. As for a theoretical package
that depends on todo.txt, I believe that the core capabilities it requires of
todo.txt are:
- a mechanism for discovering the location of the active tasking file
- an optional mechanism for adding pre and post processing hooks to
task modification activities
These capabilities are present in topydo, with the help of todo.txt-base.
This seems to imply I can manage tasks from the command-line like "todo
new-task eat breakfast"? What interface to do so is provided? Can I
call "todo <file>", "todo", "todo new-task <task>", ...?
It depends. Topydo can run one-off commands (arg[1] is the command, with a
default of "ls" - the same as devtodo). It also has an interpreter mode and a
GUI mode, which I do not believe are pertinent to the discussion.. Devtodo
has one-off commands as well, along with other end point to support specific
commands.
Should emacs provide a "todo" script to open ~/TODO (with say org-mode)?
Again, not sure I understand. To be sure, emacs could be used to edit the file,
if it knows where it is. Note that part of the virtual packages work-up involves
automatic discovery of the file location across providers (see todo.txt-base -
I'm adding a common "--info" argument to all todo.txt providers. An emacs
todo script could use that to identify a todo file to open. But, the core
"todo{.txt}" command does not open the file for editing. See the vitodo
and edittodo commands in todo.txt-base for something similar to what
you are talking about.
All of this is in preparation for another layer of capabilities for todo.txt
providers which is not submitted yet.
If your theoretical emacs script met the criterion I listed above ("--info"
and hooks), I'd say it is worth discussing if that could be a
todo.txt provider.
It appears that a virtual package, or at least these virtual packages in particular,
need a distinct spec separate from their implementations. Where would
you expect to find that documentation? Should that spec be part of this
list application process?
If it is just to have "todo" open a user-chosen program they like to
manage their todo lists with, why not just have the user add a "todo"
alias to their shell or $HOME/bin?
This standardizes that process. Part of the challenge with these tool sets
is the variety of things you have to do to get them to a common working
level. My goal in packaging them is to simplify that as much as
possible
> - name: todo.txt
> description: task management based on a standard free-form text format
This description seem to vague to me: it doesn't even mention what file
format. Does a package providing todo.txt provide any specific user
interface? Emacs can edit todo.txt files: would it qualify (even
without a "todo" executable in $PATH)?
Ansgar
Ok ... does anyone have guidance on the line length limit in that yaml file?
Could you take a stab at a replacement?
I'll just say here that your stance feels unnecessarily aggressive from the
viewpoint of my inbox. I'm just trying to add value here.