Long task names split into description

[benbarbour]

I made a task called "General (meetings, interviews, etc) @_Work", but whenever I try to log it (or change an existing entry to it) it gets split into:

Activity: General (meetings Description: interviews, etc) @_Work

which is definitely wrong.

Note: I used "@" insteal of just "@" to avoid tagging someone named Work_.

[benbarbour]

Nevermind, just noticed the feature where comma's purposefully delimit the description. Personally, I think the comma is too common to use for such a thing, maybe a semicolon would be better? I just replaced all the commas in my few tasks that use them with semicolons as a workaround.

[toupeira]

I suggest using slashes ;-)

I'm reluctant to change it to a semicolon because it will trip up users who've been using the comma deliberately to split the description. But we could make the parsing a bit smarter so it would for example ignore commas inside parentheses, like in your example.

[a-m-s]

It ought to be possible to detect that the activity or category name contains a comma, as long as you're not trying to invent a new one. It's just a matter of matching the text against the list, finding the longest match, and then parsing the remainder of the text for commas and tags.

I'm not sure if that wouldn't confuse some other user somewhere else? It's not hard to cook up some case that would be ambiguous (e.g. you have categories "work" and "work, play" and then you try "stuff@work, play with options"), but are they likely?

I'd imagine that there are similar problems with activities that contain '@' or '#' also.

[toupeira]

@a-m-s I don't think that's a good use case since it would require the user to add the activities / categories manually first. The more I think about the more I feel the existing behaviour makes perfect sense if you know about it, @benbarbour could have just written "General, meetings, interviews, etc" to move the latter part into the description (which I'd prefer, so it won't be displayed for example in the shell extension). It might be a good idea to support input in the form "activity (description)" as well though.

By the way, the relevant code is here in the hamster repository, and for once there are even tests ;-)

[a-m-s]

@toupeira I would say that if it works in the app, then it should work in the shell extension. Otherwise, I agree, keep it simple.

[toupeira]

As far as I can tell the shell extension doesn't do any additional parsing and just passes the string on to the DBus service, so any changes will apply to the desktop app, CLI, and all extensions.