[BUG] cache file conflict? [9.7-pre (release_9.6.29-1441-gaa71fa @ /home/minshall/.emacs.d/straight/build/org/)]

[Greg Minshall]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


i run various Emacs instances, in each of which i run org.  i frequently
get these messages (followed by errors when i reply 'q'):

...rg-persist/gc-lock.eld locked by minshall@arch... (pid 546721): (s, q, p, 
?)? 
Error running timer ‘org-persist--refresh-gc-lock’: (file-locked 
"/home/minshall/.cache/org-persist/gc-lock.eld" "minshall@archlinux (pid 
546721)")


since i don't see a PID in the lock file name (i assume it is), i wonder
if the code occasionally has this problem when more than one instance
attempts to acquire this lock at a time?

cheers!

Emacs  : GNU Emacs 30.0.50 (build 14, x86_64-pc-linux-gnu, GTK+ Version 
3.24.38, cairo version 1.18.0)
 of 2023-11-20
Package: Org mode version 9.7-pre (release_9.6.29-1441-gaa71fa @ 
/home/minshall/.emacs.d/straight/build/org/)

LOGBOOK drawer now being created with blank line afterwards

[Kris Nelson]

Hi,

I've noticed after upgrading to the latest Org version (9.6.30), when the 
LOGBOOK drawer is automatically generated during a TODO state change it inserts 
a blank line after the end of the drawer. This did not occur on the Org version 
I was using previously (9.5.5).

I'm not sure if this is an intended change or a bug. If it is intended, would 
there be a way to disable that behaviour (org-blank-before-new-entry does not 
seem to apply here)?

To clarify, given the following sample org file:

-*- mode: org; org-log-into-drawer: t -*-

#+SEQ_TODO: TODO(t!) | DONE(d!)

* With Org 9.5.5
** Example project
*** Action 1
*** Action 2

* With Org 9.6.30
** Example project
*** Action 1
*** Action 2


I get the following results when toggling the TODO state on the "Example 
project" heading with org-todo:

* With Org 9.5.5
** TODO Example project
:LOGBOOK:
- State "TODO"   from  [2024-05-14 Tue 12:24]
:END:
*** Action 1
*** Action 2

* With Org 9.6.30
** TODO Example project
:LOGBOOK:
- State "TODO"   from  [2024-05-14 Tue 12:38]
:END:

*** Action 1
*** Action 2


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,
Kris

Re: [PATCH] org-manual: Rewrite opening section in Citation handling

[Rens Oliemans]

Thanks for the patch, it looks good and is an improvement over the
somewhat terse previous version. I do have some thoughts though so will
chime in. Note that I am not a native speaker, it might be best if we get
extra eyes from a(nother?) native speaker.

Ihor Radchenko  writes:

> +While [[*Hyperlinks][links]] are often sufficient to refer to external
> +or internal information from Org, they have their limitations when
> +referring to multiple targets or typesetting printed publications.

In Emacs Info, this renders as

   "While see links. are often sufficient ...".

This seems quite unnatural to me. I would suggest using a different way
of referencing (without "see [link].") if possible, or rewording the
sentence otherwise.

> +In addition to export, users can use completion to search and insert
> +citations from the bibliography (via ~org-cite-insert~).  Citations
> +also act like ordinary links, jumping to the citation metadata when
> +"following" them (~org-open-at-point~).

Alternatively:

   when "following" them using ~org-open-at-point~.

For a more natural sentence?

> +Org mode ships with several built-in citation processors tailored to
> +work with LaTeX export and BibTeX bibliographies (=bibtex=,
> +=biblatex=, and =natbib= processors), or with more generic formats
> +described using [[https://citationstyles.org/][Citation Style
> +Language]] (=csl= processor).
> +
> +The default citation processor is =basic= - it works with arbitrary
> +export formats and recognizes both BibTeX and CSL bibliographies.
> +
> +More citation processors are distributed as Emacs packages.

These very small paragraphs read a bit clunky to me, I think that it's
better to merge them into a single paragraph.

> -  When style is not specified, default style is used
> +  When style is not specified, default style (=nil=) specified by the
> +  citation processor is used

I am only slightly familiar with Org's citation handling, and this part
of the manual is a bit confusing to me. I wrote a small patch on top of
yours with something that is clearer to me, but perhaps this is unique to
me.

>From 70fe33fe0012c124fd011011ee77e544e18d50ad Mon Sep 17 00:00:00 2001
From: Rens Oliemans 
Date: Tue, 14 May 2024 20:45:01 +0200
Subject: [PATCH] org-manual: clarify default style

I don't intend this commit to be merged but instead to be squashed in
the existing patch.
---
 doc/org-manual.org | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 50af99c5b..c2f08be17 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17609,16 +17609,16 @@ identifying a reference in the bibliography.
 
   : [cite/style:common prefix ;prefix @key suffix; ... ; common suffix]
 
-  When style is not specified, default style (=nil=) specified by the
-  citation processor is used
+  When =style= is not specified, one of the two default styles are
+  used
 
