tasks don't properly update when chronometrist.sexp is changed outside emacs #3

New Issue

2021-01-29T11:47:27Z

wu-lee commented

2021-01-29 11:47:27 +00:00

(Migrated from github.com)

How to reproduce:

start with some tasks in your chronometrist.sexp file
move it aside for use later
restart emacs
restart chronometrist
add some tasks
move the original file back
there is a pop-up dialog, which says something like "the chronometrist.sexp file has changed on disk. reload?"
answer "yes"
open the *Chronometrist* buffer and hit g

What I'd expect is for the tasks to update to the content of the new sexp file. They don't - the existing task list remains, and none of the tasks in the sexp file are listed, even after adding new tasks.

If I add a new task with the name of an unlisted but existing task from the new file, it appears in the list, but the time from previous entries doesn't seem to be included.

Old tasks with no entries in the file never disappear. (I'd expect them to be removed if they are no longer present)

And sometimes, I seem to be unable to add new tasks - they don't go into the list. However, this is hard to reproduce reliably, I don't know what triggers it. I have seen it several times, however.

I should also mention:

This may not be advisable, but I am using nextcloud to sychronise my chronometrist.sexp file between machines, so sometimes this means the file updates outside the context of emacs
The file ~/.emacs.d/chronometrist.sexp is a symbolic link to that file

How to reproduce: - start with some tasks in your `chronometrist.sexp` file - move it aside for use later - restart emacs - restart chronometrist - add some tasks - move the original file back - there is a pop-up dialog, which says something like "the chronometrist.sexp file has changed on disk. reload?" - answer "yes" - open the `*Chronometrist*` buffer and hit `g` What I'd expect is for the tasks to update to the content of the new sexp file. They don't - the existing task list remains, and none of the tasks in the sexp file are listed, even after adding new tasks. If I add a new task with the name of an unlisted but existing task from the new file, it appears in the list, but the time from previous entries doesn't seem to be included. Old tasks with no entries in the file never disappear. (I'd expect them to be removed if they are no longer present) And sometimes, I seem to be unable to add new tasks - they don't go into the list. However, this is hard to reproduce reliably, I don't know what triggers it. I have seen it several times, however. I should also mention: - This may not be advisable, but I am using nextcloud to sychronise my `chronometrist.sexp` file between machines, so sometimes this means the file updates outside the context of emacs - The file ~/.emacs.d/chronometrist.sexp is a symbolic link to that file

wu-lee commented

2021-02-01 19:25:04 +00:00

(Migrated from github.com)

As a work-around, is there any way to reset the state of chronometrist, without needing to restart emacs? Just closing all the buffers doesn't seem to do the job.

contrapunctus-1 commented

2021-02-02 17:21:33 +00:00

(Migrated from github.com)

Thanks for the report. I was able to replicate it a few days ago, and am working on a fix. The workaround at the moment might be to M-: (chronometrist-events-populate) RET

Thanks for the report. I was able to replicate it a few days ago, and am working on a fix. The workaround at the moment might be to `M-: (chronometrist-events-populate) RET`

wu-lee commented

2021-02-02 22:57:59 +00:00

(Migrated from github.com)

Thanks for the report. I was able to replicate it a few days ago, and am working on a fix. The workaround at the moment might be to M-: (chronometrist-events-populate) RET

That doesn't quite work - I'm not sure why. It may need niling chronometrist--file-state as well, possibly more.

> Thanks for the report. I was able to replicate it a few days ago, and am working on a fix. The workaround at the moment might be to `M-: (chronometrist-events-populate) RET` That doesn't quite work - I'm not sure why. It may need `nil`ing `chronometrist--file-state` as well, possibly more.

contrapunctus-1 commented

2021-02-03 23:25:20 +00:00

(Migrated from github.com)

@wu-lee whew, debugging this one has been exhausting. I think I've managed to fix it in the dev branch, would you like to test it by installing it from source?

@wu-lee whew, debugging this one has been exhausting. I _think_ I've managed to fix it in the dev branch, would you like to test it by installing it from source?

👀 1

wu-lee commented

2021-02-04 14:07:11 +00:00

(Migrated from github.com)

Just installed...

I notice editing a task name in chronometrist.sexp doesn't seem to show up in the *Chronometrist* buffer, after hitting g as I think I should expect it to? But it does if I close emacs and re-open it.

