On Wed, Dec 9, 2020 at 3:21 AM Ansgar <ans...@debian.org> wrote:
>
> 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 -
https://manpages.debian.org/unstable/todo.txt-base/index.html).
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?
BTW - https://salsa.debian.org/debian/todotxt-cli/-/merge_requests/2
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.
--
AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE
