[BUG] Incorrect time calculation in agenda clockcheck

[Raffael Stocker]

Hi org-mode,

in the Org Agenda clockcheck view, a warning about missing end time of a
clocked-in task is displayed together with the already elapsed time of
that task.  If the starting time is in the future (this can happen if
rounding and continuous clocking are used), the elapsed time is
incorrect.  For example, if a clocked-in task starts in 5 minutes,
clockcheck will report something like "No end time: (0:55)".  It would
be more sensible to say "No end time: (-0:05)" or even "No end time: (in
0:05)".

The culprit is the use of ‘org-duration-from-minutes’ in
‘org-agenda-show-clocking-issues’, because org-duration always assumes
positive durations and is given a negative one here.  The problem can
easily be corrected with something like the following:

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index b3c7294a2..968b6bd50 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6237,11 +6237,12 @@ defun org-agenda-show-clocking-issues
 	  (setq issue
 		(format
 		 "No end time: (%s)"
-		 (org-duration-from-minutes
-		  (floor
-		   (- (float-time (org-current-time))
-			  (float-time (org-time-string-to-time (match-string 1
-		   60)))
+		 (let ((diff (floor
+		  (- (float-time (org-current-time))
+			 (float-time (org-time-string-to-time (match-string 1
+		  60)))
+   (concat (if (> 0 diff) "-" "")
+   (org-duration-from-minutes (abs diff)
 		face (or (plist-get pl :no-end-time-face) face))
 	  (throw 'next t))
 	(setq ts (match-string 1)

However, I believe it would be more useful (and general) to use a
similar trick to teach org-duration to work with negative durations.

Cheers,
Raffael

Re: [PATCH] oc-csl: New custom option `org-cite-csl-sentence-case-bibtex-titles'

[Max Nikulin]

On 11/05/2024 22:33, András Simonyi wrote:

since bibtex and biblatex requires title fields to be in title case
but CSL assumes that they are in sentence-case, citeproc-el converts
title fields in bib(la)tex bibliography databases into sentence-case
before processing them except for entries with an explicit non-English
langid value.


I am not a user of citeproc-el, so feel free to disregard my comments.

In the past I had to adjust BibTeX styles, but yesterday I was surprised 
that there are options for upper case, lower case, and sentence-style 
capitalization, but not for title-style capitalization. It seems that 
both approaches with title case and with sentence case have some 
shortcomings. Likely title case like in BibTeX requires more explicit 
hints and perhaps there are cases when available hints are not enough to 
get specific formatting. I still expect that CSL needs hints as well to 
avoid improper formatting.


Is it possible to keep title formatting from .bib files till it becomes 
known that specific style requires sentence case for particular entry 
type? I had a hope that it might alleviate the issue and to make things 
working out of the box for more users.



I'm a bit unsure about naming the option:
Perhaps `org-cite-csl-sentence-case-bibtex-titles-without-langid'


A variant: org-cite-csl-bibtex-title-to-sentence-case


@@ -584,7 +599,8 @@ property in INFO."
  (processor
   (citeproc-create
(org-cite-csl--style-file info)
-   (citeproc-hash-itemgetter-from-any bibliography)
+   (citeproc-hash-itemgetter-from-any
+bibliography (not org-cite-csl-sentence-case-bibtex-titles))
(org-cite-csl--locale-getter)
locale)))
 (plist-put info :cite-citeproc-processor processor)


I am not in the context, so I may be completely wrong.

Does it means that you added one more argument to `citeproc-create' and 
that consistent Org and citeproc-el versions must be used? If so, 
wouldn't it better to pass a property list to allow newer Org to work 
with older citeproc-el or vice versa? It may be tricky to preserve 
backward-forward compatibility on this step, but it should make further 
changes easier. It may be reasonable to explicitly add version of 
"protocol" to the property list, so that citeproc-el may decide if error 
should be signaled in the case of serious version difference.


It is not clear for me why `org-cite-csl-sentence-case-bibtex-titles' is 
a part of Org, not of citeproc-el. The only thing that Org can do is to 
pass it to citeproc-el. It is not configurable per .org file and likely 
it should not be. From my point of view it might be more suitable per 
.bib file. Anyway it is almost unrelated to Org.

Re: [BUG] Warning (org-element-cache): org-element--cache: Org parser error [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

>> ...
>> After I interrupt it, my agenda works fine until I restart Emacs and
>> then it happens again.
>>
>> Any ideas / hints?  Thanks!
>
> Thanks for reporting!
> May you try to upgrade to the development version of Org mode?

More information have been requested, but none was provided.
Closing.
Canceled.

(It is still useful to get reports like this just to understand if
people keep seeing cache bugs)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Invalid search bound (wrong side of point) [9.6.25 ( @ /Users/cchoi/.config/emacs/elpa/org-9.6.25/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Charles Choi  writes:
>
>> Got this warning when running Org Agenda, thought I'd report it in.
>>
>> ⛔ Warning (org-element-cache): org-element--cache: Org parser error in 
>> 2024_04_07.org::#. Resetting.
>>  The error was: (error "Invalid search bound (wrong side of point)")
>
> Does it also happen on main?

More information have been requested, but none was provided.
Closing.
Canceled.

(It is still useful to get reports like this just to understand if
people keep seeing cache bugs)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?)

[Max Nikulin]

On 14/05/2024 19:56, Ihor Radchenko wrote:

Max Nikulin writes:

On 13/05/2024 17:07, Ihor Radchenko wrote:


<2025-01-31 Fri +1m>
<2025-02-28 Fri +1m>
<2025-03-28 Fri +1m>


Instead of using timestamp obtained on previous step, use original
timestamp and multiple of the interval.


This is not possible because of how `org-auto-repeat-maybe' is designed.


Then the only way to get reasonable results is to store in :PROPERTIES: 
either original date (and iteration count) or current date before 
clamping (2025-02-31)



No idea. I am not aware about any existing built-in API that provides
date increments.


The context was that day start time may give some surprise as well. I am 
unsure concerning namely increments. I just expected a set of more 
accurate functions for working with dates.



+  (org-encode-time

[...]

+(+ (if (eq unit 'day) value 0)(decoded-time-day time))


Have you considered using `min' with result of `date-days-in-month' here
(or its sibling from timezone.el)?


Not sure if it is going to be simpler.


My idea was to avoid the backward `while' loop in the code below this line.


(format-time-string
   "%F %T %Z %z"
   (encode-time '(0 30 12 15 1 2000 'ignored nil "Africa/Juba"))
   "Africa/Juba")
(error "Specified time is not representable")


Hmm. I am not sure if it is a real problem in practice.
String values of time zone are only possible for hand-crafted time
values.


This example avoids changing system time or starting Emacs with TZ 
environment. The following example does not include explicit timezone:


TZ=Africa/Juba emacs -Q --batch \
--eval "(encode-time '(0 30 12 15 1 2000 'ignored nil nil))"


The reason why I forced DST nil is hysteresis of glibc when dealing with
DST transitions:


At first I was trying to figure out what time zone had 24:00<->23:00 
transition in 2012.



(cl-loop for m in '(1 2 3 4 5 6 7 8 9 10 11 12)
   collect (decode-time (encode-time `(0 0 0 4 ,m 2012 nil -1 10800

(0 0 23 3 1 2012 2 nil 7200)


This result depends on your timezone. It is consistent with e.g. 
Asia/Istanbul. It had +02:00 offset in January, but you requested 
+03:00. The result of conversion is -1 hour difference in requested 
timestamp and conversion result. It is unrelated to internal DST state 
and hysteresis caused by this state.


When DST is nil
2012-01-04 00:00:00 +03:00 === 2012-01:03 23:00:00 +02:00

Avoid passing timezone offset when you do not know it.

I agree that there are issues with handling tm_gmtoff and tm_isdst
https://data.iana.org/time-zones/theory.html#POSIX-extensions
Results may vary across libraries.


Although, forcing DST nil will not always help here


It is fragile, I would not rely on ignoring offset when DST is 
specified. Actually you pass mutually inconsistent values, so it is 
either undefined behavior or close to it.

Re: LOGBOOK drawer now being created with blank line afterwards

[Rens Oliemans]

Kris Nelson  writes:

> I'm currently reviewing the org source to try and see where the new line is 
> coming from in the process flow, but I'm a bit of a novice in regards to 
> elisp, so I haven't figured that out yet.
>
> I also tried searching the mailing list archive, but didn't see anything 
> related.

Thanks for reporting, it seems that this was changed in
f63ff074417315fcf93c2ca6cfe8f89fcc6d902f, "Fix subtle differences between 
overlays and
invisible text properties", bisected with Emacs 29.3.

Re: org-table-row face

[Colin Baxter]

Dear Eric,

>  Fraga, Eric  writes:

,> On Monday, 13 May 2024 at 21:16, Colin Baxter wrote:
>> Thanks, so presumably I just use set-face-attribute.

,> For many/most face aspects, I find the customize interface the
,> easiest to use.  Simply

,> M-x customize-face RET org-table-row RET

I don't use customize-faces at all. I've now set it in my theme file.

Thanks.

Colin.

Re: Using search options in HTTP-style links

[Joseph Turner]

Ihor Radchenko  writes:

> I was mostly talking about commands like eww - I simply recall a similar
> proposal being made about activating Org mode when the URL points to Org
> file. That proposal has been rejected on the grounds of security. See
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774
>
> The case with hyperdrive.el is not the same.
> You may want to discuss it on emacs-devel.

Thank you!  It is a good idea to get more input on securing
hyperdrive.el.  For now, I went through bug#58744 and took some notes in
two relevant hyperdrive.el issues:

- https://todo.sr.ht/~ushin/ushin/178
- https://todo.sr.ht/~ushin/ushin/178

> As for untrusted-content, there is no point using it now - it was
> specifically introduced for Org mode. It may or may not become a part of
> more general security framework in Emacs.

Sounds good.

Thank you!!

Joseph