tools-life / taskwiki Goto Github PK

Showing whatever combination of filter and user-defaults, that will be added to new tasks, would be valuable info for Inspect

(related to #3)

When tasks exist in wikis, there is often benefit in embedding a link in the task data, so that one can easily find the wiki from the task, however there are desirable configuration options. here are a few ideas;

g:taskwiki_backlinks_enabled=1 (or 0=disabled)
g:taskwiki_backlinks_type=annotation (or 'uda: blink')
g:taskwiki_backlinks_prefix='wiki: ' (good for annotation-type, not so good for UDAs)

There are also strong arguments for in-line overrides to the backlinks_enabled config. For example, if I wanted to have a record of my tasking activity in my vimwiki-diary (which I do) and that featured a listing of every task added, completed or due on that day, then that would cause every task to have a link to a diary file, and that would be.. noisy. So, much like the project-default and tag-default inline settings, backlinks on-and-off settings would be great, like;

%backlinks (at the top of the file, with no other over-ride, would turn on backlinks for the whole file)

task, task, task list

%nobacklinks (turns off backlink behavior for tasks that follow)

task, task, task list

%backlinks (and back on again)

== Test tags | +test ==

delivers a list of 62 tasks with "test" in tag, description or annotation, when there are actually only 5 task with "+test' tags.

The original vimwiki-tasks features the option to embed a "traceback" link to the wiki file, in an annotation of associated tasks. This enables the user (using tw) to find those tasks that are also represented in a wiki, and b) easily follow those links to the wiki-file, using taskopen. (https://github.com/ValiValpas/taskopen)

The annotation should look something like "wiki: path/to/file.wiki", using the "annotation label" convention.

Taskwiki uses indentation to denote dependencies, however, tasks generated by the viewport are simply added at the base level of indentation.

The recent flurry of TaskWiki commands is stupendous. Now there is a command for everything, but especially if you are using tab-completion, tabbing through the commands, imho, there are now more commands than necessary.

namely;

• TaskWikiBurndownDaily
• TaskWikiBurndownMonthly
• TaskWikiBurndownWeekly
• TaskWikiGhistoryAnnual
• TaskWikiGhistoryMonthly
• TaskWikiHistoryAnnual
• TaskWikiHistoryMonthly

The way task cli handles it, is to allow "daily, weekly, monthly, annual" as arguments, following the command, and one of them is the default, if no argument is used. So instead;

• TaskWikiBurndown [daily|monthly|weekly] defaults to weekly
• TaskWikiGhistory [annual|monthly] defaults to monthly
• TaskWikiHistory [annual|monthly] defaults to monthly

In a ViewPort definition that looks like this;

=== Taskwarrior Tasks | +PENDING project:tw | area:it ===

and taskwiki a) does not recognize the user-default UDA, and so b) replaces the description of new tasks with "area:it".

a) taskwiki should recognize UDAs for this purpose
b) taskwiki should never use any VP default to replace the description.

Taskwarrior will do this at the cli, too, if it doesn't recognize an element. will use it as a replacement for the description. Unfortunately, this is almost never the users intention, and it is even less likely to be the right thing in a taskwiki viewport.

Currently, the syncing between taskwiki and TW is done on file save. We should create user commands for this.

The following viewport will not assign its defaults:

=== Random stuff | +stuff | +stuff ===

The description should be highlighted in color.

This is a custom vimwiki scheme (see :help vimwiki 5.12. Schemes and VimwikiLinkHandler) that can be used to generate a task list.

The main idea is to provide a link, that causes a list to be generated, showing ALL tasks that match the < filter >. This way, a user could create a heading;

== [[task: proj:tw +bug|Taskwarrior Project Bugs]] ==

and then can be confident that every task matching the filter would be inserted below the heading, in taskwiki format. Changes and additions are then propagated to and from taskwarrior.

This command opens a new split window with the full task info, like the 'task info' command, or even more the vim-taskwarrior TaskInfo command.

This configuration sets the hight of the info report window.
Setting "0" leaves the window hight determined by the report, and the available window.

