taskwarrior
taskwarrior copied to clipboard
GothenburgBitFactory
Extend the tag specification to allow dashes
To report a bug...
The software currently can't handle defined filters or contexts where a tag is formed such as "#This" the command dumps everything past the # even if it's surrounded in quotes, or has a prepending backslash.
- What command(s) did you run? task context list task
Running this bare command works.: task +#foo
The problem only seems to happen when the tag is defined in the rc file.
For me it is something similar, I want to use the - cause it is combined word. In task 1 edit I can set it without a problem, but with task 1 modify +foo-bar it just sets the description to +foo-bar.
Both of these cases don't go through parser correctly, because tags are currently defined as alphanumeric single words. In particular tags cannot contain operators (like -) or whitespace characters.
Are these restrictions causing a lot of pain on the user end? I'd like to keep a balance here between usability and code complexity.
@tbabej I understand your concerns.
I would not consider allowing the # cause in web these are most of the time just the identifier in a text, which is not required here. Especially a whitespace I would not want to allow, this would be to complex, not even in parsing also in the ui.
The balance for me would be at least allow some limited special chars like - or _ to make combined words.
And yes, not to create some kind of combined words is a pain. I use the tags in combination with a project as some kind of areas inside a project, and these areas are more than just a single word.
also, for certain special characters like -, we're allowed to "add" the task with those tags but thereafter those tags becomes impossible to refer to in a filter.
task add +black-friday "buy MORE stuff"
# Created task xxx
# goes through without problems
task +black-friday list
Error: Cannot subtract from a Boolean value
tldr : if those characters aren't allowed, we should probably also not permit the creation of tags, with such special characters?
@kaushikgopal On the recent releases, this does not create a tag, but puts the +black-friday string into a description.
[[email protected] ~]$ task add test +black-friday
Created task 1.
[[email protected] ~]$ task 1 info
Name Value
ID 1
Description test +black-friday
Status Pending
Entered 2021-09-28 17:25:42 (4s)
Last modified 2021-09-28 17:25:42 (4s)
Virtual tags LATEST PENDING READY UNBLOCKED
UUID b91b5e23-e16b-42f1-9566-8c952929e81d
Urgency 0
which, I guess, you could claim is even more un-intuitive :sweat_smile: but technically it does not accept it as a tag.
huh, that's interesting @tbabej ; do you think that's because I explicitly use quotes for my description, so it "helps" the parser pass through the tag?
I'm on tw 2.5.3 stable and the following command continues to add the tag:
task add +black-friday "test buy stuff"
my own comment shows that, that's not true. it doesn't in fact add a tag but adds it in the description as you rightly pointed out. I was probably on an older version.
sorry about the noise. 🤦
While we're parsing tags with symbols, I'd like to submit a couple of things, in hopes of having them correctly handled. I don't want to increase code complexity, but I do think there's benefit in supporting tags some leading symbols;
+@home, has always been supported, works fine, no problem.
I use this to indicate a window for scheduling other home context tasks.
+\$212.89 (with the escape on entry) works ok, but not with filters as in tag.has:$
Much preferred to putting a related dollar amount in the description, annotation or UDA (stays clearly visible)
+#457 works fine, and can be filtered by `tag.has:#'
Useful when attaching an arbitrary # to a task.
I also agree that supporting dashes and underscores would be good. Thanks :)
For that matter why not arbitrary characters. I can think of a bunch of single-char punctuation I wouldn't mind having as tags, like !, or even unicode symbols. But _ and - would be a minimum.
Timewarrior allows tags like !this is a test_->
or even unicode symbols
For what it's worth, unicode symbols work just fine as of 2.6.0 (and perhaps even earlier):
[[email protected] ~]$ task add test +čoo🚀
Created task 3.
[[email protected] ~]$ task 3
No command specified - assuming 'information'.
Name Value
ID 3
Description test
Status Pending
Entered 2021-10-11 02:21:44 (5s)
Last modified 2021-10-11 02:21:44 (5s)
Tags čoo🚀
Virtual tags LATEST ORPHAN PENDING READY TAGGED UNBLOCKED
UUID 5697732a-ecd8-4006-be3f-397789a4657d
Urgency 0.8
tags 0.8 * 1 = 0.8
------
0.8
Filter: ( ( ( id == 3 ) ) )
[[email protected] ~]$ task +čoo🚀
[task next ( +čoo🚀 )]
ID Age Tag Description Urg
3 31s čoo🚀 test 0.8
1 task
Filter: ( status = pending and tags _notag_ WAITING and limit:page ) and ( tags _hastag_ čoo🚀 )
Also underscores work on 2.6.0:
[[email protected] ~]$ task add +test_something what
Created task 5.
[[email protected] ~]$ task 5 info
Name Value
ID 5
Description what
Status Pending
Entered 2021-10-11 02:26:46 (3s)
Last modified 2021-10-11 02:26:46 (3s)
Tags test_something
Virtual tags LATEST ORPHAN PENDING READY TAGGED UNBLOCKED
UUID 3c2ca9f1-0b12-4c07-8f41-cbd6e1b2d7c5
Urgency 0.8
tags 0.8 * 1 = 0.8
------
0.8
Filter: ( ( ( id == 5 ) ) )
[[email protected] ~]$ task +test_something
[task next ( +test_something )]
ID Age Tag Description Urg
5 17s test_something what 0.8
Edit: Also on 2.5.1 and 2.5.3, looks like underscores simply were never a problem. It's just dashes as far as I can tell.
Unfortunately dashes are probably the most common non-alphabetical character people attempt to use, if I had to guess :sweat_smile:
I just realized we have kind of hijacked this bug report, whose original theme could be summarized as "there is no way to escape comment (#) symbol in the taskrc file". I will spin that out into a separate issue, as the discussion here has been rather valuable.
It might make sense to allow any timewarrior-allowed tags. Some day these tools could have better integration. Not sure if that's possible with the parser. It seems like it could be assumed that any CLI arg that started with + until end of arg (including whitespace) was the full tag, without any interpretation.
Some day these tools could have better integration
Agreed, I'm also thinking recently that bringing the two together in terms of UX should be a good long term goal! While in general I think that might mean walking back from some experimental parts of timewarrior, in this particular case I agree with your observation about how tags could work :slightly_smiling_face:
An example where - might be significant: I'm using the bugwarrior jira integration along with jira.import_sprints_as_tags = True, and our sprints all have RFC3339 dates (e.g. 2022-05-10) in their names. I can somewhat control jira labels to make sure they don't use -s, but sprint names would be difficult for me to convince others to change!
I think the tl;dr is sometimes tag names might not be controllable by the end user! I'll see if there's any hooks I can use to convert them to underscores in the meantime, but I just wanted to provide an example where I'm not choosing -.
[EDIT] I was able to use hooks to convert - to _, BUT that made bugwarrior see a difference every invocation, causing lots and lots of churn (to be fair, I didn't notice until my undo history was ~20G). This isn't a great solution for me going forward to continue with the hook based approach
Underscores are not working for UDAs. If I wanted to create an UDA like that
uda.day_urg.type=numeric
it will get me into troubles later on.
task 1 modify day_urg:1 will just change the description to "1"
Add another vote for allowing a - in a tag. I use host names for tags to sort tasks for different hosts. A few hostnames contain dashes , thus preventing me from adding a tag for that host. In some cases I have resorted to renaming the hosts altogether. I have other situations where dashes would be useful too but this is the current struggle that brought me to this issue page.
