unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Colin Baxter <m43cap@yandex.com>
Cc: 50216@debbugs.gnu.org
Subject: bug#50216: 27.2; timeclock gives incorrect time in mode-line
Date: Fri, 27 Aug 2021 03:01:13 +0200	[thread overview]
Message-ID: <877dg7u2ee.fsf@gnus.org> (raw)
In-Reply-To: <874kbcvx5f.fsf@yandex.com> (Colin Baxter's message of "Thu, 26 Aug 2021 20:11:40 +0100")

Colin Baxter <m43cap@yandex.com> writes:

> B. Repeat the process.
>
> 1. timeclock log file present
> 2. emacs -Q
> 3. In Scratch buffer, evaluate
>    (display-time)
>    (timeclock-mode-line-display 1)
>    (setq timeclock-workday (* 12 60 60))
> 4. mode-line reads [7:58]
> 5. Mx timeclock-in <RET>
> 6. mode-line reads <7:57>
> 7. Wrote /home/redknight/.emacs.d/timelog
> 8. Wait a minute or two.
> 9. M-x timeclock-out <RET>
> 10. mode-line reads [7:55]
> 11. Wrote /home/redknight/.emacs.d/timelog
> 12. Close emacs
>
> Emacs incorrectly counts down workday, starting form the default value of 8 hours even though it was set to 12 hours.

Thanks for the detailed recipes.  I tried this in Emacs 28, and I can
reproduce the problem.  However, I'm seeing exactly the same behaviour
in Emacs 27.2 (and earlier), and I think you said over on emacs-devel
that this used to work there?

> E. Repeat process but change the lisp order
>
> 1. No timeclock log file
> 2. emacs -Q
> 3. In Scratch buffer, evaluate
>    (setq timeclock-workday (* 12 60 60))
>    (timeclock-mode-line-display 1)
>    Message: "Activate ‘display-time-mode’ or turn off ‘timeclock-use-display-time’ to see timeclock information"
> 4. M-x timeclock-in <RET>
> 5. mode-line reads [11:56]
> 6. Wait a minute or two.
> 7. M-x timeclock-out <RET>
> 8. mode-line reads [11:54]
> 9. Wrote /home/redknight/.emacs.d/timelog
> 10. Close emacs.
>
> Emacs again gives the correct workday even when the mode-line display
> occurs after the workday setting.
>
> The issue seem to be the presence or otherwise of (display-time).

I'm not so sure.  In all the cases where things work correctly (when
setting timeclock after `timeclock-mode-line-display'), there's no
timelog file.  So the issue seems to be: Setting workday after timeclock
+ having a log file?

I haven't really started debugging in, but the issue seems to be
`timeclock-find-discrep' using some data that was computed before
timeclock-workday was set...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





  reply	other threads:[~2021-08-27  1:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26 19:11 bug#50216: 27.2; timeclock gives incorrect time in mode-line Colin Baxter
2021-08-27  1:01 ` Lars Ingebrigtsen [this message]
2021-08-27  1:13   ` Lars Ingebrigtsen
2021-08-27  6:53     ` Colin Baxter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dg7u2ee.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=50216@debbugs.gnu.org \
    --cc=m43cap@yandex.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).