to reproduce, cursor over a task, invole :TaskWikiAnnotate, but don't enter a value, hit ESC instead.

I get;

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/djp/.vim/bundle/taskwiki/taskwiki/taskwiki.py", line 96, in annotate
    vimwikitask.task.add_annotation(annotation)
  File "/usr/local/lib/python2.7/dist-packages/tasklib-0.9.0-py2.7.egg/tasklib/task.py", line 666, in add_annotation
    self.warrior.execute_command(args)
  File "/usr/local/lib/python2.7/dist-packages/tasklib-0.9.0-py2.7.egg/tasklib/task.py", line 947, in execute_command
    raise TaskWarriorException(error_msg)
tasklib.task.TaskWarriorException: Using alternate .taskrc file /
Using alternate data.location /home/djp/.task
Configuration override rc.bulk:0
Configuration override rc.confirmation:no
Configuration override rc.data.location:/home/djp/.task
Configuration override rc.context:
Configuration override rc.recurrence.confirmation:no
Configuration override rc.dependency.confirmation:no
Additional text must be provided.

If the last argument of a ViewPort is a named listing report, then the "report.name.sort=" line is used to drive the sort-order of the ViewPort. This does not use any other aspect of the defined report, and does not affect the metadata that Taskwiki displays.

=== FooBar tasks | project:foo +bar ls | project:foo ===

will use the report.ls.sort= definition, to determine the order that tasks are displayed. This obviously would apply only to those reports that generate task lists (list, ls, long, minimal etc.) unlike summary or graphic reports (ghistory, summary etc) which would be ignored.

A ViewPort will assign any (simple) attributes in the filter, to any new tasks created under it. That way new tasks won't simply disappear as soon as they are added. If you want to define what attributes are added, you can do so after the second "|", like this;

== ViewPort Title | project:foo +bar | +bazz ==

and this will add "project:foo +bar +bazz" to any new tasks.

But it's easy to define a valid ViewPort filter, with or without added defaults,

== Most Urgent Tasks | +PENDING urgency.over:20 ==

where the new task may or may not match the filter, and it may or may not disappear as soon as it's saved. This is OK, and should be allowed, but it might be mitigating (less disturbing) if a warning message were generated, when a new task is about to be saved, under a ViewPort with no discernible default in the filter.

Manual testing is boring! Also, we have no idea how taskwiki runs on older versions of vim/taskwarrior.

We should leverage Travis CI to run the tests for us.

This command generates an

Annotate: 

prompt, and adds the annotation to the selected task(s)

This issue presumes a number of things, but I thought I would express what I feel might be an optimal layout for a task, in a vimwiki.

== [[task: +test|test tasks]] ==
* [X] bfea17e6 continue testing twwiki                                  :test:
        * this is the first annotation
* [ ] 107 stop screwing around with taskwarrior!                        :test:
        * [ ] 108 take stats                                        :foo:test:
        * [ ] 109 test again Project thing                              :test:
                * [ ] 111 yet another test                          :test:bar:
                        * annotation for above
                        * another bullet point/ ammotation
                * [ ] 115 the last task                         :baz:test:buz:

The heading is shown with the link "open",
the anotations are presented as sub-list points,
the task IDs would be hilighted as links (to uuid), the first one, completed, used [[uuid.short|uuid]]
the tags are shown with the upcoming vimwiki tags format, and right-justified, just like they would be in orgmode.

Having some part of the ViewPort filter in the default, makes sense, to prevent new tasks from seeming to disappear. For example;

=== World Domination | project:dominate +world | project:dominate +world ===

and the new tasks created under this ViewPort will be listed.
This RFE is for a short-hand for those cases (like the example above) where the defaults are a duplicate of the filter, which should be a fairly common occurance. The example above could then entered as;

=== World Domination | project:dominate +world | * ===

Annotations can be logically presented/ created as indented list items, under a task. As long as the text-block remains contiguous, then annotations should not affect dependency/ hierarchy,

* [X] continue testing twwiki                          #bfea17e6-778a-43e0-8508-a7d29b39673d
        * this is the first annotation
