org-clock-convenience
org-clock-convenience copied to clipboard
dfeich
Error: Not on a time range field position
I used to be able to adjust the clock times in agenda mode, until about a month ago.
Do you have some tips for troubleshooting why it would no longer think that is a time range field? I included a screen shot of the agenda view and where point is when I issue the timestamp up command.
If I turn on debug on entry into the function I get:
Debugger entered--returning value: nil #f(compiled-function () #<bytecode 0x1feb28dc2fc9>)()
- org-clock-convenience-get-fieldname(322 "^ +([^:]+): *(([ 012][0-9]):([0-5][0-9]))(?:-(([ 0..." (filename d1-time d1-hours d1-minutes d2-time d2-hours d2-minutes duration) (d1-time d2-time) "Error: not on a clocked time log line")
- org-clock-convenience-get-agenda-tr-fieldname(322)
- org-clock-convenience-goto-ts()
- org-clock-convenience-timestamp-change(1)
- #f(compiled-function (&optional arg) (interactive "p") #<bytecode 0x1feb4c3926dd>)(1)
- apply(#f(compiled-function (&optional arg) (interactive "p") #<bytecode 0x1feb4c3926dd>) 1)
- org-clock-convenience-timestamp-up(1) funcall-interactively(org-clock-convenience-timestamp-up 1) call-interactively(org-clock-convenience-timestamp-up nil nil) command-execute(org-clock-convenience-timestamp-up)
I'm not sure what that "322" value being detected is or really what other terms I can search for to find the change in emacs, org, etc that caused this to stop working for me.
For now my workaround is to hit enter on the agenda item and then adjust the time in the org file, but I miss out on the fill gap function.
Hi mbarton98,
I only am on my tablet right now, but based on your excellent bug report, I think I can already see what it is. The regexp I use to detect a time range in the agenda seems to expect 09:00 instead of 9:00. Maybe the formatting of time has changed, recently. I will fix it tomorrow, when I am back on my laptop.
On Mon, 15 Jun 2020, 22:49 mbarton98, [email protected] wrote:
I used to be able to adjust the clock times in agenda mode, until about a month ago.
Do you have some tips for troubleshooting why it would no longer think that is a time range field? I included a screen shot of the agenda view and where point is when I issue the timestamp up command.
[image: image] https://user-images.githubusercontent.com/34492162/84702406-6a3b6580-af0b-11ea-9787-0caa1bdbb3b8.png
If I turn on debug on entry into the function I get:
Debugger entered--returning value: nil #f(compiled-function () #<bytecode 0x1feb28dc2fc9>)()
- org-clock-convenience-get-fieldname(322 "^ +([^:]+): *(([ 012][0-9]):([0-5][0-9]))(?:-(([ 0..." (filename d1-time d1-hours d1-minutes d2-time d2-hours d2-minutes duration) (d1-time d2-time) "Error: not on a clocked time log line")
- org-clock-convenience-get-agenda-tr-fieldname(322)
- org-clock-convenience-goto-ts()
- org-clock-convenience-timestamp-change(1)
- #f(compiled-function (&optional arg) (interactive "p") #<bytecode 0x1feb4c3926dd>)(1)
- apply(#f(compiled-function (&optional arg) (interactive "p") #<bytecode 0x1feb4c3926dd>) 1)
- org-clock-convenience-timestamp-up(1) funcall-interactively(org-clock-convenience-timestamp-up 1) call-interactively(org-clock-convenience-timestamp-up nil nil) command-execute(org-clock-convenience-timestamp-up)
I'm not sure what that "322" value being detected is or really what other terms I can search for to find the change in emacs, org, etc that caused this to stop working for me.
For now my workaround is to hit enter on the agenda item and then adjust the time in the org file, but I miss out on the fill gap function.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dfeich/org-clock-convenience/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABG377Q7ZNXOXA7PJW2PNM3RW2CNHANCNFSM4N6WEI7Q .
FYI
It also happens when I try on the 10:05 entry a few lines below, so it might be more involved than just the leading zero. I tried at one point pasting the agenda line in a scratch buffer and applying the regex to it and it seemed to group just fine, but I had to change the way I was escaping the ()s. I tried to make some changes to the string in my local copy of the code and byte compile to make sure emacs loaded my changes, but I was not positive I was doing that right with my limited experience with emacs lisp.
My org-version is: Org mode version 9.3.7 (9.3.7-4-gba6ca7-elpaplus @ /Users/bartm002/.emacs.d/elpa/org-plus-contrib-20200615/)
Ok... I just had a look and the regexp seems fine. I manually copied the problematic line from your screenshot and tested.
The best way in Emacs to test these things is to invoke the regexp-builder. You can do this directly while you are in the buffer of interest (i.e. the agenda buffer). You will get a smaller window on the bottom where you can enter a regexp. In this case it is the contents of org-clock-convenience-clocked-agenda-re
"^ +\\([^:]+\\): *\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\(?:-\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\|\.*\\)? +Clocked: +\\(([0-9]+:[0-5][0-9])\\|(-)\\)"
Now all matching lines and subexpressions will be highlighted with colored overlays. C-c C-q exits the mode. You can have multiple expressions in the regexp builder on consecutive lines. It always uses the top one, but it is nice for experimenting with different ones to be able and use transpose-lines to make another candidate active.
The lines I see on your screenshot match... except if the space in front of the first digit (where your arrow points) is really a TAB or another non-space character. You can test that by positioning your cursor on top of it and then using M-x describe-char. I made a more flexible regexp. Can you try it out by going to the scratch buffer and setting the variable
(setq org-clock-convenience-clocked-agenda-re
"^ +\\([^:]+\\):[[:space:]]*\\(\\([ \t012][0-9]\\):\\([0-5][0-9]\\)\\)\\(?:-\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\|.*\\)?[[:space:]]+Clocked:[[:space:]]+\\(([0-9]+:[0-5][0-9])\\|(-)\\)")
If this makes your lines work again, then I will commit this change. You can also hot-fix it for now in the org-clock-convenience.el file, so that you need not wait for the new package.
Please give it a try and confirm that it works. If it does not work, can you please copy your agenda screen in Emacs and put it in a file that you attach to the issue.
I tried it and it gets the same error (read on though since it works when I delete the org-clock-convenience.elc and reload emacs). I included screenshots of the regexp builder for both and they both appear to match properly.
The new proposed re value:
The existing re value
I tried deleting the .emacs.d/elpa/org-clock-convenience-20200123.1029/org-clock-convenience.elc file so I could see more info in the debugger after restarting emacs. I forgot to reset the re value to the new one after restart for this debug capture. I could capture in a video stepping through, but is there a better way?
It now works when I use the new proposed re value! I relaunched emacs again and it did not work again until I set the re value to the proposed again. I byte compiled the el file to produce another elc file and relaunched emacs again. This time it was broke with even the new proposed re value.
I deleted the elc file and relaunched emacs and again it works with just the proposed re value.
I'm not sure why that is the case. I had a problem a few months back where packages would not work after updating from melpa until forcing a byte recompile of the .emacs.d directory.
Thanks so much for taking the time to look at this for me and sharing how to use regexp-builder too.
Since both - the old and the new - regexp match your agenda buffer lines, a potential TAB being the whitespace in front of your time cannot have been the problem. Your problems with the elc files point to some deeper issue.
You do not need to delete the .elc file if you want to test the code in the .el file against it. If you use evaluate-buffer while being in the .el buffer, it will redefine all the functions in the file. You also just can go into a function in the file or on a var and do an C-M-x on it (eval-defun). That will just redefine that function or variable.
A recompiling of the elc files is usually necessary when you switch to another Emacs version which is not completely binary compatible. E.g. when you switched to Emacs 27 you needed to do this. This can lead to strange effects.
Another source of error I frequently see, is a corrupted org installation. E.g. I prefer the org-plus-contrib package, but sometimes another package pulls in the plain org package as a dependency - sometimes the two versions even slightly differ in version. This also can lead to strange errors. One needs to remove one of the versions, and best even reinstall org or at least recompile all files. But your problem does not sound like this.
In your special case it even could be some strange bug of Emacs 27, if all else is ok and you did everything right. Because it seems that the compiled code behaves differently from the interpreted one. But it still is strange, since the regexp builder is using the same underlying matching mechanisms, is certainly using compiled code, and matches both...
Did you build the Emacs 27 yourself? Are you sure that the build dir was completely cleaned (e.g. if you built if from a git repo where you previously had compiled an earlier version)?
I use the emacs-27 branch to avoid being too cutting edge and getting 28. I only went to 27 because I was working with lsp-mode and it was recommended to move to 27 to get faster json support (at that time 27 was not released yet as a package).
It did take some effort to get all the supporting libraries needed to compile emacs and those were installed via home brew on the mac. So before I build emacs, I perform a brew update and brew upgrade to make sure those have been updated. After I Pull the changes for the repo, I use a TextExpander snippet to run: make clean && ./autogen.sh && ./configure && make && make install
I then run: nextstep/Emacs.app/Contents/MacOS/Emacs --debug-init
Check for any errors, before copying the new Emacs.app to the /Applications folder.
I was going through these hurdles since lsp-mode, jupyter-client, and org-babel are evolving along with changes to emacs.
I switched to emacs from a licensed sublime text editor last September, after seeing Mike Zamansky's Using Emacs videos along with Rainer König's org mode tutorials. I wished I had discovered emacs years before. I used to use OmniFocus as a task manager and had to find other software to take notes and track time. Now org mode handles that much better and that is where I came across the org-clock-convenience to adjust my logged time when I forget to clockout of a task during the day.
I will try testing the code some more with your suggestions, if for no other reason than to learn more about emacs.
FYI
Look at what happened to the re string after the byte-compile. The tab got expanded. In the lower window is the elc version and the large white space is a made up of a SPC followed by a TAB as shown by (describe-char).
Your building workflow looks mostly ok, but it could be that it misses to clean out the compiled lisp files from the previous version (the ones that come with the Emacs distribution itself). You should execute a make bootstrap to get everything clean. These are my org notes about the building:
** General build process
If there are problems with simple =make= building after an update,
one can run =make bootstrap= to get a clean building process. This will
also trigger an =autoreconf -f -i=, but also correctly remove all the old
emacs lisp byte-compiled files. Note that it will reuse the configure arguments
from a previous run, so it may be desirable to adapt the prefix beforehand.
In one instance, when I needed to downgrade for a test, I had to
remove aclocal.me, because it contained macros that only existed in
the newer version
: make bootstrap
It might be that the libpng from the anaconda installation is interfering with the build (q.v. [[http://emacs.stackexchange.com/questions/2551/installing-emacs-24-4-from-source-on-centos5-with-libpng12/2628#2628][my own answer]]
on stack exchange). Therefore, remove anaconda from the path when building.
: ./configure --prefix=/usr/local/emacs-25.2-rc1 --with-modules
** Rebuilding all the user's packages (ELPA and others)
For user package dir rebuild: Execute
#+begin_src elisp
(byte-recompile-directory package-user-dir nil 'force)
#+end_src
Do not forget other dependencies
- mu4e: Execute in build directory
: make clean-lisp; make; make install
What happened to the string after byte-compile in your last post seems to be ok to me. The escape sequence '\t' has been translated to the real character 'TAB'
I need to start looking at Emacs 27 as well. Especially in regard to what you mention about lsp-mode and jupyter. Yes... Emacs is really, really great. I have not seen another environment up to now that gives me the same productivity. I have been very active on the babel technology for many years, but had to postpone a few things last year. If you are interested, I have a collection of babel examples https://github.com/dfeich/org-babel-examples. I will have to refresh them a bit this year. The material from Zamansky and Koenig is really nice (also have a look at the older http://emacsrocks.com/ from Magnars) and I think such things do a lot for the community. There is also http://www.masteringemacs.org by Mickey Petersen and for lisp pearls of wisdom I really like http://nullprogram.com/ by Chris Wellons.
I'm currently preparing a course trying to teach Emacs and Org by using Org itself. It's still very fresh and I do not yet want to announce it, but you can have a first look at https://github.com/dfeich/emacs-course. I'm doing a first test with people of my work group to do a first round of improvements. There's a lot of material to cover.
FYI I replied to the last comment via email yesterday as I thought it was getting off topic from this issue. It occurred to me that it might have gone to a junk/spam folder since I have not written directly to you before. I can enter feedback into the emacs-course repo as an issue which is probably better then having it in a separate email.
Yes. I got it, thanks. I already corrected what you found and committed it. It's indeed best to put it as an issue or - like you did - as a direct code-comment (which generates an email to me. Github really has a very nice interface).
Back to the original issue: Did you have any luck with a complete recompile of the Emacs distro's lisp sources using a full boortstrap?
I tried the make bootstrap and removed the org-clock-convenience directory under elpa to force use-package to download from melpa. It fails to find the time range when the elc file is there. When I delete the elc file it works perfectly. If I go into dired and use S-b to byte compile then it breaks again until I remove that elc file.
Now I'm almost convinced that it must be a byte compilation problem in your Emacs, as strange as that seems. Because the interpreter seems to give you consistently different behavior from the byte compiled code execution concerning the regexp match.
This should actually be easy to test. A minimal example triggering the problem should be the following:
(let ((test-re "^ +\\([^:]+\\):[[:space:]]*\\(\\([ \t012][0-9]\\):\\([0-5][0-9]\\)\\)\\(?:-\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\|.*\\)?[[:space:]]+Clocked:[[:space:]]+\\(([0-9]+:[0-5][0-9])\\|(-)\\)"))
(with-temp-buffer
(insert " Work_Projects: 9:00-10:05 Clocked: (1:05) TODO Weekly GI
Work_Projects: 9:00-10:05 Clocked: (1:05) Some other text
")
(goto-char (point-min))
(assert (looking-at test-re) nil "Regexp did not match")
(princ (format "regexp matched: %s" (match-string-no-properties 0)))))
This should behave differently in your Emacs if you run interpreted and byte compiled versions of it. If that really is the case, I think it would be a good time to write to the developers list.
I evaluated the sample you gave me, shown below as copied from my buffer.
(let ((test-re "^ +\\([^:]+\\):[[:space:]]*\\(\\([ \t012][0-9]\\):\\([0-5][0-9]\\)\\)\\(?:-\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\|.*\\)?[[:space:]]+Clocked:[[:space:]]+\\(([0-9]+:[0-5][0-9])\\|(-)\\)"))
(with-temp-buffer
(insert " Work_Projects: 9:00-10:05 Clocked: (1:05) TODO Weekly GI
Work_Projects: 9:00-10:05 Clocked: (1:05) Some other text
")
(goto-char (point-min))
(assert (looking-at test-re) nil "Regexp did not match")
(princ (format "regexp matched: %s" (match-string-no-properties 0)))))
The result looks good to me as: "regexp matched: Work_Projects: 9:00-10:05 Clocked: (1:05)"
I then byte compiled the sample to get this:
;ELC���
;;; Compiled
;;; in Emacs version 27.0.91
;;; with all optimizations.
;;; This file uses dynamic docstrings, first added in Emacs 19.29.
;;; This file does not contain utf-8 non-ASCII characters,
;;; and so can be loaded in Emacs versions earlier than 23.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(byte-code "\302\303\304!r q\210\305\216\306c\210eb\210\307\310\311\312\313!\"!\210,\303\207" [test-re #1=#:temp-buffer "^ +\\([^:]+\\):[[:space:]]*\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\(?:-\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\|.*\\)?[[:space:]]+Clocked:[[:space:]]+\\(([0-9]+:[0-5][0-9])\\|(-)\\)" generate-new-buffer " *temp*" #[nil "\301!\205 �\302!\207" [#1# buffer-name kill-buffer] 2] " Work_Projects: 9:00-10:05 Clocked: (1:05) TODO Weekly GI\n Work_Projects: 9:00-10:05 Clocked: (1:05) Some other text\n" princ format "regexp matched: %s" match-string-no-properties 0] 5)
When I evaluate this I get args-out-of-range error
Debugger entered--Lisp error: (args-out-of-range #<buffer *temp*> 0 1)
buffer-substring-no-properties(0 1)
match-string-no-properties(0)
byte-code("\302\30\303\304!\31r\11q\210\305\216\306c\210eb\210\307\310\311\312\313!\"!\210,\303\207" [test-re temp-buffer "^ +\\([^:]+\\):[[:space:]]*\\(\\([ \011012][0-9]\\):\\([0-5..." generate-new-buffer " *temp*" #f(compiled-function () #<bytecode 0x1fe1940df099>) " Work_Projects:\119:00-10:05 Clocked: (1:05) TODO ..." princ format "regexp matched: %s" match-string-no-properties 0] 5)
eval((byte-code "\302\30\303\304!\31r\11q\210\305\216\306c\210eb\210\307\310\311\312\313!\"!\210,\303\207" [test-re temp-buffer "^ +\\([^:]+\\):[[:space:]]*\\(\\([ \011012][0-9]\\):\\([0-5..." generate-new-buffer " *temp*" #f(compiled-function () #<bytecode 0x1fe1940df099>) " Work_Projects:\119:00-10:05 Clocked: (1:05) TODO ..." princ format "regexp matched: %s" match-string-no-properties 0] 5) nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
Some of those characters pasted strange. Here is a screenshot of the byte compiled version
I was just a bit too late in providing a better test. Here is a better way how you can test all of this in the scratch buffer. We define the function my-bctest which contains that code. Then you execute it once in its interpreted fashion using C-x C-e. Then we use the byte-compile command to turn the function into its byte-compiled form. And then you execute that one.
(defun my-bctest ()
(let ((test-re "^ +\\([^:]+\\):[[:space:]]*\\(\\([ \t012][0-9]\\):\\([0-5][0-9]\\)\\)\\(?:-\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\|.*\\)?[[:space:]]+Clocked:[[:space:]]+\\(([0-9]+:[0-5][0-9])\\|(-)\\)"))
(with-temp-buffer
(insert " Work_Projects: 9:00-10:05 Clocked: (1:05) TODO Weekly GI
Work_Projects: 9:00-11:05 Clocked: (2:05) Some other text
")
(goto-char (point-min))
(assert (looking-at test-re) nil "Regexp did not match")
(princ (format "regexp matched: %s" (match-string-no-properties 0)))))
)
;; execute the following for interpreter execution
(my-bctest)
;; byte compile the function (after this command, you can test with 'C-h f' that
;; the function now really is byte-compiled)
(byte-compile 'my-bctest)
;; now run the function in its byte compiled form and compare
(my-bctest)
If this gives an error, I think these lines can be submitted easily to the Emacs devel list to raise attention to the problem.
I followed those steps and of course it runs fine for that test. I also verified I still have the problem, so it did not sudden fix itself. I wonder if the difference with this latest test is that it all occurred in memory rather than going through the file io. In the test before this I used dired to create the compiled version on disk and then loaded it in to evaluate.
Hmmm.... at least we now know that it is not a problem with the byte compilation itself. If it is as you suspect, and it has to do with the serialization to and deserialization from file, then it really is an exotic problem. I'm a bit at a loss...
A pragmatic solution for you at this moment might be to just run the org-clock-convenience functions not in the byte compiled form. Just keep the elc file deleted. You may also put such a line on top of the file to prevent it from being compiled.
;; -*-no-byte-compile: t; -*-
Sorry, at the moment I do not have a good idea how to tackle your problem, further. Probably one could try to see whether the memory representation of the byte compiled function differs when it is read from file, in comparison to creating it directly. But something is really really strange.
FYI for curiosity's sake and to learn a little more about elisp, I reread the advice you gave me and tried some other steps to narrow it down some more. I found that after I byte compile the file, I can get it to work by just opening the source and eval-defun the one function: org-clock-convenience-get-fieldname. It continues to work when I byte compile that in memory and confirm via C-h f that the function is compiled.
** [2020-06-30 Tue] Troubleshoot org-clock-convenience *** byte compile org-clock-convenience fails to work *** eval-defun org-clock-convenience-get-fieldname works *** (byte-compile 'org-clock-convenience-get-fieldname) works and C-h f verifies it is compiled *** elc file version
#+begin_quote
(defalias 'org-clock-convenience-get-fieldname #[(point re fnames &optional ignore-lst errmsg) "\306 \307\216\212\310 \210+ \311\312\313\311\f\n:\203S�\n@\fT
>\204H�\f\211\224\205:�\211\224X\205:�\211\225Y\266\202\203H�\f\311\211\202I�\313\203S�\nA\211\202�
?\205Z�\f-\207" [#1=#:saved-marker fnames #2=#:--cl-var-- field cnt #3=#:--cl-var-- save-mark-and-excursion--save #[nil "\301!\207" [#1# save-mark-and-excursion--restore] 2] beginning-of-line nil 0 t #4=#:--cl-var-- ignore-lst point] 5 (#$ . 2855)])
#+end_quote
*** in memory version
#+begin_quote
#[(point re fnames &optional ignore-lst errmsg) "\306 \307\216\212\310 \210\311 !\204�\312\313
\206�\314\315\211$\210+\315\316\317\315:\203j�@T
>\204_�\211\224\205P�\211\224X\205P�\211\225Y\266\202\203_�
\315\211\202`�\317\203j�A\211\202)�?\205r�-\207" [saved-marker re errmsg fnames --cl-var-- field save-mark-and-excursion--save #[nil "\301!\207" [saved-marker save-mark-and-excursion--restore] 2] beginning-of-line looking-at cl--assertion-failed (looking-at re) ...] 6 "Return field name of submatch where POINT is located.
The field names are based of the sub-patterns defined by the
regexp RE and the passed field names list FNAMES. RE must match
from the beginning of line. The optional parameter IGNORE-LST can
contain a list of submatch field names to ignore (sometimes there
are subpattern which contain several other subpatterns, and one
wants only the names of the smaller subpatterns). ERRMSG allows
specifying an error message if RE is not matching."]
#+end_quote
You really cornered the problem now to the first few lines of that function. At some point I thought the problems could also come from some macro related source, but these lines seem so easy. Still, I committed now the code that makes the regexp a bit more flexible, but I also discovered that I had not used the POINT argument in the function... somehow when I was rewriting it once that seemed to have fallen out. But it did not matter for the standard use inside of the package.
This discussion goes completely over my head due to my limited understanding of the inner workings of Emacs, but I just wanted to chip in: after a recent update of all my packages, I received the same error about "not on a time range field", but removing the .elc and then running eval-buffer on the .el file solved my issues.
Not sure whether this actually provides useful information for your debugging purposes, but removing the .elc is a workaround that is easy enough.
And also: I'm so very glad that this workaround fixes it, because I was really missing the convenience -- just to say: thanks for this great package 👍
@EFLS Are you also on a Mac? It helps to know someone else is experiencing the same issue. Most of this thread was trying to help me find out why it was specific to my configuration. I did remove the elc file and it does work, but I keep going back to see if I can learn why the byte-compile is failing, but works when I do it again after the function loads.
I also agree it is a great package and I use it multiple times a day.
(I'm also seeing this issue, but on linux. Package version 20200705.1527 with emacs 26.3).
Edit: I upgraded to emacs 27 and recompiled everything, but to no avail. removing the .elc file did work, however.
Digging a bit deeper into it, it seems like the regex doesn't work when ~~I have lines with tags (e.g., :@office) in them~~ this is wrong, the culprit is the estimated effort. For instance:
inbox: 12:08-13:35 Clocked: (1:27) DONE Watch EE263 lecture
gtd: 14:15-14:45 0:30 Clocked: (0:30) DONE Make sure to convey in the paper outline that not any synthetic dataset works. :@office:
The regex:
"^ +\\([^:]+\\):[[:space:]]*\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\(?:-\\(\\([ 012][0-9]\\):\\([0-5][0-9]\\)\\)\\|.*\\)?[[:space:]]+Clocked:[[:space:]]+\\(([0-9]+:[0-5][0-9])\\|(-)\\)"
matches the first, but not the second. Here's a screenshot from the regex-builder with my current value of org-clock-convenience-clocked-agenda-re (the same as what's above):
Upon further inspection, it seems like the issue isn't the tag, but the estimated effort. Here's a screenshot showing lines with:
(1) no tag, estimated effort (doesn't work)
(2) has tag, estimated effort (doesn't work)
(3) no tag, no effort (works)
(4) has tag, no effort (works)
Hi @nelson-liu Yes, seems I need to extend the regex for this additional time field. I never used estimated effort, so I did not yet have any such case. Thanks for debugging. So I just need to introduce another optional timestamp pattern after the timerange in the clock line.
It definitely is a different kind of problem that @mbarton98 has.
I can probably do it by tomorrow. Or do you want to send a pull request?
Yeah, you're right it's a different issue--apologies for polluting the issue tracker.
I can probably do it by tomorrow. Or do you want to send a pull request?
It'd be great if you could get to it---I was studying the regex yesterday to see if I could make a fix, but I think there are some elisp-specific artifacts (e.g., the way things are escaped) that eluded me. Let me know if you can't get to it, though, and I can try to take another look over the weekend.
Thanks @dfeich !
Hi @nelson-liu I just tried to first also get effort estimates to display in my agenda log lines. I have never used effort estimation before, and I just added some effort estimates to tasks. But they are not shown in the log lines for me. I then tried to understand how the log lines and all other entries in the agenda display are configured and formatted... Can you tell me about your setup? How do you configure the efforts to display in your case?
Depending on these log line configurations, I may anyhow need to think about the package or at least about the documentation. The package will only work with the correct regexps matching the configured log lines. So, if this is very variable according to user configuration, I have to at least point this out in the documentation, and potentially indicate how users could adapt the package.
Hi @dfeich , thanks so much for taking a look into it! I did some more investigation and made a new issue that more concisely encapsulates what's going on here---let's continue the discussion there? https://github.com/dfeich/org-clock-convenience/issues/10
Closing this old bug. Hopefully the byte compile related problems have disappeared. Else, please re-open or post as a new bug.