new global command :TaskWiki < project >

[linuxcaffe]

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.

[linuxcaffe]

This, of course, has the bonus effect of allowing a user to go

:Tas (TAB) M (TAB)

to invoke TaskWikiMod, instead of

:Tas (TAB) (TAB) (TAB) (TAB) (TAB) (TAB) (TAB) (TAB) (TAB) (TAB) (TAB) (TAB) (TAB) (TAB)

[tbabej]

Well, user can just set:

set wildmode=longest,list

if he wants partial completion of the commands.

[tbabej]

Not sure if we want to implement this. Seems too specific to @linuxcaffe workflow. Not closing yet, I'll let it go over my head.

[linuxcaffe]

Ok, completion is the smallest part (wildmode is an excellent solution) and while the example paths may be somewhat linuxcaffe-centric, the idea itself is quite generic, at least to the idea that a group of tasks is called a "project". It presumes that actual "projects" are a central organizational unit, a core tw attribute, and need much more description, for most users, than taskwarrior presently delivers.

To take this idea from generic to universal, so that other atribute could be handled, the concept could be extended to;

:TaskWiki FIELD  VALUE

as in

:TaskWiki project foo 

(creates or opens .../foo.project.wiki)
or

:TaskWiki area family

(creates or opens .../family.area.wiki)
or

:TaskWiki tag bar

(creates or opens .../bar.tag.wiki)

The caveat: for a field to be valid, it needs to be configured with

let g:taskwiki_area_dir = '~/.task/area'
let g:taskwiki_area_ext = '.area.wiki'
et g:taskwiki_tag_dir = '~/.task/tags'
let g:taskwiki_tag_ext = '.tag.wiki'
etc..

Very flexible, although considerably more complex than the project-only solution. imho, project-only is the way to go.

[tbabej]

So what you're trying to solve here is the problem of filesystem navigation. Different users might have different ideas about how to store their wiki files - whether flat in one directory, whether use subdirectories and how exactly the heirarchy should look like.

Imho these problems are easier solved by a dedicated plugin, like NERDTree. For example, I have:

map <C-n> :NERDTree /home/tbabej/.wiki/ <CR>

in my .vimrc, which fires up the wiki tree immediately, which can be then navigated efficiently, i.e using bookmarks

[linuxcaffe]

Don't completely "hang up" on this one yet. Yes, it is a wiki navigation thing, but it is also a taskwarrior-specific thing, and it's totally user-configurable, so it will fit into whatever file-scheme. The desired outcome is a very fast and very consistent way to navigate from vim to a given project wiki. Yes, you could use a correctly invoked NERDtree, but nothings going to be as fast as

:TaskWiki foo

to get to ~/.task/project/foo.project.wiki (or whatever/wherever)

And it doesn't interfere with any other navigation options.

[linuxcaffe]

Taking it a step further (cause that's what I do) in my grand imaginings, with no other arguments,

TaskWiki

could/ should (using the example configs, at the top) open ~/.task/project/index.project.wiki.