* [ ] stop screwing around with taskwarrior!                     #1c5f75ac-8fa6-4913-9305-3f63d21dcde5
        * [ ] take stats          #5e485bd4-576d-40c7-919f-7d02dbc6cf6b
        * [ ] test again Project thing              #ec44828b-e6b8-48f8-9815-43360f57e352
                * [ ] yet another test         #18206957-d35b-43e7-9177-5f20d95a0fc1
                        * annotation for above
                        * another bullet point/ ammotation
                * [ ] the last task  #30783ba1-4262-482c-a983-f7339512fb85

Like the Default Values in teranex's vimwiki-tasks, if the first ten linkes of a wiki-file have

%% Project:
or
%% Tags: +tag1 +tag2

then these values are added to each new project on that wiki page.

This command is a toggle that shows/ hides the ViewPort metadata. ("hide" being the default) This would mostly be for diagnostics.

TaskWiki has several requirements, and may not operate correctly if these dependencies are not installed, or at their minimum versions. This RFE is for a diagnostic routine that tests for these requirements, and generates a warning message, or throws an error, if these requirements are not met.

Currently, invoking ':TaskWikiInfo 142' generates an "E488: Trailing characters" error, but I think it would be swell if it opened the info-window of 142, instead.

This command makes it easy to open/ create project.wiki files.
Using the configurations;

let g:taskwiki_project_dir = '~/.task/project'
let g:taskwiki_project_ext = '.project.wiki'

and entering

:TaskWiki foo

or using

:TaskWiki(space)< tab >

completion, should offer all top-level projects.
Enter a name or select a project and hit < enter > and the "~/.task/project/foo.project.wiki" file is opened for editing.

imho, the UUID should be presented as a wiki-link in the form of

[[task: bfea17e6-778a-43e0-8508-a7d29b39673d|ID]]

with the task ID (52, in this example) presented as the description.

This could have several advantages

• less "visual noise", as only a few characters are seen (unless the cursor is over it)
• task ID is immediately available, so regular tw actions can be performed
• link gets syntax highlighting
• special link handler can be used to "follow the link" and get task info.

Currently, deleting a task in a ViewPort or a wiki, does not delete the task from pending.data, and this is good.
But if you actually wanted to delete a task or tasks, the command :TaskWikiDelete, on a single task or visually-selected group, would make that possible.
The command could also use trailing ID(s) or UUID(s), instead.

Make sure the TagBar displays headings and viewports in a hierarchical view.

This command would sort a ViewPort or visually-selected group of tasks, using the <field(s)> argument, perhaps emulating a report.foo.sort= config syntax.
If no arguments provided, the command should sort on description(?).

This command makes it easy to open/ create project.wiki files.
Using the configurations;

let g:taskwiki_project_dir = '~/.task/project'
let g:taskwiki_project_ext = '.project.wiki'

and entering

:TaskWiki foo

or using

:TaskWiki(space)(TAB)

completion, should offer all top-level projects.
Enter a name or select a project and hit < enter > and the "~/.task/project/foo.project.wiki" file is opened for editing.

The TaskWikiGrid looks almost exactly like a vim-taskwarrior report, but doesn't act like it, vim-tw has a slew of features, and mappings, that I wouldn't expect TaskWiki to re-implement.

So I would suggest that TaskWikiGrid implement a simplified grid unless vim-taskwarrior is found to be installed, in which case, the command should pass the job off to vim-tw.

Love the idea, but seeing errors;

"~/.vim/wiki/index.wiki" 85L, 3849C
Traceback (most recent call last):
File "", line 1, in
File "/home/djp/.vim/bundle/taskwiki/taskwiki/taskwiki.py", line 58, in projects
util.show_in_split(output, name="projects", vertical=True)
File "/home/djp/.vim/bundle/taskwiki/taskwiki/util.py", line 117, in show_in_split
vim.current.buffer.append(lines, 0)
TypeError: bad argument type for built-in operation

This would allowe users add/edit aribtrary metadata to the selected tasks.

