jschlatow / taskopen Goto Github PK

I'm a recent convert to zsh, and I now understand how all of those taskwarrior helper-scrpts actually help, by providing zsh (and others) with completion options.

I wonder if an _openable script, re-written on every "write-to-data-file" action, might generate such a list of the things that taskopen actually knows how to open, so then at the CLI, "taskopen 142" could show all of the logical completions.

-r as in raw

Edit the raw annotation text instead of opening the associated file/URI/whatever.

-C as in Columns

With a default definition in .taskopenrc

columns=$CHOICE) $ANNOT ("$DESC") -- $ID

then just

taskopen -C

would use the default order, aligned in columns, and

taskopen -C '$CHOICE | $LABEL: $ANNOT | $ID $DESC'

would override that order.

Currently, attaching a file to a task is accomplished like so;

task 10 annotate ref: ~/documents/things/this_is_the_thing_to_be_attached.txt <enter>

but there exist several ways to invoke a file-browser to do the same thing.
This feature suggestion (for an external, but related script) seeks to allow you to use your system-default file-open dialog, or a user-configurable alternative, instead of remembering, or cut-and-pasting that path/file.

(I like ranger for this; http://ranger.nongnu.org/, see --choosefile=targetfile option)
so the above command would be accomplished with

attach 10 ref: <enter> (browse to file) <enter>

-v as in version

causes taskopen to print version info, and exit.

-y as in yes

The -y option forces a "yes" response to all following "y/n" prompts, enabling uninterrupted batch processing and unconfirmed -D deletions.

It's just a little typo but the word FOLDER is misspelt in the final line of taskopenrc. It means that it doesn't work out of the box but places your notes in the home directory. It had me scratching my head for a few minutes before I noticed the typo.

Additional options to sort by
time (annotation datestamp)
mtime (file modification time)
atime (file access time)
size (file size)
would be useful.

-c as in color

ideally drawn from the active theme in ~/.taskrc, but not using taskwarriors color rules.
Each field can be mapped to the taskwarrior color.theme, with key=values in .taskopenrc, like

PROMPT=color.header
HELP=color.footnote
DEBUG=color.debug
LIST_BG=color.alternate
ANNOT=color.recurring
UUID=color.overdue
ID=color.due.today
FILE=color.due
LABEL=color.active
DESC=color.pri.none
PRI=color.pri.H
TAG=color.tagged
DATE=color.blocked
PROJECT=color.project.none

That way task users will be right at home with the taskopen colors, and changing themes in .taskrc will change the colors for taskopen automatically.

-n as in Notes

An annotation could be anything, but the -n flag restricts the query to Notes, in the tasknotes FOLDER. thusly

taskopen -n

with no other parameters, would provide a nice browser for those pending-task-related, UUID-named files.

The Type number(s): prompt expects a numeric response, and that makes sense, but I can think of other things that would be handy instead, based on a small set of leading keywords, or option flags.

keywords;
all - selects "all" available choices (like -b after-the-fact)

flags;
if, at the taskopen prompt, you could enter a flag, or set of flags, and taskopen would then re-run the previous command with the new flags, that would allow quick variations.
(see #48 command history)

-Y as in Yes?

This option is sort of the opposite of the -y option (no, it doesn't answer "no").
Using the -Y flag forces taskopen to prompt "Y/n/q" for each item in a batch process, and for changes that would not normally demand confirmation, effectively making each change interactive.
The "n" response would move on to the next action in a series, the "q" response aborts the process.

In this case, more information about the item being acted upon is required, as part of the prompt, so the user knows which annotation is in question.

this is a stub :)

taskopen.pl -l
currently lists all openable annotations, with the command that would be used to open them.
like

djp@tigger:~$ to -l fix
1 annotation(s) found

Please select an annotation:
1) Notes ("fix shower leak")
executes: /bin/bash -c "vim ~/tasknotes/2885bf39-742c-a3a6-4151-06bc50b7e100.txt"

but if I want to directly open one of the results, or otherwise modify it, I have to resort to a matching regex, or something.
If the output were enhanced with the IDs of the tasks, as in;

1) Notes (1 "fix shower leak")

then I could immediately act on that task, either with taskopen or taskwarrior.

also, when using the -l option, the message text "Please select an annotation:" is redundant.

-s as in sort
-S as in sort reverse

sorting is always a tall order,
but the order in which taskopen presents a list,
the sort-driver is important. Sort by;
id
desc
annot
label
would be a essential, and it would be great to sort on any taskwarrior field, like
project
priority
due
or "pseudo-field" like urgency or age

In bash you could do e.g.:

BROWSER=${BROWSER:-firefox}
EDITOR=${EDITOR:-vim}

This will use the already defined BROWSER or EDITOR if it is set. Otherwise, the provided defaults (firefox and vim) will be used.