[edit] Just to elaborate: I'm using commit 8be5eb1ccb by adding the elisp directory of a git checkout to load-path, and I've removed chronometrist from my melpa directory entirely.

Just installed... I notice editing a task name in chronometrist.sexp doesn't seem to show up in the `*Chronometrist*` buffer, after hitting `g` as I think I should expect it to? But it does if I close emacs and re-open it. [edit] Just to elaborate: I'm using commit 8be5eb1ccbc34c8024 by adding the elisp directory of a git checkout to `load-path`, and I've removed chronometrist from my melpa directory entirely.

contrapunctus-1 commented

2021-02-04 17:44:39 +00:00

(Migrated from github.com)

Thanks for testing the development version. Are you able to replicate the issue with the file being replaced?

I've actually done a lot of testing by modifying task names, of late, and it worked for me...what was your exact change? Was it to the last expression, or something else? Also, note that if you rename the file while Emacs is running, the file notify watch will be invalidated and changes to the file won't be noticed, at least until one kills the Chronometrist buffer (optionally creating the file again, if you want to use an existing file) and runs chronometrist again.

Thanks for testing the development version. Are you able to replicate the issue with the file being replaced? I've actually done a lot of testing by modifying task names, of late, and it worked for me...what was your exact change? Was it to the last expression, or something else? Also, note that if you rename the file while Emacs is running, the file notify watch will be invalidated and changes to the file won't be noticed, at least until one kills the Chronometrist buffer (optionally creating the file again, if you want to use an existing file) and runs `chronometrist` again.

wu-lee commented

2021-02-04 22:42:23 +00:00

(Migrated from github.com)

In this case, immediately after starting emacs and chronometrist, I just opened chronometrist.sexp using the l keybinding, edited the title of the second last entry, saved. Then I switched back to *Chronometrist*, and hit g. No file moving this time.

I'll see if I can find out more.

Thanks for your work on this.

In this case, immediately after starting emacs and chronometrist, I just opened `chronometrist.sexp` using the `l` keybinding, edited the title of the second last entry, saved. Then I switched back to `*Chronometrist*`, and hit `g`. No file moving this time. I'll see if I can find out more. Thanks for your work on this.

contrapunctus-1 commented

2021-02-05 11:50:18 +00:00

(Migrated from github.com)

Re: task list not being updated, there was a situation I apparently overlooked. Should be fixed on the latest commit to the dev branch. Waiting to hear whether the file replacement behaviour is any better than before 😀

wu-lee commented

2021-02-05 12:23:01 +00:00

(Migrated from github.com)

I did a git pull (to commit 018fcdd858) and restarted emacs - initially it didn't work because there was a malformed time string (my mistake, but the error is quite opaque unless you know how to get and inspect a stack trace)

I don't seem to be able to get the *Chronometrist* buffer to pick up chronometrist.sexp edits on a g or M-: (chronometrist-events-populate)

Also, adding new events to chronometrist.sexp outside emacs gets the "reload buffer" prompt, but the *Chronometrist* buffer doesn't seem to pick up the changes.

Avoiding the symlink to chronometrist.sexp by configuring the actual path with customize-mode doesn't seem to help.

Closing all chronometrist buffers and re-opening doesn't seem to help.

Possibly this could be an emacs version problem? I realise I should have stated my version up front:

GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian

... however, looking at the git commit history, I see you added a function chronometrist-reset-task-list. Trying this, what does seem to refresh the *Chronometrist* buffer is invoking M-: (chronometrist-reset-task-list) and then hitting g in the buffer.

I did a git pull (to commit 018fcdd85807693d) and restarted emacs - initially it didn't work because there was a malformed time string (my mistake, but the error is quite opaque unless you know how to get and inspect a stack trace) I don't seem to be able to get the `*Chronometrist*` buffer to pick up `chronometrist.sexp` edits on a `g` or `M-: (chronometrist-events-populate)` Also, adding new events to `chronometrist.sexp` outside emacs gets the "reload buffer" prompt, but the `*Chronometrist*` buffer doesn't seem to pick up the changes. Avoiding the symlink to `chronometrist.sexp` by configuring the actual path with `customize-mode` doesn't seem to help. Closing all chronometrist buffers and re-opening doesn't seem to help. Possibly this could be an emacs version problem? I realise I should have stated my version up front: > GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian ... however, looking at the git commit history, I see you added a function `chronometrist-reset-task-list`. Trying this, what does seem to refresh the `*Chronometrist*` buffer is invoking `M-: (chronometrist-reset-task-list)` and *then* hitting `g` in the buffer.