One of the first things I might suggest, is to rename ALL of the commands!

That's right, all of them!

The original vimwiki-tasks is essentially undocumented, save for the commit messages, as each feature was added by teranex. Now don't get me wrong, the functions are amazingly clever, but the command names are undocumented and undiscoverable, and I think a new command-naming-scheme could really help that.

Take vim-taskwarrior as an excelent (and related) example. Ze He (the author) used "TWXxxXxx" in naming all vim-tw commands, and as a result, all vim-tw commands are easily seen in vim, with ":TW< tab >" completion. I don't consider this a conflict, I'm quite sure that Ze has no great plans to use "TWW" (or any new user-commands, actually) and that would make this program's commands discoverable while using that program!

and so I would nominate ":TWWXxxXxx" for all of this program's user-commands, because

• it will make all commands easily discoverable
• it's easy to type
• it's easy to remember (TaskWarrior Wiki)

for example:

:TaskCmd
becomes (simply)
:TWW

:UpdateTaskList
becomes
:TWWUpdate

:InsertTasks
becomes
:TWWInsert

:DisplayTaskUUID
becomes
:TWWUuid

:CopyTaskUUID
becomes
:TWWCopyUuid

There may be existing commands I don't know about, and tons of room for new features and commands, but that should get the idea across.

While TaskWiki displays only a limited amount of metadata (description, due:date, started) but tasks could be entered with any metadata. As soon as the new task(s) are processed, that metada will be hidden, like usual.

== Make RFE example | project:taskwiki +RFE | project:taskwiki ==
* [ ] Existing task 1
* [ ] Existing task 2
* [ ] area:software +RFE depends:412 -- New task desciption

Using "--" to precede the description should make it easier (possible) to parse, as soon as taskwiki processes the new task(s), they are displayed as usual, with the extra metadata is hidden, like

* [ ] New task description

What's the visual difference between a ViewPort where the filter has no matches, and a regular vimwiki heading? The answer is: none. A ViewPort with matches at least has a group of tasks below it.

A viewPort could still be useful with "no matches", but there should be some indication, and it shouldn't take up any extra lines, so I suggest:

== Booze Business Tasks | +bizz +buz +booze ==

might resolve to:

== Booze Business Tasks == (no matches)

in normal mode

This is analogous to the vim-taskwarrior :TW command, which is effectively like having a task-shell within vim. The major difference would be that it will operate on visually-selected tasks, otherwise, it is a global command. It does not normally focus on the task below the cursor, unless it is visually selected.
Just as in task cli, precautions against BBQing you whole data-set, with "This will apply to all tasks in the database, are you NUTS?? (yes/no)" warning messages

A task as represented by taskwiki, has two fields displayed by default. This feature request is for a .vimrc config allowing custom task field selection and layout, including left and right justification.

Currently, the default task layout might be represented as;

g:taskwiki_fields = '%desc (%due)

but a custom config might look like;

g:taskwiki_fields = '%desc [%project] | (%due) %tags

those on the right side of the "|" pipe would be right-justified, those on the left, left-justified, so that an example task with the above custom config might look like;

* [ ] call Sue about piano lessons [music]         (2015-03-20) :skills:weekly:txn:

With the ability to have defaults in headings and sub-headings, as long as the blocks are contiguous (same text-object) the defaults could be inherited. So for example;

== Bake Sale | | project:bakesale == # this header has no filter, or list, but has default
=== Baked goods | project:bakesale +bake | +bake === # (also project:bakesale)
* [ ] pick recipes
* [ ] bla 
* [ ] bla 
==== Shop for ingredients | project:bakesale +shop | +shop === # (also +bake & project:bakesale)
* [ ] get flour
* [ ] get sugar
=== Labeling | project:bakesale +label | +label === # (also has project:bakesale)
* [ ] design labels
* [ ] print labels

Maybe not the most exciting use-case, but just outlining the idea.

Using this command is like issuing 'task mod < mods > on the task under the cursor, or visually-selected group of tasks, and would allow modification of any attribute, without leaving the wiki and losing focus. Mods should be reflected in any ViewPort on the page, immediately after making changes.

