Extend the tag specification to allow dashes

[fullstopslash]

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.

[chapterjason]

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.

[tbabej]

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.

[chapterjason]

@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.

[kaushikgopal]

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?

[tbabej]

@kaushikgopal On the recent releases, this does not create a tag, but puts the +black-friday string into a description.

[warrior@tw-v2.5.3 ~]$ task add test +black-friday
Created task 1.
[warrior@tw-v2.5.3 ~]$ 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.

[kaushikgopal]

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"

[kaushikgopal]

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. 🤦

[tbabej]

No worries :slightly_smiling_face: it is definitely visually confusing!

[linuxcaffe]

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 :)

[smemsh]

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_->

[tbabej]

or even unicode symbols

For what it's worth, unicode symbols work just fine as of 2.6.0 (and perhaps even earlier):

[warrior@tw-2.6.0 ~]$ task add test +čoo🚀
Created task 3.
[warrior@tw-2.6.0 ~]$ 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 ) ) )
[warrior@tw-2.6.0 ~]$ 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🚀 )

[tbabej]

Also underscores work on 2.6.0:

[warrior@tw-2.6.0 ~]$ task add +test_something what
Created task 5.

[warrior@tw-2.6.0 ~]$ 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 ) ) )

[warrior@tw-2.6.0 ~]$ 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.

[tbabej]

Unfortunately dashes are probably the most common non-alphabetical character people attempt to use, if I had to guess :sweat_smile:

[tbabej]

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.

[smemsh]

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.

[tbabej]

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:

[travisby]

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

[kamillentee]

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"

[Archangel33]

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.