contrapunctus-1 commented

2021-02-06 04:45:08 +00:00

(Migrated from github.com)

I've made a TODO item for a function to check the contents of the file. (PRs welcome! 😀)

I'm quite puzzled how you're getting those, because I rely on that functionality every day 🤔 Did you test that with emacs -q? I'm running v26.1 from Debian Stable.

I tried echo "(:name \"Foo\" :start \"$(date -Is)\" :stop \"$(date -Is)\")" >> ~/.emacs.d/chronometrist.sexp and that worked (although I get the "Reread from disk?" prompt twice, for some reason, despite having auto-revert-mode enabled in the buffer.)

Also, do you by any chance byte compile things? You probably want to remove any .elc files for Chronometrist, for the purpose of debugging.

I've made a TODO item for a function to check the contents of the file. (PRs welcome! 😀) I'm quite puzzled how you're getting those, because I rely on that functionality every day 🤔 Did you test that with `emacs -q`? I'm running v26.1 from Debian Stable. I tried `echo "(:name \"Foo\" :start \"$(date -Is)\" :stop \"$(date -Is)\")" >> ~/.emacs.d/chronometrist.sexp` and that worked (although I get the "Reread from disk?" prompt twice, for some reason, despite having auto-revert-mode enabled in the buffer.) Also, do you by any chance byte compile things? You probably want to remove any .elc files for Chronometrist, for the purpose of debugging.

wu-lee commented

2021-02-08 10:06:29 +00:00

(Migrated from github.com)

The chronometrist code is not byte compiled when I run it from the git checkout.

I did try running with -q just now, but because of the missing dependencies it failed, and I have not yet ventured to find a way to load them without the melpa packaging system.

I have tried to debug the code but find it tricky, emacs debug/edebug isn't very familiar and the various 3rd party anaphoric/threading libraries even less so...

Could I ask what the intended behaviour of the g keybinding is? Should I infer that you don't intend it to pick up changes to the sexp file on disk, or that it should but that it works for you?

The chronometrist code is not byte compiled when I run it from the git checkout. I did try running with -q just now, but because of the missing dependencies it failed, and I have not yet ventured to find a way to load them without the melpa packaging system. I have tried to debug the code but find it tricky, emacs debug/edebug isn't very familiar and the various 3rd party anaphoric/threading libraries even less so... Could I ask what the intended behaviour of the `g` keybinding is? Should I infer that you don't intend it to pick up changes to the sexp file on disk, or that it should but that it works for you?

contrapunctus-1 commented

2021-02-09 18:13:47 +00:00

(Migrated from github.com)

You'll probably have to run something like emacs -q -L path/to/dash/dir/ ... --eval '(progn (require 'dash) ...)'; if you have Cask (and aren't afflicted with the TLS bug), run cask emacs -q --eval "(progn (require 'chronometrist) (chronometrist))".

There's a commented message call in chronometrist-refresh-file in chronometrist.el - you can uncommented and reevaluate that, to see what file change type it displays when you replace the Chronometrist file. I've had funny things happen when I edebug that function and replace the Chronometrist file, so I'm not sure if edebug will help...

The g key is having an existential crisis of sorts after the v0.6 release. 😅 I guess I could bind it to some kind of force-refresh command, if necessary.

As a nuclear option, you can see if downgrading to pre-v0.6 makes life better for you 🤔

You'll probably have to run something like `emacs -q -L path/to/dash/dir/ ... --eval '(progn (require 'dash) ...)'`; if you have Cask (and aren't afflicted with the TLS bug), run `cask emacs -q --eval "(progn (require 'chronometrist) (chronometrist))"`. There's a commented `message` call in `chronometrist-refresh-file` in chronometrist.el - you can uncommented and reevaluate that, to see what file change type it displays when you replace the Chronometrist file. I've had funny things happen when I edebug that function and replace the Chronometrist file, so I'm not sure if edebug will help... The g key is having an existential crisis of sorts after the v0.6 release. 😅 I guess I could bind it to some kind of force-refresh command, if necessary. As a nuclear option, you can see if downgrading to pre-v0.6 makes life better for you 🤔

This repo is archived. You cannot comment on issues.