Also, for BROWSER, wouldn't it be better to use xdg-open and not force firefox or any other particular browser?

Regards,
tzok

Use of uninitialized value in string eq at /home/djp/bin/taskopen.pl line 204, line 26.
Use of uninitialized value in string comparison (cmp) at /home/djp/bin/taskopen.pl line 211, line 26.
Use of uninitialized value in string eq at /home/djp/bin/taskopen.pl line 204, line 26.
Use of uninitialized value in string eq at /home/djp/bin/taskopen.pl line 204, line 26.
and so on, many lines of

-p as in parent

The option additionally selects the annotations of any tasks which depend on the < filter > tasks.

related to #45

-S as in Show

Where taskopen listings now display ("description"), the -S option would replace that with the first line of the annotation file. This might only work for text-based annotations, but it would be especially handy in viewing listings of Notes files.

My most common error by far, in using taskopen, is to run a command (without the -l flag) and then to hit the "up arrow" while at the Type number(s): prompt, in order to modify that command, and run it again.

If taskopen could maintain a command-history, and users could scroll through it with the up/down arrows, while at the Type number(s): prompt, that might work.

This is the "thin edge of the wedge" for some other non-numeric input I would like to use at the prompt.

-M as in Match type
(formerly -t as in type)

taskopen -M [filter1 filter2 filterN] [\label]

Only open files whose file type (as returned by 'file') matches the given regular expression. Note, that applying -M implicitly excludes URIs and everything else that is not a file.

maybe ;-)

see: #17 and #37

1. Allow setting default arguments via taskopenrc.
2. Allow overriding those defaults on cli (particularly -T/-N/-F)

-l as in "list",
taskopen.pl -l [ id | filter ] [ \label ]
wouldn't open annotations, but list all openable annotations that match the query, including the app that would be used to open them, and exits.

Hi, I really like the idea of integrating files and even mutt with taskwarrior.

However, I can't integrate it properly with muttjump. What am I doing wrong?

I use the commands from mutt to create the task and then annotate the message. But it doesn't seem to work:

$ task 43 info

Name Value
ID 43
Description E-mail: "Tesco.com" < [email protected]> - Pay Day deals at Tesco direct + Shop our new TV clothing lines
today
3/30/2012 Message-Id:[email protected]
Status Pending
Tags email
UUID 6f7aef6c-4080-4b5a-a7b6-d358b756bd34
Entered 3/30/2012 (33 secs)
Urgency 1.6

Date Modification
3/30/2012 Annotation of 'Message-Id:[email protected]'
added.

$ taskopen 43
No annotation found.

Any ideas?

-T as in hide Text annotations
(formerly -R as in Regular annotations)
(this is all in active development ;)

(ie. not links or attachments, but "in-line" annotations)

The -t option might cause taskopen to list only regular (non-link) annotations.
-T would hide any such annotations

For example, text annotations such as;

$ task 1 annotate I want to consider this
$ task 2 annotate idea: consider buying a tiny note-book, that looks like an iPhone.
$ task 3 annotate km: 193023-193141
$ task 4 annotate minutes: Consider This meeting \\n 12:12 - welcome \\n 13:52 break for lunch 

related to #24 and #31

E.g:

code: ~/bin/exists.sh
it would be opened with the EDITOR, but if I (also) had

exe: ~/bin/exists.sh
then /that/ would be opened with -x

-D as in Delete

Currently, "taskopen -x rm" will delete the target of an annotation, but it will leave the annotation itself.
The -D flag instructs taskopen to delete an annotation (but not the target).

To delete both target AND annotation

taskopen -x rm -D

A "new" sort order; "as found" in pending.data (or completed.data, if using -aa)

related to #47

-G as in Group

This option is an adjunct to sorting, and breaks listings on change of < field >, into logical groups

This seems like a great script for taskwarrior. I get this message for a task with these annotations though:

ID          8
        10-10-29 00:00 ~/jobb/2010/NOTAT2.txt                               
        10-10-29 19:44 /home/jostein/testing/test.txt                       
        10-10-30 12:28 /home/jostein/testing/date.txt                       

taskopen 8
No annotation found.

-d as in description

this flag would cause taskopen to open the description of < id > using the chosen $EDITOR.

the -d option is a middle ground between "task edit" (which exposes every aspect of a task to editing) and "task mod new-description" (which is replaces the whole description)

Because every task has a description, wider filters might include too many tasks, so < id > might be the sole sensible argument.

-m as in match

taskopen -m

Only include annotations which match the given regular expression. The regex will be applied on the part that follows the label, e.g.:

task 1 annotate web: http://www.taskwarrior.org

so that

taskopen -m ^http

will match, but

taskopem -m web

will not match.

-g as in grep

Using

taskopen -g sometext -l

would list the annotations that had "sometext" in the text of any linked file.

-a as in all

