From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Task Newsgroups: gmane.emacs.devel Subject: Re: Extending timeclock.el Date: Sat, 06 May 2023 12:47:24 -0300 Message-ID: <86wn1la21d.fsf@disroot.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19339"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 06 18:28:02 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pvKlO-0004lZ-8I for ged-emacs-devel@m.gmane-mx.org; Sat, 06 May 2023 18:28:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pvKkq-0006yn-5i; Sat, 06 May 2023 12:27:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvKEI-0007Wq-0s for emacs-devel@gnu.org; Sat, 06 May 2023 11:53:50 -0400 Original-Received: from knopi.disroot.org ([178.21.23.139]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvKEE-0003hD-K6; Sat, 06 May 2023 11:53:48 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id EEB264023C; Sat, 6 May 2023 17:53:44 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Original-Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGEOD3g9j0Hn; Sat, 6 May 2023 17:53:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1683388423; bh=TzMV3fV6ZjU1LKlCjUzVbhPVQAqbMFUel34YitKdYnk=; h=From:To:Cc:Subject:In-Reply-To:Date; b=BJpkvJRbF5lvLG38GHiNjnvKe5PH5ZdM1AdpLiaX5d6jTRt9a0acsdx4Z+k2057Bt dQcSLAOvBGVtR6jI1J+DhpTYiPI2G+dL9aJkqvkAqyem49cPz9orCY68UUbYpOMKvW MP6H7/9YSvjpS2/tRVq6kn6HIIF9I88XFmGTlXWJMhIrlC7Wpry5WR6lk3rXz8SYPT Sb5jF5cVptz/BgVTjt6RlXzzUow5s/pCxuYL57YtixxVawG8kEAsPFG0+42DyvWMOP qeMi3Yp4ghItXPzb5b8GHjeOOc1b5lTrtnoDrEEtBcUqBjWi2KItKc4dyfFmnmTDL4 Ol5MSTtNRSsBA== In-Reply-To: 83ild6gc54.fsf@gnu.org Received-SPF: pass client-ip=178.21.23.139; envelope-from=q01@disroot.org; helo=knopi.disroot.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 06 May 2023 12:27:26 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305917 Archived-At: Eli Zaretskii writes: > Why not simply add the code to timeclock.el itself? You can for now > fork it and develop it separately; later, we will merge the changes. That works, too. My thinking was that timeclock.el worked perfectly fine until now, and timeclock-modern.el would be a simple extension in order to support a different workflow. However, it also makes room for improvement in other areas of the package, so I'll look into that. > By "timelog format" do you mean the format of the log file > read/written by timeclock.el, or do you mean some other format, which > Emacs currently doesn't use? I mean the current format read and written by timeclock.el. > The codes are documented in the doc string of timeclock-log-data > (assuming it is up-to-date ;-). Yes, that's how I realized they exist. But as I'm not well familiarized with the package, they are still pretty cryptic from my POV. For instance: b Set the current time balance, or "time debt". Useful when archiving old log data, when a debt must be carried forward. The COMMENT here is the number of seconds of debt. I understand every word here, and yet I don't really get what time balance is or when to use it. Also, old log data can be archived? Of course, in this particular situation, I think it's pretty clear a line starting with a 'b' doesn't indicate a track, and that's everything the parser need to know in order to work. At least for now. > There's no "0" there that I could > see, but there is "O" (upper-case letter O). I hate my font so much :( > As for the "clock-out" issue: like I said, time trackers used for > tracking work activities do have both 'o' and 'O'. The former means > "end of workday", the latter means "this activity will never again > appear, because its project is 'finished'". The former can indeed be > represented as the start of "untracked" activity, but the latter must > be also explicitly supported, because a reasonably useful report or > statistics could deal with projects which were already completed. For > instance: how many projects were completed the last year? Or: what is > the average amount of time spent per project until it's completed? OK, I think that's clearer now. That kind of statistic was not possible at all in ETT, so I'll have to design it from scratch, but it sounds good. > If you find actions that are difficult to represent in the usage > pattern you envisioned for ETT, we can have two separate workflows > supported by timeclock: one workflow for which timeclock was > originally designed, where it tracks "work hours"; the other where it > tracks everything. We could have the type of the workflow described > in the COMMENT of the 'i' entry. Or we could ask the user up front to > specify which workflow is intended, and have that encoded in the > header line of the timelog file (if we think these two workflows are > mutually exclusive). I was thinking about something like that, too. Basically, timeclock-modern, as it is designed right now, should ideally make three main additions to stock timeclock: 1. A parser to retrieve information from the timelog file 2. Advanced statistic reports 3. A new optional workflow where it is able to track everything Point 1 must explicitly support the current state of things, as it would be useless otherwise. Point 2 also should support the default behaviour of timeclock, so all users can benefit from it; however, some things such as tags are not supported out-of-the-box as of now, while other things such as the 'b' or 'h' keywords don't make much sense for the new behaviour. So, statistic reports will depend on what workflow the user chooses. As for point 3, it is the most complex one because I haven't come to a clear solution of how to implement it properly yet. For now, I think a user option which redefines the behaviour of some commands such as timeclock-in and timeclock-out is the best path to follow. And the thing is, the new workflow will probably slightly modify the timelog format. Currently, my custom tm-clock-in (which would be the new 'timeclock-in' once the user opts-in into the new worflow) gets rid of the letter code altogether, somehow breaking backward compatibility. Maybe that's not a bad thing though, because if the user opted into the new workflow, they probably don't care about that. > I have only ever used timeclock in a very simple workflow, with a > single "project" into which I was clocking in and then clocking out > every day. So my timelog file is a series of 'i's and 'o's, something > that you can easily generate yourself. If specific issues are of > interest, please ask more specific questions. Yes, I have tested that kind of timelogs and everything has gone well. I was thinking on sligthly more complex files, maybe with 'O', 'h' and 'b' here or there. Maybe I'm exaggerating a little, but it feels wrong to not test it with real timelogs :) > Why "worse"? Can't we do this in a backward-compatible manner, like > based on user options? And if worse comes to worst, we can add a > whole new set of commands to support the "track everything" workflow > you had in mind for ETT. Now that I think about it, maybe modifying timeclock-in in order to support that workflow based on user options is a good idea. That way I don't have to support a separate tm-clock-in. That's also another argument in favour of forking timeclock instead of developing a separate file. I'll look into that. > John Wiegley, the original author is somewhat busy these days, but we > can add him to this discussion right away. Here, done. Thank you.