cmdline entry format improvements

[ederag]

There have been requests for a more permissive parser (#280, #423)
and different suggestions such as
activity name[@category[, description] [#tag1] ... [#tagn]]
in #438 (comment), or
name[@Category] [#tag1] [#tag2] ... [description]
in #438 (comment).

My current opinion is that there is no way to have a smart parser
using heuristics suitable for almost any input.
This is even more difficult as this parser should keep
the currently satisfied users experience intact.

Both the above suggestions do not keep compatibility.
The first one because it would not be possible to enter activity, description without category.
The second one because description would now be at the end.
Another issue with the second one is that it would prevent entering a description starting with #.

So the plan could be to make all separators configurable, such as ,, before description.
Regular expressions could be allowed.
The defaults would not change, so most people would not even notice.

[mwilck]

The second one because description would now be at the end.

Not so bad because the current format has never been thoroughly described :-) Also, the description parsing after comma doesn't seem to work at all in hamster 2.2.2, so I don't see a regression there.

We could also define the format like this:

name[@Category] [description and tags]

where "description and tags" would be just free-form input from which hamster would pick all #words prefixed with #hash as #tags. That would include tags at the beginning, at the end, or actually anywhere after the first word.

Thus:

8:00 - 9:30 #boss@meeting In this meeting I asked for higher #salary and more #days_off

would define an activity "#boss" in category "meeting" with description "In this meeting I asked for higher salary and more days_off" and tags "salary" and "days_off".

This should be parseable just fine.

In general, I'd recommend against making this configurable. This is GNOME - avoid possibly confusing configuration options.

[GeraldJansen]

A nitpick, but how about #boss, I'm asking for higher #salary?
It's simpler if there is a rule that an @category is mandatory if you want to add tags and/or description, hence:
activity name[@category[, description] [#tag1 #tag2 ...]]

I suggest choosing something that is similar to past practice (but not necessarily 100% compatible), convenient for entry and simple to define and parse. Define the behaviour in a wiki page as the standard, then stick to it. It will be impossible to please everyone.

I am also not in favor of the further complexity of configurable separators.

[ederag]

I am also not in favor of the further complexity of configurable separators.

OK, we'll discuss that after v3.0.
But my proposition would simplify a lot reasoning about the parser, on the contrary.

And description without category does not work for command line indeed (surprise),
but it should for consistency, and it works from the gui.

[mwilck]

#boss, I'm asking for higher #salary

activity: "#boss", category: None, description "I'm asking for higher salary", tags: "salary".
Where's the problem?

[mwilck]

@GeraldJansen, did you mean this?

#boss I'm asking for higher #salary
#boss, I'm asking for higher #salary

I would treat these two as equivalent (or IOW, the comma as optional). Someone will complain that it's impossible to enter activities that end with ",", but hey, forget about it.

[GeraldJansen]

@mwilck My main point is that current usage is not well defined and my example could mean different things depending on the rules. Even the rule activity name[@Category][, description] [#tag1] [#tag2] ... doesn't clarify my example if spaces, '#' and ',' are allowed in the activity name. Currently you have to find out by trial and error or try to read the code, which is a bit complex by the way. I guess it would be better to document what the parsing should do first then implement that. Beyond that I don't really have much interest because I don't use either tags or descriptions.

@ederag Verbatim input in separate input fields doesn't really solve this issue because later editing from the cmdline would still be problematic, as would trying to achieve the same input with the CLI. Anyway, agree to v3.1+.

Just for the record, here's what the Gnome extension readme currently says:

'activity@category, description #tag1 #tag2', where the comma is mandatory when adding a description and/or tag(s).

[ederag]

Verbatim input in separate input fields doesn't really solve this issue

Obviously. Not at all. What gave the impression otherwise ?

[GeraldJansen]

Obviously a wrong impression. Comment cancelled.

[mwilck]

doesn't clarify my example if spaces, '#' and ',' are allowed in the activity name

Spaces in the activity name? Excuse me, I'm an old-fashioned command line guy, this would never have occurred to me. All my propositions are based on the assumption that spaces are not allowed in either activity, tag, or category names. Without that, hell is open.

If we want to be anything like consistent, we must either forbid spaces, or forbid , and #. (I, personally, would be fine with quoting of some sort, e.g. #weird\ activity or "strange activity" - but chances are that some users would dislike that, too).

To reiterate an example I've been using before - Twitter allows no spaces in hash tags. So forbidding them should be a rule that even total command-line haters should be able to grasp.

[GeraldJansen]

I use multi-word activity names with spaces all the time and they have been a normal part of Hamster forever. Concerning requiring quotation for spaces in activity names, NO thanks!

[mwilck]

Ok, that clarifies it. That means, of course, that indeed # and , must keep their special meaning.

[mwilck]

Just to make sure I understand right, @GeraldJansen, you would parse the example

#boss I'm asking for higher #salary

As just an activity named "#boss I'm asking for higher #salary", no description, no tags?

[GeraldJansen]

Yes. An @category would be required before any description or tags. Dates and times would be parsed and removed from the front, then anything up to @ would be the activity name. I assume that people that use tags and descriptions also usually use categories, so this would not be a burden.

[ederag]

I assume that people that use tags and descriptions also usually use categories

Is it the case ?

Some users might like to use tags only,
as a mean to classify activities (pretty sure I read about that use case somewhere).
This does not work yet
("Unsorted" never worked correctly, even in v1, and I understood why yesterday),
but the intention was already there in the database code, and it will be possible in the near future.
It is much lighter to read and enter activity #tag1 #tag2 than activity@Unsorted #tag1 #tag2.

[GeraldJansen]

Okay, my suggestion was just that, a suggestion. You and others may have better solutions.

[ederag]

You and others may have better solutions.

@GeraldJansen Maybe this time, we'll see.
Yet thanks for the discussion, it helps a lot, to foster educated choices.
Actually the solution I proposed was grown out of your propositions,
so please keep on, it's important for this project !

[GeraldJansen]

@ederag Actually I haven't yet understood your proposal. With the current spec in wiki/Entering-activities, i.e. activity name[@category][, description] [#tag1] ... [#tagn] my example above would not be clear if ',', '#' and spaces are allowed in the activity name and there is no @category.

[ederag]

Indeed, it looks like a special separator will be required before tags too,
to allow for comma inside activity.
For instance a double comma again, or anything that is never typed elsewhere by the user.
Tags are searched from the end, until this separator is found,
or the parsed tag does not begin with #, or the resulting activity would be empty
(meaning the last found "tag" is actually the activity).
Or something along these lines.
We'll see after v3.0. The first post was essentially a mean to move the discussion away from #438.

[mwilck]

@GeraldJansen, does whitespace have to be supported in tag and category names, too?

[GeraldJansen]

@mwilck IMO there should not be spaces in categories or tags, but I am not sure about the behaviour of the current parser. Perhaps @ederag can clarify.

My own categories have the form "client/project" and I then use hamster export tsv and my own python script to create billing reports by client and project. Thus, for my personal use case I rely on the special character "/" embedded in categories. Who knows what other personal use cases have developed over the years.

[mwilck]

I tried the code from #461. Spaces in category work, but hell breaks loose if you try spaces in tag names. Basically, doing that will cause no tags to be recognized any more, and the tag string to be added to the "description" field.

[GeraldJansen]

You're in the territory of "undefined behaviour" ;-)

[mwilck]

The current code is what "determines" the behavior. But you're right, it's undocumented and it has never been thoroughly defined.

[mwilck]

@ederag,

Indeed, it looks like a special separator will be required before tags too,
to allow for comma inside activity.

Is it really worth all this effort and complexity to allow commas in activity names? Why don't you just close #280? We don't want our users to have to learn and memorize complex syntax rules for entering certain characters. The rules have to be simple, and "comma is forbidden" is simple, even if some don't like it.

[GeraldJansen]

Related issue: #285.

[ederag]

Two additional constraints:

need to allow @ in the middle of tags

in #476 (review).

Looking at the Input help page (eg. here), it seems that "#tag with spaces" is explicitly mentioned.

in #476 (comment)

In general, I'd recommend against making this configurable.

OK, I have an experimental parser that does the job with fixed separators,
and fully compatible with existing syntax [edit: 9cce2d7].
Less pretty and simple than with configurable separators though.
To be polished and pushed soon.

[ederag]

Proposition in PR #482.