The -a option bypasses the EXCLUDE line (default; status.isnt:deleted status.isnt:completed) in .taskopenrc

-t as in type

taskopen -t [filter1 filter2 filterN] [\label]

Only open files whose file type (as returned by 'file') matches the given regular expression. Note, that applying -t implicitly excludes URIs and everything else that is not a file.

-V as in Versions and Verbose

This option would be the functional equivalent of "taskwarrior version + diag" output, listing versions and locations of taskopen, taskwarrior, perl etc, with full debug and configuration and license details. (some of this could be moved from "taskopen -h") This will make debugging a lot easier.

This also allows the output of "taskopen -v" to be as terse as can be.

-h as in help.
As it stands, if taskopen is run with no arguments, the program gives helpul feedback;

djp@tigger:~$ taskopen.pl
Usage: /home/djp/bin/taskopen.pl <id|filter> [\label]

Current configuration:
BROWSER = xdg-open
TASKBIN = /usr/bin/task
FOLDER = ~/tasknotes/
EXT = .txt
EDITOR = vim
NOTEMSG = Notes
NOTES_CMD = ~/tasknotes/UUID.txt

but this request is to change that behavior.
Instead, if run with no arguments, status:pending should be presumed, and every eligible annotation should be displayed, as though something like "taskopen all" were issued,

The helpful output that is currently triggered by "taskopen" with no arguments, should instead be displayed only when the "-h" flag is used.

Annotations that do not link to external files are still annotations, there is no restrictions on the length of an in-line annotation, they can have labels and they should be treated as first-class citizens.
In opening such an annotations, your $EDITOR is the only logical choice, but they should be listed with the others, and after

$ task 1 annotate www.taskwarrior.org
$ task 1 annotate I want to consider this
$ task 1 annotate ~/tasknotes/1.txt
$ taskopen 1

the answer should be

3 annotation(s) found.

Please select an annotation:

1. www.taskwarrior.org
2. I want to consider this
3. ~/tasknotes/1.txt
   Type number:

-c as in configuration

This option forces taskopen to use an alternate .taskopenrc file.

-N as in No Notes

The opposite of the -n option, -N hides all annotations from the ~/tasknotes/ FOLDER.

-B for Broken links

This option narrows the display to those link-type annotations whose targets are non-existent. This is an important maintenance function, and the only clue you might get that your annotations have become un-linked.

related to #33

-P as in Parents

The opposite of -p. this option additionally selects any annotations of tasks which are Parents of the < filter > tasks.
(upon which the < filter > tasks depend)

the subject says it all, the -s option should be an override to the rc default.

In an effort to expand the capabilities of task annotations by establishing a key: value pair convention, (as outlined in tw feature request #1088 - task "properties" or "casual attributes") and that has direct implications for taskopen.

I'm encouraging changes to task open that will extend the current behaviour to annotations that have a leading key: , so that annotations that start with

goals: ~/foo-objectives.txt
notes: Notes
devsite: www.tasktools.org

would behave nicely, but with shiny new semantic labels. I would also be desirable to be able use those new labels as in "taskopen 10 goals".

taskopen can't open more than one annotation at at time, but there's no reason it couldn't open multiples, one-after-another.

taskopen 10-15,72,74,276

could be considered a series of annotations to be opened, cuing up for iterations of taskopen < id n >

Similarly, after "taskopen" (optional parameters) lists all candidates, a comma-delimited series of choice#s, to be processed one-after-another, has some profound implications in workflow management, among other things.

-E as in Entry
(formerly -T as in Timestamp)

This option turns on the display of annotation "entry" timestamps, if any.

-x as in executable

The -x flag overrides the executable that is used to open an annotation.

Sometimes, you might want to open .html using your $EDITOR, and conversely, it's possible to open a .txt file with your $BROWSER, and sometimes, you want to use applications we'd never think of.

As an example, with this option, it might be possible to do things like
taskopen -x wc < id | filter > [ \label ]
which would (after selecting from multiple matches) do a word count of the selected annotation.

If the application used arguments, they would probably need to be quoted, as in
taskopen -x 'wc -l' +bugs \notes

-R as in Read-only

Like -r, which opens annotations raw text in your EDITOR, but -R opens/ displays it in read-only mode.

taskopen.pl -l
now lists openable tasks, and displays the command that would be used to open it.
This might be important, to understand what would happen if.. but it also might be considered noise.

if
taskopen -L
listed the annotations and the execution line that would be used, and
taskopen -l
just listed the annotations,
then users could choose their signal-to-noise ratio

-i as in info

Using "taskopen -x 'ls -l'". or "taskopen -x file" or "taskopen -x wc" reveals a lot about an annotation(s).
The -i option causes listings to include the information from all three.

Redundant /pathname/filename.ext output should be stripped, for clarity.

The specific commands used to generate the annotation info, could be listed in .taskopenrc to allow for customization.