Skip to content
This repository has been archived by the owner on May 11, 2021. It is now read-only.

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

Open
wu-lee opened this issue Jan 29, 2021 · 12 comments

Comments

@wu-lee
Copy link

wu-lee commented Jan 29, 2021

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
Copy link
Author

wu-lee commented Feb 1, 2021

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
Copy link
Owner

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
Copy link
Author

wu-lee commented Feb 2, 2021

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.

@contrapunctus-1
Copy link
Owner

@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
Copy link
Author

wu-lee commented Feb 4, 2021

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 8be5eb1 by adding the elisp directory of a git checkout to load-path, and I've removed chronometrist from my melpa directory entirely.

@contrapunctus-1
Copy link
Owner

contrapunctus-1 commented Feb 4, 2021

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
Copy link
Author

wu-lee commented Feb 4, 2021

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
Copy link
Owner

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
Copy link
Author

wu-lee commented Feb 5, 2021

I did a git pull (to commit 018fcdd) 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
Copy link
Owner

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
Copy link
Author

wu-lee commented Feb 8, 2021

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
Copy link
Owner

contrapunctus-1 commented Feb 9, 2021

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 🤔

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants