task names are truncated, splitting the task into a new task #2

New Issue

contrapunctus · 2020-12-21T13:47:25Z

wu-lee commented

2020-12-21 13:47:25 +00:00

(Migrated from github.com)

Just been trying chronometrist, overall I quite like its simplicity and the s-exp data. Thanks!

There is a niggle I have: when create a new task, if the name is too long, chronometrist records that name in the data file, and truncates it in the *Chronometrist* buffer. Ok... but if I pause and restart it, the new time period has the truncated name, and the *Chronometrist* buffer now has two tasks, with apparently the same name. They they look the same when truncated - but one is the original long name, the other is the truncated name. Further - from now on, only the new truncated name gets any time added to it.

So:

Is there a way to lengthen or remove the truncation length? (Can't see an option in customize-mode for that)
In any case, shouldn't the long name be preserved in the data?

Just been trying chronometrist, overall I quite like its simplicity and the s-exp data. Thanks! There is a niggle I have: when create a new task, if the name is too long, chronometrist records that name in the data file, and truncates it in the `*Chronometrist*` buffer. Ok... but if I pause and restart it, the new time period has the truncated name, and the `*Chronometrist*` buffer now has two tasks, with apparently the same name. They they look the same when truncated - but one is the original long name, the other is the truncated name. Further - from now on, only the new truncated name gets any time added to it. So: - Is there a way to lengthen or remove the truncation length? (Can't see an option in `customize-mode` for that) - In any case, shouldn't the long name be preserved in the data?

❤️ 1

contrapunctus-1 commented

2020-12-21 14:44:26 +00:00

(Migrated from github.com)

Oh, thank you for the appreciation, I feel quite elated to hear that 😀

Thanks also for the bug report. I'd never noticed this, as I always used rather short names. I'm able to reproduce it, and hopefully I'll be able to fix it soon.

Oh, thank you for the appreciation, I feel quite elated to hear that 😀 Thanks also for the bug report. I'd never noticed this, as I always used rather short names. I'm able to reproduce it, and hopefully I'll be able to fix it soon.

contrapunctus-1 commented

2020-12-22 15:11:11 +00:00

(Migrated from github.com)

Please have a look at v0.5.6, hopefully it fixes this. Since people are using longer task names than I am, I might make field widths customizable in a future release.

wu-lee commented

2021-01-18 16:47:33 +00:00

(Migrated from github.com)

Thanks, have installed and been using. I have been noticing bugs which may be related - task names were being truncated still, and wrongly - for example "sea-map directory panel #43" was truncated to just "sea".

However, I notice a release from 6th January 2021, so I've installed that and will check if this problem persists"

Thanks, have installed and been using. I have been noticing bugs which may be related - task names were being truncated still, and wrongly - for example "sea-map directory panel #43" was truncated to just "sea". However, I notice a release from 6th January 2021, so I've installed that and will check if this problem persists"

wu-lee commented

2021-01-18 17:09:58 +00:00

(Migrated from github.com)

Some trouble with the new version too - including a lock up when I add a task, which requires C-g to escape from. top shows emacs at 100% CPU. Not sure why that was, could have been a linefeed which accidentally got into the task name via copy-and-paste, or it could have been some problem with the chronometrist.sexp file. In any case, I needed to clear the .sexp file and start again.

This in turn had an issue with "Wrong type argument: stringp, nil" because of the empty .sexp file - I needed to add an entry manually, after which things seem to be ok.

I should mention, my .sexp is symlinked from ~/.emacs.d/chronometrist.sexp to another location. This used to work ok, but could be a factor nevertheless.

Some trouble with the new version too - including a lock up when I add a task, which requires C-g to escape from. `top` shows emacs at 100% CPU. Not sure why that was, could have been a linefeed which accidentally got into the task name via copy-and-paste, or it could have been some problem with the `chronometrist.sexp` file. In any case, I needed to clear the .sexp file and start again. This in turn had an issue with "Wrong type argument: stringp, nil" because of the empty .sexp file - I needed to add an entry manually, after which things seem to be ok. I should mention, my .sexp is symlinked from `~/.emacs.d/chronometrist.sexp` to another location. This used to work ok, but could be a factor nevertheless.

wu-lee commented

2021-01-18 17:19:17 +00:00

(Migrated from github.com)

Also: I find I can't add new tasks, even short ones like "test". There is an error:

chronometrist-plist-pp-buffer: Symbol’s function definition is void: json-plist-p

Enabling debug-on-error gets this stacktrace:

Debugger entered--Lisp error: (void-function json-plist-p)
  json-plist-p((:name "test" :start "2021-01-18T17:17:49+0000"))
  chronometrist-plist-pp-buffer()
  chronometrist-plist-pp-to-string((:name "test" :start "2021-01-18T17:17:49+0000"))
  chronometrist-plist-pp((:name "test" :start "2021-01-18T17:17:49+0000") #<buffer chronometrist.sexp>)
  chronometrist-sexp-new((:name "test" :start "2021-01-18T17:17:49+0000"))
  chronometrist-in("test")
  chronometrist-run-functions-and-clock-in("test")
  chronometrist-add-new-task-button(nil)
  chronometrist-add-new-task()
  funcall-interactively(chronometrist-add-new-task)
  call-interactively(chronometrist-add-new-task nil nil)
  command-execute(chronometrist-add-new-task)

Also: I find I can't add new tasks, even short ones like "test". There is an error: chronometrist-plist-pp-buffer: Symbol’s function definition is void: json-plist-p Enabling `debug-on-error` gets this stacktrace: ``` Debugger entered--Lisp error: (void-function json-plist-p) json-plist-p((:name "test" :start "2021-01-18T17:17:49+0000")) chronometrist-plist-pp-buffer() chronometrist-plist-pp-to-string((:name "test" :start "2021-01-18T17:17:49+0000")) chronometrist-plist-pp((:name "test" :start "2021-01-18T17:17:49+0000") #<buffer chronometrist.sexp>) chronometrist-sexp-new((:name "test" :start "2021-01-18T17:17:49+0000")) chronometrist-in("test") chronometrist-run-functions-and-clock-in("test") chronometrist-add-new-task-button(nil) chronometrist-add-new-task() funcall-interactively(chronometrist-add-new-task) call-interactively(chronometrist-add-new-task nil nil) command-execute(chronometrist-add-new-task) ```

contrapunctus-1 commented

2021-01-19 06:19:08 +00:00

(Migrated from github.com)

Grateful for any bug reports as always, @wu-lee ^^

Re: the json-plist-p error, a workaround might be to (require 'json). I'll remove this dependency as soon as I get time. EDIT - done, try v0.6.3.

Re: freezing and the empty file error, yikes what 😱 Please try to get a backtrace (using toggle-debug-on-quit for the former.)

Grateful for any bug reports as always, @wu-lee ^^ Re: the json-plist-p error, a workaround might be to `(require 'json)`. I'll remove this dependency as soon as I get time. EDIT - done, try v0.6.3. Re: freezing and the empty file error, yikes what 😱 Please try to get a backtrace (using `toggle-debug-on-quit` for the former.)

👍 1

wu-lee commented

2021-01-24 17:50:59 +00:00

(Migrated from github.com)

I've been using the version 20210119.753 from melpa for a few days. (list-packages doesn't seem to want to show me the version, but I think this is v0.6.3)

Some of the problems haven't re-appeared, but I do find the list of tasks doesn't seem to refresh properly with new tasks, so when when I add a new task I can't stop it without switching to a new task.

Here's how I can reproduce this.

Move away my chronometrist.sexp file
Start a fresh emacs instance.
M-x chronometrist
On prompt: "Welcome to Chronometrist! Hit RET to start a new task." hit return and type "task1". hit RETURN
Now hit "a" and type in "task2", hit RETURN

What I'd expect here is for the new task "tast2" to appear in the list. But it doesn't, only "task1" is present. Hitting "g" used to fix things like this but it does not.

(I did try debugging it with edebug, but I'm not really that familiar with elisp and edebug, yet alone elisp with dash, and I've given up trying to track down the problem for now.)

I've been using the version 20210119.753 from melpa for a few days. (`list-packages` doesn't seem to want to show me the version, but I think this is v0.6.3) Some of the problems haven't re-appeared, but I do find the list of tasks doesn't seem to refresh properly with new tasks, so when when I add a new task I can't stop it without switching to a new task. Here's how I can reproduce this. - Move away my `chronometrist.sexp` file - Start a fresh emacs instance. - M-x `chronometrist` - On prompt: "Welcome to Chronometrist! Hit RET to start a new task." hit return and type "task1". hit RETURN - Now hit "a" and type in "task2", hit RETURN What I'd expect here is for the new task "tast2" to appear in the list. But it doesn't, only "task1" is present. Hitting "g" used to fix things like this but it does not. (I did try debugging it with edebug, but I'm not really that familiar with elisp and edebug, yet alone elisp with dash, and I've given up trying to track down the problem for now.)

contrapunctus-1 commented

2021-01-27 16:02:00 +00:00

(Migrated from github.com)

I've pushed v0.6.4 which should fix this, thanks for the specific steps which helped me replicate the issue.

👍 1

wu-lee commented

2021-01-29 11:35:39 +00:00

(Migrated from github.com)

Thanks. I've been using this new release for a day or so - the reported problem is fixed, although I have still experienced problems with adding tasks, which doesn't happen immediately, and I can't yet reproduce this. I'll desist from adding new problems to this ticket however, and file new issues as appropriate.

contrapunctus closed this issue

2022-04-24 05:02:06 +00:00

This repo is archived. You cannot comment on issues.