Add all the tags into the vimwiki task, ignoring the default ones?

Recurring task status is currently unknow, should it be handled as 'Pending'? How to deal with it?

• daily_overview
• instant_notifications

Currently, vimwiki-tasks does not reflect the task-subtask relationship via the dependency paramter.

* [ ] Task
  * [ ] Subtask 1
  * [ ] Subtask 2

the created Task should depend both on the Subtask 1 and Subtask 2.

One of the things I like about vim-taskwarrior, is that it has adopted a command-name convention so that all of it's commands start with ":TW.." and that makes the commands a) easier to remember, and b) makes all of the related, applicable commands instantly available with tab-completion. :TW-tab and you see before you the whole set of related command options, it's a beautiful thing :)

Now vimwiki-tasks has a smaller-but-growing set of commands, and in experimenting with them, I sometimes forget exactly what commands exists for a given context, and what they're called exactly.

So I'd like to put forth a potentially controversial idea that vimwiki-tasks and vim-taskwarrior could both use that same command prefix: TW! The two applications are both "taskwarrior-in-vim" and there is plenty of "namespace" to go around. This could be done in a complimentary way.

:TWCmd (TaskCmd)
:TWInsert (InsertTasks)
:TWModify (TaskModify)
:TWNote (OpenTaskNotes)
:TWUpdate (UpdateTaskLists)
:TWCopyUuid (CopyTaskUUID)
:TWDisplayUuid (DisplayTaskUUID)
:TWCopyId (CopyTaskID)
:TWDisplayId (DisplayTaskID)