-  + either the default style specified in =CITE_EXPORT= keyword (see
-[[*Citation export processors]])
+  + either the default style specified in the =CITE_EXPORT= keyword
+(see [[*Citation export processors]])
 
 : #+cite_export: basic numeric noauthor/bare
 : [cite:@key] is the same as [cite/noauthor/bare:@key]
 
-  + or using default =nil= style
+  + or, if =CITE_EXPORT= is not set, using the default =nil= style
 
 : [cite:@key] is the same as [cite/nil:@key]
 
-- 
2.44.0


Is this understanding of the 'style' specification correct? This is what
I concluded from reading the manual, if it is incorrect, please forgive
me and let me know how exactly I am incorrect, perhaps that can
illuminate this part ;)


Best,
Rens

PS: is such a way of including a patch (that builds upon a discussed
patch) the best way to communicate changes? 

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

[Stefan Nobis]

Ihor Radchenko  writes:

> This is not possible because of how `org-auto-repeat-maybe' is
> designed. When repeater is triggered, the original date in the
> timestamp is replaced with future date. So, we have no access to the
> original date in the timestamp.

And even if we would have access to the original date: It may be
something like the last day of February and from that alone it is not
evident, wether e.g. the 28. of each month should be used or the last
day of month.

Therefore, I think, the only solution to this problem is to have some
kind of special 'last day of month' marker. Maybe something like
"+1m!" or any other way of encoding this "go to the last day of the
next month" directly into the increment specifier.

-- 
Until the next mail...,
Stefan.

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

[Ihor Radchenko]

Max Nikulin  writes:

> On 13/05/2024 17:07, Ihor Radchenko wrote:
>> 
>> However, there are still some issues remaining.
>> When updating timestamps repeating monthly across months with 30, 31,
>> and 28 days we get
>> 
>> <2025-01-31 Fri +1m>
>> <2025-02-28 Fri +1m>
>> <2025-03-28 Fri +1m>
>> ...
>> <2026-01-28 Wed +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.
When repeater is triggered, the original date in the timestamp is
replaced with future date. So, we have no access to the original date in
the timestamp.

> I have the following in my notes. However I have not find suitable 
> functions in elisp:
>
> https://debbugs.gnu.org/54764#10
> Paul Eggert. Sat, 9 Apr 2022 00:52:57 -0700
>> Generally speaking, 
>> when Org mode is doing calendrical calculations it should use 
>> calendrical functions rather than encode-time+decode-time, which are 
>> best used for time calculations not calendar calculations.
>
> Do you have any idea what Paul was writing about?

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

>> +  (org-encode-time
>> +   (list
>> +(+ (if (eq unit 'second) value 0) (decoded-time-second time))
>> +(+ (if (eq unit 'minute) value 0) (decoded-time-minute time))
>> +(+ (if (eq unit 'hour) value 0)   (decoded-time-hour 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.

>> +(defun org-time-inc (unit value time)
> Is there a chance that support of intervals like 1h20m will be required 
> later?

Not sure again. I simply used ts-inc function signature from Adam's
ts.el as reference.

>> +(+ (if (eq unit 'month) value 0)  (decoded-time-month time))
>> +(+ (if (eq unit 'year) value 0)   (decoded-time-year time))
>> +(decoded-time-weekday time)
>> +(if (memq unit '(day month year))
>> +nil ; Avoid auto-adjustments of time when jumping across 
>> DST.
>
> Sorry, but you have to use -1, otherwise
>
> (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. Using `decode-time' does not retain the time zone name:

(decode-time
  (encode-time '(0 30 12 15 1 2000 'ignored -1 "Africa/Juba")))
; => (0 30 12 15 1 2000 6 nil 7200)

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

(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)
(0 0 23 3 2 2012 5 nil 7200)
(0 0 23 3 3 2012 6 nil 7200)
(0 0 0  4 4 2012 3 t 10800)
(0 0 0  4 5 2012 5 t 10800)
(0 0 0  4 6 2012 1 t 10800)
(0 0 0  4 7 2012 3 t 10800)
(0 0 0  4 8 2012 6 t 10800)
(0 0 0  4 9 2012 2 t 10800)
(0 0 0  4 10 2012 4 t 10800)
(0 0 23 3 11 2012 6 nil 7200)
(0 0 23 3 12 2012 1 nil 7200)

Although, forcing DST nil will not always help here, so I need some
other solution to this problem.
(timezones, DSTs... :sigh:)