note* User with vim-taskwarrior already installed, can already do something similar :TW < anything >

Probability of clash on 100 tasks in the same taskwiki file is 0.0001%, so using full uuids as metadata might be a overkill.

This should help with vim overeagerly wrapping the lines, since cocealed characters can cause line wrapping too.

Which defaults to the beggining of the unix epoch. Needs investigation.

* [ ] Set goals for the next day (2014-01-13 22:00)  #c23972c9-813a-4c29-b858-acfcaf8b60e3
  * [ ] Set reccurring task in TaskWarrior (1970-01-01 01:00)  #d3cb5ef6-8f78-4ccf-a210-d52e077122fa

On my box, 'tw proj:tw' yields 20 pending tasks, and 'tw proj:tw all' only shows 27 tasks, but

== Taskwarrior tasks | project:tw ==

generates a list of 80 tasks! (most of them since deleted)
This ViewPort includes some completed tasks, but neither

== Taskwarrior tasks | status:pending project:tw ==

nor

== Taskwarrior tasks | +PENDING project:tw ==

make any difference, still 80 tasks.

Regression, workaround - use :TaskWikiMod.

It would be very convenient if, in normal mode, and only when over a task, hitting invoked TaskWikiInfo.

Wherever possible, vimwiki Todo list key-mappings and behavior should be adopted for taskwiki.

(from vimwiki.txt)

Todo lists                                                vimwiki-todo-lists
------------------------------------------------------------------------------

You can have todo lists -- lists of items you can check/uncheck.

Consider the following example: >
 = Toggleable list of todo items =
   * [X] Toggle list item on/off.
     * [X] Simple toggling between [ ] and [X].
     * [X] All list's subitems should be toggled on/off appropriately.
     * [X] Toggle child subitems only if current line is list item
     * [X] Parent list item should be toggled depending on it's child items.
   * [X] Make numbered list items toggleable too
   * [X] Add highlighting to list item boxes
   * [X] Add [ ] to the next list item created with o, O and CR.

Pressing  C-Space  on the first list item will toggle it and all of its child
items: >
 = Toggleable list of todo items =
   * [ ] Toggle list item on/off.
     * [ ] Simple toggling between [ ] and [X].
     * [ ] All of a list's subitems should be toggled on/off appropriately.
     * [ ] Toggle child subitems only if the current line is a list item.
     * [ ] Parent list item should be toggled depending on their child items.
   * [X] Make numbered list items toggleable too.
   * [X] Add highlighting to list item boxes.
   * [X] Add [ ] to the next list item created using o, O or CR.

Pressing C-Space on the third list item will toggle it and adjust all of its
parent items: >
 = Toggleable list of todo items =
   * [.] Toggle list item on/off.
     * [ ] Simple toggling between [ ] and [X].
     * [X] All of a list's subitems should be toggled on/off appropriately.
     * [ ] Toggle child subitems only if current line is list item.
     * [ ] Parent list item should be toggled depending on it's child items.
   * [ ] Make numbered list items toggleable too.
   * [ ] Add highlighting to list item boxes.
   * [ ] Add [ ] to the next list item created using o, O or CR.

Parent items should change when their child items change. If not, use
vimwiki_glr. The symbol between [ ] depends on the percentage of toggled
child items (see also g:vimwiki_listsyms): >
    [ ] -- 0%
    [.] -- 1-33%
    [o] -- 34-66%
    [O] -- 67-99%
    [X] -- 100%

It is possible to toggle several list items using visual mode. But note that
instead of toggling every item individually, all items get checked if the
first item is unchecked and all items get unchecked if the first item is
checked.

Use gl Space (see vimwiki_gl Space) to remove a single checkbox and
gLSpace (see vimwiki_gL Space) to remove all checkboxes of the list the
cursor is in.

Vim airline can provide a valuable, information-rich status line.
Vim-taskwarrior can use it very effectively, if it is installed, but it's not a requirement, and I think TaskWiki could take advantage of it too.