(have a look at the command-wish-list, embedded as comments, at the bottom of this file; https://github.com/farseer90718/vim-taskwarrior/blob/master/plugin/taskwarrior.vim, many of the suggested (wished for) commands will never be incorporated in vim-taskwarrior, but several are more perfectly suited to vimwiki-tasks)

The upshot, if we (you ;-) were to adopt this command-name convention, is that whether using vimwiki-tasks or vim-tw, or back-and-forth between the two, all taskwarrior-related commands would be at hand. most just available for that filetype, some local to the buffer, and a few global commands from each, and you could see them all, instantly, with tab-completion.

Even if (especially if) the :TWAnnotate command were used by both programs, for similar intent, using entirely different code, there's actually no conflict, because each is acting locally, on it's own filtetype. Global-commands would have to be unique, but there aren't that many of them. Otherwise, it's just re-enforcement of the same behavior, the path of least surprise, and the overlap simplifies things. All you really have to know then is :TW-tab.

I think the fact that a %%TaskList doesn't remove completed tasks automatically, is a feature! Good behavior!

But I'd like to be able to manually delete them from a listing, and have them stay gone. I don't want to "delete the completed ones" or anything, but hoping there was a way that the sync process could (optionally?) not remove them automatically, but also not re-import completed or deleted tasks once manually removed.

InsertProject is is related to InsertTask, but outputs the tasks with vimwiki headings.

As an example, If I were to issue the command ":InsertProject foo", and within the "Foo Project" if there are several sub-projects implied by the proj:name.sub.sub convention, the output is grouped in corresponding sub-headers. As an example, with proj:foo, proj:foo,baz, proj:foo.bar and proj:foo.biz.buz, resulting listing might look like

= foo =
* [ ] task
* [ ] task
== bar ==
* [ ] task
* [ ] task
== baz ==
* [ ] task
== biz ==
* [ ] task
=== buz ===
* [ ] task
* [ ] task

InsertProject with no attributes might output all tasks to a vimwiki file, sorted into project headings, one of which might be "none".

The InsertTasks command has the potential to make a superb task "dashboard", embedding queries into a wiki page with your regular activities, deadlines and current projects, etc.
While arranging a page to do this, I find myself creating descriptive headings above the "%%TaskList: " line, and while that works ok, it has a redundancy and a "double list header" that could be improved.

So the idea here is to embed the %%TaskList: in the form of a vimwiki link. something like this;

[[%%TaskList: +DUE +work desc.startswith:call|Work Calls]]

All of which would be concealed but the "Work Calls" part, unless the cursor were over it.
This could stand alone or be used in a heading, or as a list item, and the output should respect indentation.

A vimwiki link typically goes somewhere, but hitting enter on this one should invoke UpdateTasks, maybe even reload the page, in case external changes have occurred.

There has been some discussion of "executable links" on the vimwiki github site, which may (or may not) be helpful; vimwiki/vimwiki#19

With regards to highlighting, because this form is always intended to be the header of a list, it might be a good visual cue if this link-type was always underlined when concealed, but that would be icing on the cake!

Maybe a very early step should be to see if any changes have occurred to pending.data since "the last time", because that could have implications for syncing confusion.

When you said tasks and TODOs could co-exist, you weren't kidding!

A vimwiki todo (not connected to tw) can be inserted within a TaskList and it looks identical, even using the same syntax highlighting for +tags (even if a tag in a todo doesn't do anything) and the only way to tell that it's not a tw task is to move the cursor over it, and notice how UUID does not pop up.

Coexisting is good, but there should be some clear visual clue differentiating the two types.

When I have a task in my vimwiki file, which was marked completed upon loading:

* [X] Next random thing (2014-11-21 00:00) #785e10ef-5f7d-44b8-83c6-f7be496b94aa 

and I undo the task completion, the change is not propagated to the taskwarrior:

$ task 785e10ef-5f7d-44b8-83c6-f7be496b94aa info | grep Status
Status        Completed

Upon reloading the file, I can see that task is again showing up as completed in the wiki file (which is correct, since that is performed by the vimwiki-tasks sync upon loading the file).

This great-big feature request seeks to answer the question
"where should I find the wikified version of this task?".

It rests on a number of suppositions

• users of this plugin have a $TASKDATA environment variable, usually ~/.task.
• it is desirable to keep task data together, for ease of use and portability.
• wiki-tasks is different enough from vimwiki, that it should not use ~/vimwiki/ by default.
• a real-world project may need it's own files directory and/or it's own sub-wiki.
• a (sub)project can have it's own folder (../foo/index.wiki) or wiki (../foo.wiki) but not both
• wikified tasks could be in any wiki, and in multiples, no problem, but
• a known or anticipated location for each task within a wiki would be preferable.

So considering all of that, it's still not immediately obvious where a specific task should be found within an automatically-generated wiki hierarchy, but it's possible.

Let me start with the $TASKDATA/index.wiki and $TASKDATA/project/index.wiki and work from there. Like the subject-line says, this is a "project-centric" idea, and presumes a hierarchy that follows a tree of projects and subprojects. A project or sub-project will only get it's own folder or wiki if the user creates it, but if it does exist, we can follow a convention, and work down the tree logically, from the highest branches to the trunk.

As a more complex example, let's locate the proper wiki entry/ file for the following task;

task add proj:tw.web.ui choose initial color scheme

Where should this go?
We'll start from the most granular possibility, and work towards the simplest;
(the first one that exists is the correct place for this task)

• if exists $TASKDATA/project/tw/web/ui/index.wiki

then the ui sub-sub-project has it's own folder

• if exists $TASKDATA/project/tw/web/ui.wiki

then the ui sub-sub-project has it's own wiki

• if exists $TASKDATA/project/tw/web/index.wiki

then the web sub-project has a folder, look under heading == ui ==

• if exists $TASKDATA/project/tw/web.wiki

then the subproject has a wiki, look under heading == ui ==

• if exists $TASKDATA/project/tw/index.wiki

then the project has a folder, look under == web, === ui sub heading

*if exists $TASKDATA/project/tw.wiki

the project has a wiki, look under == web, === ui sub heading

• if exists $TASKDATA/project/index.wiki (and it will exist, or be created)

the project has no folder or wikis, look under == tw, === web, ==== ui heading.

Without any sub-folders or sub-wikis, all tasks with projects will be listed under project-driven headeings and sub-headings in $TASKDATA/project/index.wiki.
Tasks with no project are all listed in $TASKDATA/index.wiki (the root of the taskwiki tree)

This scheme allows for things to start small, and if a project or sub-project needs to add a folder full of related files, or it's own sub-wiki, then related tasks can be automatically moved to the right place, inter-wiki links are automagically (re)generated.

thanks for reading through all of this, I hope at least some of it makes sense :)

One of the most important things about a tw extension is that it can pass the "round-trip test". That's where a task is created on one platform and then transfered to the other platform and modified. Tasks get sent back to the first platform, to see if the initial tasks and changes are intact. For this to happen, each platform has to be able to accept and preserve all of the data the other one sends, and in turn, send all the data back. To do that, a wikified task has to be able to handle any attribute that gets thrown at it.

So my idea for a "wikified task" uses existing vimwiki definition lists, and should be visually clear and easy to manipulate. It looks almost like (but better than) task info.

   - [142] This is a task description 
      Status::       Pending  
      Due::          2013-12-21-00:00:00
      Area::         it.tw    
      Project::      wiki
      Phase::        2
      Tags::         test,feature
      Entered::      2013-10-28 02:29:43 (8 days)
      :: 2013-11-31 22:01:08 -- this is an annotation
      :: 2013-12-04 19:21:20 -- docs: https://github.com/vimwiki/vimwiki/tree/master/doc
   - [212] This is the next task..               

this is of course foldable, and when folded, the line could look like;

   - [142] This is a task descrip..(2003-12-21) +test,feature [2]

all of this being automatically populated, on wikifying a task, and changes are sent to tw like they are now (but with more data. :) and the whole thing becomes a task-text-object.

Each task can optionally be linked to a vimwiki 'taskpage'.

• linked as an annotation, to make it compatible with taskopen
• all stored in a specified path
• UUID.{md,wiki} filename

One of the things that I think would be great, in melding tw and vimwiki functionality, is the chance to log all relevant activities to my vimwiki diary file for the day; tasks added, completed and deleted, as well as the usual treatment, if such actions were automatically logged to the days diary, would enhance the record of the day.

standardized, foldable header with

= tasks = 
== added ==
   - [ ] do laundry
== completed ==
   - [X] feed cat

And there's no reason (?) these tasks couldn't be just as actionable from within that diary file.

Because taskwarrior tasks all have added, complete, deleted dates, a GenDiaryActions function could retroactively create these entries (and diary files, if needed) from past actions. I would draw the line at modifications, I don't really need to know that I added a tag that day.

I would also like to see other activities in other programs logged in the same way,
but that's a different kettle o fish!

Using a set of %%TaskLists that represent things you MUST do, by your own definition. This would start with any +OVERDUE and +DUE_TODAY, but could include queries for current projects, kids, family, whatever you felt was imperative, and you could define in a query.

The magic here is that if the query finds 0 matches, it is silent, not displayed, and once ALL of the imperative tasks for the day have been marked as done, it would show no lists but instead a "task logo" and a fortune, as a reward.
Go for a walk! All the important stuff is done!

It's not that unrealistic, that if you defined the must do set of tasks as a short list, you might just line them up and shoot them down to get to the "fortune"! right?
That makes you officially "on top of it"!.

..and tomorrow that same page may have new entries!

The [N] of items below the fold is an excellent thing, and could be somewhat misleading.

When the line says

== Task details == [9]

I actually have 7 attributes listed, and under

== Annotations == [2]

there are no annotations. (same for == Notes == [2])

Now I understand this is a line count, and subtracting "2" will usually give the actual number of items below, but it may be worth considering excluding the heading and any blank lines from that count, for details, Annotations and Notes.

An exception to this might be the very first heading of the task, with the description, as that contains several sections, and overall number-of-lines, including other headings and blank lines, makes as much sense here as anything else.

Deleted tasks are currently ignored when syncing from TW to VW. Should they be handled? Possibilities:

• Ignore
• Delete in VW
• Mark as done in VW
• Mark as deleted in VW
• ...?

or maybe interactively ask what to do?

I guess the title says it all.

Shouldn't vimwiki-tasks provide a configurable option to sync all the tasks?

I often have projects, which I can outline in the matter of subsequent tasks, but I cannot yet give them deadlines (and don't want to, since that slows me down at that part of the process). Remembering to write #TW to each task can become annoying.

https://github.com/tbabej/taskwiki seems to do something similar. Please make a link to it so people who hit this page are aware of it.

I feel quite strongly that while ID is a transient, and not a good programatic reference (like UUID) but it IS the user-handle for all tasks. If a user wants to take an immediate action with tw or an extension, it will almost always be using the ID(s) as reference.

So it has to be visible, and to me the most economical, obvious spot is in the checkbox, but I would otherwise treat this checkbox like usual. Now that you have figured out how to conceal the UUID, maybe the checkbox could act like a link, with uuid as target, and ID as the displayed value?

When a task is completed, and it loses it's ID, that should change to [[uuid|X]]

Just a kooky thought here, a "task add" routine within vim provides an opportunity to use vim abbreviations. This enables something that has been requested for years; add something in a short-form that get's expanded before saving.

example:

$ task add get tps @work 

becomes

$ task add get Training Progress Report proj:train pri:h +work

vimwiki-tasks has a number of features that are undocumented, and only discoverable by reading closed issues and combing through the code. If you have the chance please update the README to describe all of the current capabilities, and a vim-help file, vimwiki-tasks.vim, would also be very handy.