Syntax for continuing a specific entry

[Tim Weber]

Currently, 1234^ is defined as "at 12:34, I've continued work on the previous entry". But what if you want to continue to work on the one before that? Example:

1234  implement CLI parser
1245  customer called, discussed some open questions
1320.  # bathroom break

Now it's 13:25 and I want to continue work on "implement CLI parser". My only way right now is to copy the line (with a different timestamp of course).

First question is: How (i.e. by what) do we want to refer to a previous entry? My suggestion would be to allow these three options:

• By file position relative to the current entry, i.e. "3 entries before this one". A Git-commit-like syntax comes to mind: 1325^^^. This starts to get complicated at about 5 consecutive caret characters though. ;) Like Git, we could also support 1325^3, meaning the same thing.
• By timestamp, i.e. "the entry that started at 12:34". I'd love to have a syntax like 1325^1234 for this, but we need to take care to not create ambiguity with the 1325^3 syntax from above. I'd say, let's interpret one to three digits after the caret as relative position, four digits or more as timestamp.
• By string content, i.e. "the most recent entry that contains this substring". An example would be 1325^?parser. I've selected the question mark as a prefix for a reason here. First, it's easy to memorize, because less, vi etc. use ? as the command to search backwards. Second, not using any prefix at all (like 1325^parser) would prevent us from adding more possible ways to search in the future.

I have some open questions.

• Should ^? match case-insensitively? I I'd say no. It complicates the matching (for non-ASCII characters at least), and you'll be most likely able to see the line you're referring to anyway.
• Should ^? be able to match anything in the description text, even hashtags and billable flags? I think yes, simply match the text as it is in the file, not any parsed content. This also makes it easier for editor plugins etc. to know which line you're referring to.
• It's allowed to provide seconds in timestamps. Should ^1234 match a previous timestamp of 123456? What about 123400? Should ^123400 match 1234? I'd say: ^1234 should match 1234, 123400 and 123456, and ^123400 should match 1234, but not 123456. In other words: Match according to the precision provided in the search expression.
• Should these expressions look back multiple days trying to find a match? Should there be a limit to that? I'd suggest no limit, although this means that an implementation will have to keep the complete file in RAM. Files will not be that large, and if it starts to become a problem, you can always split them up.

[Roland Hieber]

I like the ^ and I immediately thought of Git syntax too :) I think 1234^^^ is the most number of ^s I would use, and then rather use 1325^1234 instead of the ^n syntax, because it would need counting lines, and I usually don't like to count lines. So these two syntaxes would have the most value for me.

^? should match case-insensitively (less typing... :-)), and also matching substrings seems like a good idea.

For the other precision question, I don't have a strong feeling... I would tend to ^1234 matching the last entry beginning with 1234, so even 123456 would be matched, but I don't have a strong logical argument to support that ^^

[Tim Weber]

Thanks for your input! I had started to write a reply, but I've noticed that it starts to get chaotic because we're basically discussing three different features in a single issue. I'll split this up into individual ones and comment there.

[Tim Weber]

Okay, this has been split into three separate tickets. Let's continue the discussion there.