Specify custom commands for specific labels

[jschlatow]

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

[jschlatow]

This feature could be used to set up template tasks like a recurring "backup" task that can be expanded by taskopen, adding a whole chain of tasks, as soon as it pops up.

[linuxcaffe]

I know it sounds a bit fast-and-loose, but I really like the idea of tying label: to ../taskopen/scripts/label

the processing logic goes something like this;

if the annotation matches an existing rule or regex, open with that overridden by if the label matches executable in ../scripts/ (not extending to the rest of the $PATH) use that executable overridden by cmd specified at the CLI (like -x 'cmd', -i 'cmd') (which looks first to ../scripts/ and then full $PATH)

Keeping the label-executable in ../scripts/ makes the process easy to explain, transparent and extensible. Most importantly, with a few examples, users will be able to cook up their own label-executables. This approach will encourage users to mix-and-match special-purpose scripts, trade them with your friends! I think it would be the most flexible and require the least amount of developer (read: Johannes) support.

And no, I don't think that these scripts will cause any confusion or mishap, even if the labels are "cat:" and "rsync:", because the ../scripts/ will only EVER be in the path when called by taskopen.

To extend this to the max, I also think that the ../scripts/ directory could be the target for all "long-form" (double-dash) CLI options, like --create_file or --fix_notes_dupes. Those small executables should (imho) be found in ../scripts/, any script could be called as a long-form option, could be called as a label, or could be called directly with command options -x, or -i.

[jschlatow]

label-based actions will be available in taskopen 2.0