>> +  (decoded-time-dst time))
>> +(decoded-time-zone time))
>> +(if (not org-repeat-round-time) new-time
> I am in doubts if `org-time-inc' should access `org-repeat-round-time' 
> directly or its value should be passed as an explicit argument. Perhaps 
> the additional argument may be optional with fallback to 
> `org-repeat-round-time' when it is omitted.

This is of no use for now - we do not need to pass different parameters
to `org-time-inc' from the existing Org code. But we can always add an
extra optional argument if necessary.

-- 
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 13/05/2024 17:07, Ihor Radchenko wrote:


However, there are still some issues remaining.
When updating timestamps repeating monthly across months with 30, 31,
and 28 days we get

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


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


I have the following in my notes. However I have not find suitable 
functions in elisp:


https://debbugs.gnu.org/54764#10
Paul Eggert. Sat, 9 Apr 2022 00:52:57 -0700
Generally speaking, 
when Org mode is doing calendrical calculations it should use 
calendrical functions rather than encode-time+decode-time, which are 
best used for time calculations not calendar calculations.


Do you have any idea what Paul was writing about?

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

+   (type-unit (pcase type
+("h" 'hour) ("d" 'day) ("w" 'week)
+("m" 'month) ("y" 'year
I do not mind against `pcase' here, I just expected something like 
`assoc' and `string-to-char'.



+ ((or "m" "y")

Another comment that may be ignored: `type-unit' values might be used here.


+  (org-encode-time
+   (list
+(+ (if (eq unit 'second) value 0) (decoded-time-second time))
+(+ (if (eq unit 'minute) value 0) (decoded-time-minute time))
+(+ (if (eq unit 'hour) value 0)   (decoded-time-hour 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)?



+(defun org-time-inc (unit value time)
Is there a chance that support of intervals like 1h20m will be required 
later?



+(+ (if (eq unit 'month) value 0)  (decoded-time-month time))
+(+ (if (eq unit 'year) value 0)   (decoded-time-year time))
+(decoded-time-weekday time)
+(if (memq unit '(day month year))
+nil ; Avoid auto-adjustments of time when jumping across DST.


Sorry, but you have to use -1, otherwise

(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")


+  (decoded-time-dst time))
+(decoded-time-zone time))
+(if (not org-repeat-round-time) new-time
I am in doubts if `org-time-inc' should access `org-repeat-round-time' 
directly or its value should be passed as an explicit argument. Perhaps 
the additional argument may be optional with fallback to 
`org-repeat-round-time' when it is omitted.

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

[András Simonyi]

Dear All,

On Sat, 11 May 2024 at 19:24, Ihor Radchenko  wrote:

>> > since bibtex and biblatex requires title fields to be in title case
> Are you sure? AFAIK, bibtex and biblatex (depending on the bibstyle)
> does not care about capitalization and instead applies its own, unless
> the title explicitly protects the capitalization/case with {Curly
> BracketS}.

Yes, I'm pretty sure that the expected casing in .bib bibliography
databases for the title fields is by default title case, plus
protective braces around texts whose case shouldn't be touched during
formatting (of course, formatting itself can produce both sentence and
title case from this input depending on the used style). This
requirement was already clearly stated in Lamport's original LaTeX
book. To quote the relevant part of "The Bibliography Database"
chapter  (2nd edition, p. 158):

> The bibliography style determines whether or not a title is capitalized; the
> titles of books usually are, the titles of articles usually are not. You type
> a title the way it should appear if it is capitalized. You should capitalize
> the first word of the title, the first word after a colon, and all other words
> except articles and unstressed conjunctions and prepositions. BiBTeX will
> change uppercase letters to lowercase if appropriate. Uppercase letters that
> should not be changed are enclosed in braces.

These requirements haven't changed since then and also hold for
biblatex, see, e.g.,
https://tex.stackexchange.com/questions/439440/what-is-the-proper-casing-to-use-when-storing-titles-in-the-bibliography-database.
If you are interested, you can also look at the discussion concerning
the citeproc-el conversion implementation at
https://github.com/andras-simonyi/citeproc-el/issues/71, see also the
"Capitalization in titles" section in
Pandoc's User’s Guide.

The proposed default makes it possible to use a .bib bibliography
database that conforms to the standard title field format requirements
(title case etc.) and get the intended output corresponding to the
used citation style both with bib(la)tex and CSL styles.  Moreover, it
matches Pandoc's behaviour, see
https://github.com/jgm/pandoc-citeproc/issues/269.

best wishes,
András

Re: [PATCH 1/2] org-capture: Allow entry template to start without heading

[Rens Oliemans]

Ihor Radchenko  writes:

> It has been one month since the last activity in this thread.
> May I know if you got any reply from FSF?

I did, I got and signed the assignment, on Friday the 10th of May. I will get a 
reply of
the FSF once they have signed it, and will post here when that happens.

Best,
Rens

Re: [PATCH 1/2] org-capture: Allow entry template to start without heading

[Ihor Radchenko]

Rens Oliemans  writes:

>> Before I install the patches, may I know if you have FSF copyright
>> assignment? See https://orgmode.org/worg/org-contribute.html#copyright
>
> I had not done that yet. I have just sent the form to the FSF. I will let
> you know when the process is complete.

It has been one month since the last activity in this thread.
May I know if you got any reply from FSF?

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

Re: org-table-row face

[Fraga, Eric]

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

(and then probably click on "Show all attributes").

You can see that the inherit option is selected if the face has not
previously been customised.

-- 
: Eric S Fraga, with org release_9.6.23-1320-g1be2f9 in Emacs 30.0.50

Re: [PATCH] org-manual: Rewrite opening section in Citation handling

[András Simonyi]

Dear All,

On Sat, 11 May 2024 at 11:55, Ihor Radchenko  wrote:

> See the attached updated version of the patch with all your comments
> addressed.

Thanks Ihor, the patch looks good to me now!

best wishes,
András