This is an interesting problem. In my opinion an archive subcommand would be the best solution. I had already thought about such a command in the beginning but I dismissed it because I thought it would be enough to just start a new bartib file.

If the use case were to filter the activities to archive by dates and / or project, the archive subcommand gets interesting again. It could simply delete selected activities in the current bartib file and write them to the end of another bartib file.

What are your thoughts on that? Would that solve the problem of billed activities?

If the use case were to filter the activities to archive by dates and / or project, the archive subcommand gets interesting again. It could simply delete selected activities in the current bartib file and write them to the end of another bartib file.

That's what I had in mind with the Archive feature too.

I think one "bartib archive|unarchive N" where N is a number would work. Archive moves it from the the "live" to the "archive" file, "unarchive" the other way around. Moving would probably be just append it to the end of the other file?

Then a global "--archive|-a" flag to toggle the "report" and "list" to use either the archive file or the live file could be added so that we can check which is in archive.

Would that solve the problem of billed activities?

It would solve it, because I could "abuse" the archive as a flag to say "archived == billed".

I think the archive command should accept the same parameters as report for filtering the activities. The file to which the activities should be appended could be provided either by an -af|--archive-file option or by an environment variable BARTIB_ARCHIVE_FILE. If an archive file name of - is given the command could just print the activities to stdout. As an addition, one could consider a --dry-run option that would not delete the activities but print them to stdout only.

I am not sure what the N parameter you proposed is supposed to do? Are you suggesting it should function like the n parameter in bartib last?

I like the idea of a global --archive|-a flag which would use the BARTIB_ARCHIVE_FILE as the source for all the other operations.

One thing to consider during implementation is to ensure no data is lost during the move. Therefore, the activities should be appended to the archive, before they are removed from the source file. Thus, if writing the archive leads to an error we can still stop the operation.

I am not sure what the N parameter you proposed is supposed to do? Are you suggesting it should function like the n parameter in bartib last?

My idea was to keep it simple, by (re)using the continue idea. N is the task listed with last. N being some sort of ID.
Then, if someone wants to archive a large list, they can use a tool (or special bartib flag) to generate the list of IDS and pipe that into archive.

In my case, something like the following would work. The sed/cut stuff could be dropped if I could control the output of bartib a bit more.

ids=$(bartib last -n100 | grep "myproject" | sed -e "s/\[//" -e "s/\]//" | cut  -c 1-3)
for id in $ids; do
    bartib archive $id
 done

I -personally- prefer such an approach, provided the output is somewhat stable and parseable. So, in case of bartib, I'd like last or list to be able to add the numbers/ids and get them out of there easily without sed/cut.

The approach allows for much more freedom: I can even pipe it to my text editor, or via a spreadsheet. But I can always just use simple grep, sed, and a loop to control what I want archived. It also offers a good way to first review what's being archived.

I do think your request to follow the project and list filtering mechanism is neat too, though. Especially because all that is in place already, and could -at least in theory- easily be used to create filters for what to archive.

Please excuse my late reply; Christmas was a busy time.

I am not sure if utilizing the mechanisms from bartib last would be the best option if you are looking for a consistent output. With last, the ids in the output would change every time you make changes in the bartib file. Furthermore, at least for last, the ids reference recently used combinations of projects and descriptions, not distinct activities.

Regarding your use case, I think it could be perfectly feasible and reasonable to skip an archive command and just use GNU standard tools directly with the bartib file.

For now I went with a scheme that matches what I use in todo.txt. "key:value" pairs in the description.
This particular use-case, I can then solve by adding "billed_on:yyyy-mm-dd" to items that are billed.

It is not the same as archiving at all, but works for my case.

FWIW, I've made a bash and awk script that allows me to batch-append such strings to the description.

#!/bin/bash

# Assigning command line arguments to variables
startDate=$1
endDate=$2
projectCode=$3
appendString=$4
filePath=$5

# Using awk to process the file with an additional project code filter
awk -v startDate="$startDate" -v endDate="$endDate" -v projectCode="$projectCode" -v appendString="$appendString" '
BEGIN {
    # Convert dates to timestamps for easier comparison
    startTimestamp = mktime(gensub(/-/, " ", "g", startDate) " 00 00 00")
    endTimestamp = mktime(gensub(/-/, " ", "g", endDate) " 23 59 59")
}

{
    # Extract the start date and time of the entry
    entryDate = substr($1, 1, 10)
    entryTime = substr($2, 1, 5)
    # Convert date and time to the format "YYYY MM DD HH MM"
    split(entryDate, dateParts, "-")
    split(entryTime, timeParts, ":")
    formattedEntryStart = dateParts[1] " " dateParts[2] " " dateParts[3] " " timeParts[1] " " timeParts[2] " 00"
    # Convert the formatted date and time to a timestamp
    entryStartTimestamp = mktime(formattedEntryStart)

    # Check if the line contains the project code
    if ($0 ~ projectCode && entryStartTimestamp >= startTimestamp && entryStartTimestamp <= endTimestamp) {
      print $0, appendString  # Append the string if within the date range and matches project code
    } else {
      print $0  # Otherwise, print the line as is
    }
}' $filePath

The batch-appending (or batch replacing) of descriptions, might be a nice feature to have in bartib, rather than the unreadable mess that awk uses.
Another two nice addition to bartib might be to support "key:value" pairs. First, in list and report, it could get highlighted. And second, as filter for list and report. I suspect that a generic "substring" filter for descriptions would suffice. like --description-contains="status:to-be-discussed"

Anyway. Hope this already helps someone.

I like the idea as described in #33 (comment)