Re: [POLL] Proposed syntax for timestamps with time zone info

[Jean Louis]

* Stefan Nobis  [2023-02-03 18:50]:
> Jean Louis  writes:
> 
> > Specifying time zone is not ambiguous as long as you use the TZ
> > database for specifications!
> 
> That's wrong and you know it.

What I know is based on research and good references. It seems you did
not follow it.

> For example
> 
>[2023-10-29 02:30 @Europe/Berlin]
> 
> is ambiguous. Period.

You may put as many periods as you want.

If you do not know how to generate timestamp that they are conclusive,
then they will be always invalid or ambigous.

Computer program that knows that your timestamp is most probably try
to correct it, as saving time with invalid timestamp with some
programs does not work, as I have demonstrated.

Fact is that some timestamps mentioned in the conversations are
invalid. 

Such invalid timestamps were generated by human, not by computer.

Agree on what people internationally agreed.

Do not generate it in first place.

I can place any kind of text anywhere and I could say it is
"timestamp", but that is valid for me, not for community that relies
on international agreements.

If user wish to do timestamp generation by hand, or some looney
program wish to generate invalid timestamps, I can only say "good
luck", but it is good to warn users and file bug reports for such
program.

Timestamp of course may be generated by human, and it can be ambigous. 

But why would you do that? 

Isn't it better to learn how to write non-ambigous timestamps?

Or even better, to use good program to generate non-amgibious
timestamp?

Every user and programmer should strive to make computer, in this case
Org program, to generate and calculate useful timestamps and how to
increase that usefulness for users by being accurate.

Programmer should not strive to generate invalid timestamps, and then
prolong discussions how timestamp is invalid.

That is programmer's problem. 

We have that problem in Org, solutions are in sight.

It is not international problem at all as it is solved by ISO
representation.

All computer programs should use the internationally accepted time
zone database and not those invalid timestamp representation but valid
timestamp representation.

And user should file bugs when they see that timestamps are either
incorrectly represented, invalid, or there are some problems.

It is easy to observe how will PostgreSQL understand those times with
time zone being Europe/Berlin:

Here it will tell that time of 01:30 has UTC offset of +02:

select '2023-10-29 01:30:00'::timestamp at time zone 'Europe/Berlin';
timezone

 2023-10-29 01:30:00+02
(1 row)

Here it will tell that time of 02:30 has UTC offset of +01:

select '2023-10-29 02:30:00'::timestamp at time zone 'Europe/Berlin';
timezone

 2023-10-29 02:30:00+01
(1 row)

Here it will tell that time of 02:30 has UTC offset of +01:

select '2023-10-29 03:30:00'::timestamp at time zone 'Europe/Berlin';
timezone

 2023-10-29 03:30:00+01
(1 row)

Observe how the timesamp representation changes 
from '2023-10-29 01:59:59+02' to '2023-10-29 02:00:00+01'
and how UTC offset is there to make it very clear.

select '2023-10-29 01:59:59'::timestamp at time zone 'Europe/Berlin';
timezone

 2023-10-29 01:59:59+02
(1 row)

select '2023-10-29 02:00:00'::timestamp at time zone 'Europe/Berlin';
timezone

 2023-10-29 02:00:00+01
(1 row)

Above is happening because PostgreSQL observes time zone definition
and knows how to represent that timestamp correctly.

A looney program will not observe time zone, it will generate invalid
or ambigious timestamps.

Conclusion:
---

Do use looney programs.

Use timezone database information and international standards to
represent and exchange time related information.

> It would also be nice to eventually recognize, that we are talking
> about readable syntax for humans, that is sometimes generated,
> sometimes manually typed. Most of you comments does not really
> resonate with this crucial design goal.

Teach that human how to represent time correctly.

Teach computer program to help human to correct incorrectly hand
written timestamps to something that is reasonable, like Etar calendar
does that.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I think it is a good idea to document the reasoning for these
  > > decision.  But I think it does not necessarily have to be centralized
  > > in one file for all of Emacs.  Another alternative, also natural,
  > > would be to describe these decisions with the code that implements the
  > > support.

  > Will file header be a good place?

It's a reasonable candidate.

  > Note that there is little point adding the reasons behind supporting
  > non-free software if they cannot be easily found. Ideally, it should be
  > a standard place documented as code convention. Then, people can
  > consistently check the reasons (or lack of) behind each individual
  > non-free software support decision.

That is a valid point.

Sorry for the delay.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Max Nikulin]

On 03/02/2023 22:42, Bruno Barbier wrote:

Max Nikulin writes:

(with-eval-after-load 'ol
(org-link-set-parameters
 "mid"
 :follow (lambda (url  arg)
   (browse-url (concat "mid:" url) arg

Thunderbird opens mid: links in new message display tab or window.

Yes. If `browse-url' knows how to open Thunderbird (mine didn't).


On windows I expect fallback to `browse-url-default-windows-browser` by 
default. Are you able to open mid: links from e.g. cmd.exe?


open "mid:63dd2b57.050a0220.ed66f.0...@mx.google.com"

Looking into https://bugzilla.mozilla.org/show_bug.cgi?id=1696218
"Thunderbird displays the dialog for default application after each startup"
and the patch, I expect that thunderbird on windows can register 
protocol handler for the "mid" scheme.


Unsure however if the following entries in advanced preferences are 
relevant:


network.protocol-handler.expose.mid true
network.protocol-handler.external.mid   false

I have never debugged protocol handlers on windows. I would compare 
"mailto" and "mid" entries in the registry


https://stackoverflow.com/questions/80650/how-do-i-register-a-custom-url-protocol-in-windows


How do you think we should proceed to update the wiki ?


I am trying to determine if it is difficult to get mid scheme working 
system-wide and emacs-wide on windows. If not, I would just add your 
example "[[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]" to the 
remark related to copying Message-ID in the existing text and corrected 
a bit a note on obsolete thunderlink. If thunderbird still has issues 
with registering global mid: handler then your snippet with 
`start-process' should be added.


Maybe I just have gone too far trying to add "right" recommendation.

[BUG] org-publish does not obey org-footnote-section [9.6.1 ( @ /home/contrapunctus/.emacs.d/elpa/org-9.6.1/)]

[contrapunctus]

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 have org-footnote-section set to nil in my init.el.

If I export through the HTML or Tufte backends, my footnotes are not exported 
in a different section. However, with org-publish-project and with 
org-publish-project-alist having a value like -

(("project" :base-directory "/foo/bar/"
:publishing-directory "/foo/bar/"
:recursive t
:publishing-function org-html-publish-to-tufte-html))

...a section called Footnotes is created.

I have also tried setting org-footnote-section to nil in a .dir-locals.el, in 
the Org file itself as #+OPTION: org-footnote-section:nil, and as a property in 
org-publish-project-alist (:org-footnote-section nil)

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0)
 of 2023-01-18, modified by Debian
Package: Org mode version 9.6.1 ( @ 
/home/contrapunctus/.emacs.d/elpa/org-9.6.1/)

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Esteban Ordóñez]

El 2023-02-02 06:05, Ihor Radchenko escribió:
> Ihor Radchenko  writes:
> 
>> (your version)
>>
>> ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Duración" "TODO"
>>  "Duración total" "Tiempo archivo" "Generado el")
>>
>> or
>>
>> (Esteban's version)
>>
>> ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Tiempo" "TODO"
>>  "Tiempo total" "Tiempo de archivo" "Resumen de tiempos en")
>>
>> Note that "time" in English version refers to clocked time, which is
>> probably closer in its meaning to "duration" or "time spent".
>>
>> Pedro, Esteban, any comments?
> 
> No further response has been given. I arbitrarily went with Pedro's
> version.
> 
> Applied, on Pedro's behalf, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8ae8a8462

Did not see this message.  I agree that his version is better.  :-)

Re: bug#59882: Multiple versions of Org in load-path problem

[Tim Cross]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>> On 27/12/2022 16:47, Ihor Radchenko wrote:
>>> Can you then try to test using Emacs 28?
>>> The main question if whether this has been fixed in newer Emacs releases
>>> or it is also something to do with OS environment.
>>
>> I see quite the same issue with Emacs-28.2 in Debian testing. Compile 
>> buffer displays a bit more warnings and usual `org-assert-version' 
>> warnings and errors are present as well. It might have another level of 
>> complexity due to .eln files. I am unsure what happens with calls to 
>> undefined macros.
>
> I asked people around to test using Debian, and we do have a
> confirmation that Debian + Emacs 27 and Debian + Emacs 28 do trigger the
> error.
>
> I also installed Debian 11.6.0 on virtual machine, and I was also able to
> trigger the error, following the provided steps, using the Emacs 27
> installed via apt-get.
>
> The problem seems to be real and appears to be some combination of
> Debian/Ubuntu + Emacs.
>
> Considering the popularity of Debian-based distros, may someone take a
> closer look on what may be going on? Since the latest Emacs release also
> suffers from the problem, I am afraid that the issue will be present in
> the coming Emacs 29 as well (I recall no related fixes in recent Emacs).

I don't run Debian or Ubuntu anymore. However, I do recall that debian
does use a modified Emacs startup which is not part of the standard
Emacs distribution. They do this to enable the ability to have multiple
versions of Emacs installed at the same time.

If you are unable to reproduce the issue with an Emacs built from
sources and only from the versions of Emacs installed bia apt, then I
would be looking at the sources for the apt package and the modified
*.el files it uses as it could be something in there which is triggering
the issue (seem unlikely to be coincidence that a customization to allow
running of multiple versions is also triggering a version conflict in
org?)

. 

Re: [O] [PATCH] ob-eval: display error fix

[Andreas Gerler]

Hi Ihor,

way too busy right now.
As soon as I find some time I’ll rework that change. Might take a week or two.

so long...

Andreas Gerler

> On Jan 27, 2023, at 2:11 PM, Ihor Radchenko  wrote:
> 
> Andreas Gerler  writes:
> 
>> +(defcustom org-babel-eval-error-display-notify nil
>> +  "Display org-babel-eval-errors always or only if exit code is not 0."
> 
> This docstring is confusing. What will happen if the value is nil?
> non-nil? I cannot answer these questions by reading the docstring.
> 
> Also, what is "org-babel-eval-errors"? Symbol?
> 
> Finally, I do not think that "nil" is a good default here. It is better
> to display warnings by default and let people disable them only
> consciously, when needed. Ideally, we may allow the value to be a list
> of backends where to display/not display the warnings.
> 
>> +  :group 'org-babel
>> +  :version "29.1"
> 
> Please use :package-version instead.
> 
> And add the new customization to etc/ORG-NEWS.
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
> 

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Jean Louis  writes:

> Specifying time zone is not ambiguous as long as you use the TZ
> database for specifications!

That's wrong and you know it. For example

   [2023-10-29 02:30 @Europe/Berlin]

is ambiguous. Period.

And that some examples got a bit off has been quite obvious and has
already been stated. So its not necessary to flog dead horses.

It would also be nice to eventually recognize, that we are talking
about readable syntax for humans, that is sometimes generated,
sometimes manually typed. Most of you comments does not really
resonate with this crucial design goal.

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

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Bruno Barbier]

Max Nikulin  writes:

> On 02/02/2023 13:04, Bruno Barbier wrote:
>> As it's still not clear to me how to configure browse-url, I'm still relying
>> on start-process.
>
> Bruno, it seems I completely confused you by my comments. I am sorry for 
> that.

I was confused way before, trying to assemble a simple non-obsolete, not
OS specific method. No problem ;-)

> Does the method currently suggested by FAQ works for you? My particular 
> interest caused by your words that you use Thunderbird on Windows:
>
> (with-eval-after-load 'ol
>(org-link-set-parameters
> "mid"
> :follow (lambda (url  arg)
>   (browse-url (concat "mid:" url) arg
>
> Thunderbird opens mid: links in new message display tab or window.
Yes. If `browse-url' knows how to open Thunderbird (mine didn't).

> Does cb_thunderlink behave in the same way or it switches to proper
> folder and selects the message in the list of messages, so it appears
> in 3 pane view making other messages from the same thread directly
> accessible?

AFAIK, cb_thunderlink behaves like Thunderbird to open messages. Once
the message is displayed, you have to click in Thunderbird to see it in
its folder or in its conversation. That's why I removed my
cb_thunderlink native application; I will use only the add-on from now
on.

My own configuration is now a lot simpler. Thanks!


How do you think we should proceed to update the wiki ?


Bruno

Re: [BUG] #+cite_export: ... bibstyle citestyle cannot be universally used as global defaults (was: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite)

[Edgar Lux]

On Jan 24, 2023 at 11:54 AM, Ihor Radchenko  wrote:Edgar 
Lux  writes:

> I understand. My takeaway from here is that there is a need to provide
> extended global defaults for both bibliography style and citation style.
> 
> Which is a questionable design choice. I was referring to higher-level
> docstring for `org-cite-export-processors':
> 
>   (NAME BIBLIOGRAPHY-STYLE CITATION-STYLE)
> 
> There, NAME is the name of a registered citation processor providing
> export
> functionality, as a symbol.  BIBLIOGRAPHY-STYLE (respectively
> CITATION-STYLE)
> is the desired default style to use when printing a bibliography
> (respectively
> exporting a citation), as a string or nil.  Both BIBLIOGRAPHY-STYLE and
> CITATION-STYLE are optional.  NAME is mandatory.
> 
> oc-biblatex simply deviates from the global paradigm, making oc-biblatex
> special compared to other citation processors. Not ideal.
> 
> I think that we have a fundamental design flaw with org-cite:
> 
> #+cite_export: processor bibliography-style citation-style
> 
> introduces:
> 
>  - default bibliography style set document-wide
>  - default citation style set individually in every citation via
>   low-level commands, BUT NOT GLOBAL DEFAULT CITATION STYLE.
> 
> Basically, CITATION_STYLE cannot currently affect document preamble by
> design.
> 
> That's why awkward workarounds in oc-biblatex, where default citation
> style can be set globally, and we have to attach citation style to
> BIBLIOGRAPHY_STYLE keyword.
> 
> I suggest the following changes to the org-cite:
> 
> 1. :export-finalizer should accept export processor triplet instead of
>bibliography style as 4th argument. The assumption that only
>bibliography style is required to finalize the export is clearly not
>accurate.
> 
> 2. Allow passing extra arguments in #+cite_export:
> 
> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style[...]
> citation-style[...]
> 
>   The options listed within the square brackets will pass extra default
> options
>   to the processor/styles and used as needed by citation processor
> implementations.
> 
> WDYT?
> -- 
> Ihor Radchenko // yantar92,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Dear Ihor and Org mailing list,

I wanted to answer last weekend, because I had the intention to contribute a 
little in terms of code. However, I was very busy, and I will be very busy this 
weekend as well. All in all, the idea sounds great. I appreciate that my 
opinion is taken into account, but I know very little about citation systems. I 
was only a bit concerned about the effort which is needed to implement the 
changes, as little as they may be. 



-- 
Sent with https://mailfence.com  
Secure and private email

Re: org-clock idle time in pgtk Emacs

[Max Nikulin]

On 03/02/2023 19:17, Ihor Radchenko wrote:

Julien Cubizolles writes:


May I know where "jc-idle-time" is coming from? Is it a built-in command
on wayland?


Sorry, I forgot to mention. It's a custom python program, working both
in X11 and wayland. I didn't find a built-in command.


I would prefer something built-in or, at least, available via OS'
package manager.


It seems, one can obtain the python package using

pip install idle-time

https://pypi.org/project/idle-time/

The issue is that the project has just 2 commits, a pull request for 
wider support of various environments is ignored by the author. The 
package already has CLI interface, but output format is not script-friendly:


https://github.com/escaped/idle_time/blob/master/idle_time/__main__.py
print(f"Idle time: {monitor.get_idle_time()}s")

python3 -m idle-time


This does not look pgtk-specific. Is it?


I see X11 and Windows in the implementation. xprintidle might be more 
reliable though.


As to Org my opinion is still that a defcustom for user-defined function 
returning idle may be a better option.

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Max Nikulin]

On 02/02/2023 13:04, Bruno Barbier wrote:

As it's still not clear to me how to configure browse-url, I'm still relying
on start-process.


Bruno, it seems I completely confused you by my comments. I am sorry for 
that.


Does the method currently suggested by FAQ works for you? My particular 
interest caused by your words that you use Thunderbird on Windows:


(with-eval-after-load 'ol
  (org-link-set-parameters
   "mid"
   :follow (lambda (url  arg)
 (browse-url (concat "mid:" url) arg

Thunderbird opens mid: links in new message display tab or window. Does 
cb_thunderlink behave in the same way or it switches to proper folder 
and selects the message in the list of messages, so it appears in 3 pane 
view making other messages from the same thread directly accessible?

Re: [patch] improved: add TTL as defcustom to ox-icalendar

[Detlef Steuer]

Am Tue, 17 Jan 2023 10:30:07 +
schrieb Ihor Radchenko :

> Detlef Steuer  writes:
> 
> >> The patch only allows to the TTL globally for all the calendars.
> >> However, it would make sense to specify TTL on per-file basis.
> >> WDYT? 
> >
> > Hmm. Surely it would be useful to have the option to use different
> > TTL settings for different calendar exports, yes.
> >
> > The next question would be, if org-icalendar-combine-agenda-files is
> > called and the files have different per-file settings, which will be
> > used?  
> 
> The only sane way would be using the global default.
> 
> > May be single file org-icalendar-export-to-ics and
> > org-icalender-export-agenda-files use an existing per-file setting,
> > global setting otherwise, but org-icalendar-combine-agenda-files
> > always uses the global setting?  
> 
> Agree.
> 
> To achieve this you just need to update the export option settings:
> 
> (:icalendar-ttl nil nil org-icalendar-ttl)
> 
> adding a file keyword to be used.
> See `org-export-options-alist' docstring.
> 

Hi Ihor, 

I hope I understood your advice and the docstring and examples in other
exporters correctly. Is it really that easy?

Next iteration of the patch.

Detlef

>From 0af9cf3d1e742271531f047f2ed0a690a81261c7 Mon Sep 17 00:00:00 2001
From: Detlef Steuer 
Date: Fri, 3 Feb 2023 14:11:00 +0100
Subject: [PATCH 1/2] Add TTL to icalendar export options

---
 lisp/ox-icalendar.el | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 81a77a770..600eaae24 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -297,6 +297,21 @@ Interesting value are:
 	  (const :tag "Universal time" ":%Y%m%dT%H%M%SZ")
 	  (string :tag "Explicit format")))
 
+(defcustom org-icalendar-ttl "PT1H"
+  "The time to life for the exported calendar.
+Subscribing clients to the exported ics file can derive the time interval
+to read the file again from the server. One example of such a client is
+the nextcloud calendar, which respects the setting of
+X-PUBLISHED-TTL, i.e. X-PUBLISHED-TTL:PT1H .
+
+See https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html
+for a complete description of possiblee values of this option. I.e.
+PT1H stands for 1 hour, PT0H27M34S for 0 hours, 27 minutes and 34 seconds.
+
+This option can also be set with the ICAL-TTL keyword."
+  :group 'org-export-icalendar
+  :type 'string)
+
 (defvar org-icalendar-after-save-hook nil
   "Hook run after an iCalendar file has been saved.
 This hook is run with the name of the file as argument.  A good
@@ -333,6 +348,7 @@ re-read the iCalendar file.")
 (:icalendar-timezone nil nil org-icalendar-timezone)
 (:icalendar-use-deadline nil nil org-icalendar-use-deadline)
 (:icalendar-use-scheduled nil nil org-icalendar-use-scheduled)
+(:icalendar-ttl "ICAL-TTL" nil org-icalendar-ttl)
 (:icalendar-scheduled-summary-prefix nil nil org-icalendar-scheduled-summary-prefix)
 (:icalendar-deadline-summary-prefix nil nil org-icalendar-deadline-summary-prefix))
   :filters-alist
@@ -872,13 +888,16 @@ as a communication channel."
(or (org-string-nw-p org-icalendar-timezone) (format-time-string "%Z"))
;; Description.
(org-export-data (plist-get info :title) info)
+   ;; TTL
+   org-icalendar-ttl
contents))
 
-(defun org-icalendar--vcalendar (name owner tz description contents)
+(defun org-icalendar--vcalendar (name owner tz description ttl contents)
   "Create a VCALENDAR component.
-NAME, OWNER, TZ, DESCRIPTION and CONTENTS are all strings giving,
+NAME, OWNER, TZ, DESCRIPTION, TTL and CONTENTS are all strings giving,
 respectively, the name of the calendar, its owner, the timezone
-used, a short description and the other components included."
+used, a short description, the time-to-live resp. refresh period and 
+the other components included."
   (concat (format "BEGIN:VCALENDAR
 VERSION:2.0
 X-WR-CALNAME:%s
@@ -1018,6 +1037,7 @@ This function assumes major mode for current buffer is
 	user-full-name
 	(or (org-string-nw-p org-icalendar-timezone) (format-time-string "%Z"))
 	org-icalendar-combined-description
+	org-icalendar-ttl
 	contents)))
 (run-hook-with-args 'org-icalendar-after-save-hook file)))
 
@@ -1042,6 +1062,8 @@ FILES is a list of files to build the calendar from."
 		  (format-time-string "%Z"))
 	  ;; Description.
 	  org-icalendar-combined-description
+	  ;; TTL (Refresh period)
+	  org-icalendar-ttl
 	  ;; Contents.
 	  (concat
 	   ;; Agenda contents.
-- 
2.39.1

>From 2a1376457a7d09b6586bea55061aa0aa99509106 Mon Sep 17 00:00:00 2001
From: Detlef Steuer 
Date: Fri, 3 Feb 2023 14:20:52 +0100
Subject: [PATCH 2/2] Add entry for new org-icalendar-ttl option to ORG-NEWS

---
 etc/ORG-NEWS | 17 +
 1 file changed, 17 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 40477e73f..c10f95d67 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -24,6 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-01 14:12]:
> Let me try to explain better. Just specifying time zone is ambiguous
> once per year during daylight transition.

For reason to make it unambiguous, people (representatives of
countries in international associations) are creating the TZ database,
and maintaining it.

Specifying time zone is not ambiguous as long as you use the TZ
database for specifications!

> [2023-03-29 02:30 @Europe/Berlin] is special.

I may only guess you wanted to specify the last Sunday in March 2023,
where there is UTC offset shift.

Your time stamp above is very valid, but you probably wanted to point
out to the alleged problem with the daylight savings.

The time stamp you maybe wanted to demonstrate would be:

2023-03-26 02:30 @Europe/berlin

It is not special case!

It is INVALID time stamp. 

It does not exist in the context of internationally agreed time.

In the context of this e-mail, you may write what you want, but you
are arguing about something that does not exist.

Things that do not exist, do not make you a problem. 

The only thing that could be ambiguous is the hypothetical, imaginary,
lousy software that generates invalid time stamps like that.

You are bringing up the problem which in the human agreed reality does
not exist.

> According to https://www.timeanddate.com/time/zone/germany/berlin,
> 2023-03-29 is the time when the clock is shifted one hour back due to
> the daylight saving transition. The wall time goes like
> 
> 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... ->
> 2:30 (again!)

I got your point, even though you are showing invalid time stamp. 

And that is not a problem, because TZ database specifies exactly how
to calculat time.

If you however, use time zones but do not use time zone database,
well, that is case of bad program design, and your program, and
anything you do in that program will become ambigous as well.

> So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points:
> before and after the transition.

1. Your timestamp is wrong for demonstration purposes, the time stamp
   you are displaying is not related to daylight savings shift.

2. The time stamp for demonstration should be: 
   2023-03-26 02:30 @Europe/berlin

3. The time stamp above, in the number (2) of this list, IS INVALID.

4. Recommendation is to stop using lousy programs generating invalid
   time stamps.

> Specifying explicit offset is thus necessary in this specific
> scenario to disambiguate the timestamp:

That specification of UTC offset is necessary is out of any doubt.

But you have formed your decision in invalid timestamp and lousy
programs, thus further conclusions based on such decisions cannot be
relevant, and people shall be cautious regarding conclusions that were
based on wrong and correct time stamp, where author wanted to point
out to daylight savings shift time stamp, whereby such time stamp is
invalid and as time representation does not exist.

It is because you do not need to worry how time zone is ambigous,
because it is not. Please read specification of the time zone
definition. It has been defined to solve this type of problems for
people.

> [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
> [2023-03-29 02:30+1 @Europe/Berlin] (after transition)

Both of the above time stamps do not exist, both are valid.

If you meant daylight savings time stamps, then you maybe wanted to
say following:

> [2023-03-26 02:30+2 @Europe/Berlin] (before transition)
> [2023-03-26 02:30+1 @Europe/Berlin] (after transition)

However, above time stamps are INVALID. 

You deal with non-existent problem.

There is nothing to solve there.

Practical exercises for people to understand it:


Go in shell:

# Following will set your user's time zone to Europe/Berlin, that
# indicates that programs shall look for time zone specification, such
# as the one in /usr/share/zoneinfo/Europe/Berlin

$ export TZ=Europe/Berlin

# In the next step, setup the date:

$ sudo date -s '20230326 0159'
Sun Mar 26 01:59:00 AM CET 2023

# Ask for current time stamp from system

$ date
2023-03-26-01:59:22-Sunday

# Sorry that I have peculiar system time stamp personally, it is
# because I often use it to generate files

# Let us see it without my customization

$ /usr/bin/date
Sun Mar 26 01:59:06 AM CET 2023

# Let us repeat it, while we let time running:

$ /usr/bin/date
Sun Mar 26 01:59:32 AM CET 2023

# Observe what is happening:

$ /usr/bin/date
Sun Mar 26 01:59:58 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 01:59:58 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 01:59:59 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 03:00:00 AM CEST 2023

Did we arrive to 02:30? No. Why?

How about setting up the date to the imaginary "ambigous" and invalid
time stamp:

$ sudo date -s '20230326 0200'
date: invalid date ‘20230326 0200’

$ sudo date -s '20230326 0230'
date: invalid date ‘20230326 0230’

Hmm. Maybe the GNU `date' command simply does it's job 

Re: Internal links to lines in different org files

[kevin lucas]

Thanks for responding. I meant specifically the :: syntax with org IDs, and
not filenames. I did confirm that this feature is currently only in Doom
Emacs, see:
https://github.com/doomemacs/doomemacs/blob/master/modules/lang/org/config.el#L639-L659
Regarding org-export-with-broken-links, is there a way to export the text
of the link, and not kill all the text?

On Wed 1. Feb 2023 at 15:55, Ihor Radchenko  wrote:

> kevin lucas  writes:
>
> > 1. Is this feature indeed specific to Doom Emacs?
> > 2. If this behavior isn’t in org mode, could it be added?
>
> No. It is built-in.
>
> > 3. Connected to this: if I export an org file containing an ordinary link
> > to another node to PDF, the PDF compiles and I get a dead link in the
> file.
> > If one tries to export org files with these double colon links there's an
> > error message `Unable to resolve ID "foo::myname"`. Is there a way to
> > generate the PDF just like in the first case?
>
> See org-export-with-broken-links
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Re: [ANN] Looking for new maintainers for ox-latex.el (LaTeX export library)

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> I'm certainly time-limited, but use ox-latex and ox-beamer profusely and in
> parallel with "pure" LaTEX - whatever you might understand by "pure" ;-)
> will be close enough - I could also help when my lectures permit and yes, I
> also follow the list

Thanks!
So, we have 3 volunteers now ☺️

Just in case, ob-latex, oc-natbib, oc-bibtex, an oc-biblatex also don't
have active maintainer now. We are certainly not in shortage of
LaTeX-related things to be taken care of. Especially for citations,
which are still not fully documented.

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

Re: org-clock idle time in pgtk Emacs

[Ihor Radchenko]

Julien Cubizolles  writes:

>> May I know where "jc-idle-time" is coming from? Is it a built-in command
>> on wayland?
>
> Sorry, I forgot to mention. It's a custom python program, working both
> in X11 and wayland. I didn't find a built-in command.

I would prefer something built-in or, at least, available via OS'
package manager.

> --8<---cut here---start->8---
> #!/usr/bin/env python3
>
> from idle_time import IdleMonitor
>
> monitor = IdleMonitor.get_monitor()
> print(f"{1000*monitor.get_idle_time():.0f}")
> --8<---cut here---end--->8---

This does not look pgtk-specific. Is it?

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

Re: bug#59882: Multiple versions of Org in load-path problem

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: Stefan Monnier , emacs-orgmode@gnu.org, Eli
>  Zaretskii , 59...@debbugs.gnu.org
> Date: Fri, 03 Feb 2023 11:02:21 +
> 
> Considering the popularity of Debian-based distros, may someone take a
> closer look on what may be going on? Since the latest Emacs release also
> suffers from the problem, I am afraid that the issue will be present in
> the coming Emacs 29 as well (I recall no related fixes in recent Emacs).

I don't know enough about package.el's peculiarities, sorry.  And my
plate is too full ATM.  So I'm afraid someone else will have to
investigate this.  (I think Debian downstream maintainers are the
natural candidates, so I've taken the liberty of CC'ing them.)

Re: org-clock-sum-today performance

[Ihor Radchenko]

Tijs Mallaerts  writes:

> This is the profiler report:

Thanks!
Do I understand correctly that `org-element-use-cache' is set to nil for you?

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

Re: [BUG] list.orgmode.org managed to parse a message in future: 2023-10-29 [9.6.1 (release_9.6.1-223-gc8d20d @ /home/yantar92/.emacs.d/straight/build/org/)]

[Jean Louis]

* Ihor Radchenko  [2023-02-03 14:13]:
> Hi,
> 
> We currently have a message in future on top of
> https://list.orgmode.org/
> 
> The message is
> https://list.orgmode.org/ZT2vNKsf3Lp5xit3@protected.localdomain/raw, and
> it does not contain the future dates in headers. Just in the body.
> 
> Are we observing public inbox bug?

Sorry for that. It was not intentional. It happened during the
exercises.

I went to future, and wrote from there. ☺️ 

Now it is pending until the future time stamp.

Similarly, I have made mess with Dino XMPP messenger as well, I have
sent message from future, now that message will appear to me for years
as the last message sent, no matter what I do, that message remains
pending!

Why did mailing list accept message from far future? It should not be
so, that is bug to be reported.

Dino messenger accepted message from far future, that is bug, and I
have reported it: 
https://github.com/dino/dino/issues/1355


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-02 11:38]:
> Jean Louis  writes:
> 
> > * Ihor Radchenko  [2023-02-01 15:23]:
> >> [2022-11-12 14:00 @UTC+2]
> >> [2022-11-12 14:00 @UTC-2:30]
> >> 
> >> are also fine within the proposed format.
> >
> > The above format is unclear to me. I look at timestamps every day, too
> > many, often change them.
> >
> > I cannot understand what you mean.
> 
> See "std offset" format for TZ environment variable.
> https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

I understand that information on hyperlink.

I do not understand how it is related to "UTC", a with "UTC" people do
not put UTC offset.

It is either UTC as time zone and offset can be considered only ZERO,
like +0, or it is NOT UTC as time zone, and there is offset to
understand what was really the UTC. This latter is also explained in
that hyperlink.

So what do you really mean with such time stamp?

I think it is incorrect time stamp. If you specify UTC, you do not
specify UTC offset. 

There is no UTC offset for UTC time.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Properly handle defaults in org-set-property

[Ihor Radchenko]

Janek F  writes:

> 1. Put the cursor on a heading that does not have an id
> 2. Invoke (org-set-property "ID" (org-read-property-value "ID" nil 
> "default-value")) via keybind or Alt-:
> 3. default-value is not within the list of suggestions

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0522c1850

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

Re: [PATCH] org-agenda-filter-by-category: fix 'no category' error

[Ihor Radchenko]

Liu Hui  writes:

> To reproduce the bug:
> ...
> Subject: [PATCH] org-agenda: Fix `org-agenda-filter-by-category'

Thanks for reporting and providing a fix!
Applied, onto bugfix, adding link to this message to the commit message.
Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3e23b8976

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

Re: When is a function an interactive function? [was Re: Is function 'org-insert-property-drawer' usable?]

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> For example, with the cursor on 'org-capture-finalize' in the manual,
> 'C-h f ' gives nothing right away; 'C-h f org-capture' does
> not offer 'org-capture-finalize' as a completion; 'C-h f
> org-capture-fin' does complete and says that
> 'org-capture-finalize' is interactive; and then it becomes possible to
> use it with 'M-x'.

This is Emacs bug.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60085

> Similarly, as far I as can see, 'M-x org-attach-attach' fails right
> away, but works after having been used once with the standard (menu)
> way.

I guess we can make this function autoloaded.
Are there are any other function that you often try to call via M-x and
miss?

> List (of non interactive functions that might be thought interactive
> to the ignorant):
>
> - ‘C-u C-u ’ (‘org-set-startup-visibility’)

What about doing something like

- ‘C-u C-u ’ (‘org-cycle’ ⟶ ‘org-set-startup-visibility’)

There is no reason to make some of the listed functions interactive -
they are not designed to be interactive.

> - ‘S-’ (‘org-property-next-allowed-values’) 
>
>   Shouldn't it be 'org-property-next-allowed-value'?
>
> - ‘U’ (‘org-agenda-bulk-remove-all-marks’) 
>
>   Shouldn't it be 'org-agenda-bulk-unmark-all'?
>
> - ‘C-c C-e’ (‘org-export’) 
>
>   Shouldn't this one be 'org-export-dispatch'?
>
> - ‘C-c '’ (‘org-edit~special’) 
>
>   This must be a typo, right?
>
> - ‘C-c C-e o o’ (‘org-export-to-odt’) 
>
>   Shouldn't it be 'org-odt-export-to-odt'?

Fixed, on bugfix. Thanks!
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f33d24108

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

[BUG] list.orgmode.org managed to parse a message in future: 2023-10-29 [9.6.1 (release_9.6.1-223-gc8d20d @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Hi,

We currently have a message in future on top of
https://list.orgmode.org/

The message is
https://list.orgmode.org/ZT2vNKsf3Lp5xit3@protected.localdomain/raw, and
it does not contain the future dates in headers. Just in the body.

Are we observing public inbox bug?

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

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Kevin Brubeck Unhammer]

> 1. I think "ALT" should be "ALLE" as in "alle filene" (the documentation
> says "ALL" refers to "All files when clock table includes multiple
> files").
>
> 2. I like "Tid stempla", but "Tidsoversyn" or "Tidssamandrag" would stick
> closer to the original and be clearer, I think.
>
> 3. I think "ved" should be omitted. It's not used before dates ("den
> 3.2.2023" but preferably just "3.2.2023"), days ("på fredag") or times
> ("klokka 14:00", "kl. 14:00", "14:00"). It's generally safe to omit it:
> "Tidsoversyn [2023-02-03 Fri 14:00]" would be clear. If a preposition is
> wanted, the entire date could be read "fredag 3.2.2023 kl. 14:00", so
> the "på" before weekday would work, I guess.

That sounds good to me. With those changes we have

  (setq org-clock-clocktable-language-setup
'(

  ("nn" "Fil"  "N"  "Tidspunkt" "Overskrift" "Tid" "ALLE" "Total 
tid" "Filtid" "Tidsoversyn")

  ))



signature.asc
Description: PGP signature

Re: bug#59882: Multiple versions of Org in load-path problem

[Ihor Radchenko]

Max Nikulin  writes:

> On 27/12/2022 16:47, Ihor Radchenko wrote:
>> Can you then try to test using Emacs 28?
>> The main question if whether this has been fixed in newer Emacs releases
>> or it is also something to do with OS environment.
>
> I see quite the same issue with Emacs-28.2 in Debian testing. Compile 
> buffer displays a bit more warnings and usual `org-assert-version' 
> warnings and errors are present as well. It might have another level of 
> complexity due to .eln files. I am unsure what happens with calls to 
> undefined macros.

I asked people around to test using Debian, and we do have a
confirmation that Debian + Emacs 27 and Debian + Emacs 28 do trigger the
error.

I also installed Debian 11.6.0 on virtual machine, and I was also able to
trigger the error, following the provided steps, using the Emacs 27
installed via apt-get.

The problem seems to be real and appears to be some combination of
Debian/Ubuntu + Emacs.

Considering the popularity of Debian-based distros, may someone take a
closer look on what may be going on? Since the latest Emacs release also
suffers from the problem, I am afraid that the issue will be present in
the coming Emacs 29 as well (I recall no related fixes in recent Emacs).

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

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Christian Moe]

Hi, Kevin,

A couple of considerations:

1. I think "ALT" should be "ALLE" as in "alle filene" (the documentation
says "ALL" refers to "All files when clock table includes multiple
files").

2. I like "Tid stempla", but "Tidsoversyn" or "Tidssamandrag" would stick
closer to the original and be clearer, I think.

3. I think "ved" should be omitted. It's not used before dates ("den
3.2.2023" but preferably just "3.2.2023"), days ("på fredag") or times
("klokka 14:00", "kl. 14:00", "14:00"). It's generally safe to omit it:
"Tidsoversyn [2023-02-03 Fri 14:00]" would be clear. If a preposition is
wanted, the entire date could be read "fredag 3.2.2023 kl. 14:00", so
the "på" before weekday would work, I guess.

Yours,
Christian


Kevin Brubeck Unhammer writes:

>> (defcustom org-clock-clocktable-language-setup
>> Contributions for other languages are also welcome.
>
> Here's Norwegian Nynorsk:
>
>   (setq org-clock-clocktable-language-setup
> '(
>
>   ("nn" "Fil"  "N"  "Tidspunkt" "Overskrift" "Tid" "ALT" "Total 
> tid" "Filtid" "Tid stempla ved")
>
>   ))
>
> Looking forward when I can delete that line from my init.el :)

Re: [HELP] Things to help Org that do not involve programming

[Kevin Brubeck Unhammer]

>>> More things also require translation in `org-export-dictionary'.

The missing Norwegian Nynorsk "nn" org-export-dictionary entries:

(
 ("Continued from previous page"
  ("nn" :default "Held fram frå førre side"))
 ("Continued on next page"
  ("nn" :default "Held fram på neste side"))
 ("Created"
  ("nn" :default "Oppretta"))
 ("List of Listings"
  ("nn" :default "Programliste"))
 ("Listing"
  ("nn" :default "Program"))
 ("Listing %d:"
  ("nn" :default "Program %d:"))
 ("References"
  ("nn" :default "Kjelder"))
 ("See figure %s"
  ("nn" :default "Sjå figur %s"))
 ("See listing %s"
  ("nn" :default "Sjå program %s"))
 ("See section %s"
  ("nn" :default "Sjå del %s"))
 ("See table %s"
  ("nn" :default "Sjå tabell %s"))
 ("Table"
  ("nn" :default "Tabell"))
 ("Unknown reference"
  ("nn" :default "Ukjend kjelde"))
  )


signature.asc
Description: PGP signature

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Kevin Brubeck Unhammer]

> (defcustom org-clock-clocktable-language-setup
> Contributions for other languages are also welcome.

Here's Norwegian Nynorsk:

  (setq org-clock-clocktable-language-setup
'(

  ("nn" "Fil"  "N"  "Tidspunkt" "Overskrift" "Tid" "ALT" "Total 
tid" "Filtid" "Tid stempla ved")

  ))

Looking forward when I can delete that line from my init.el :)


signature.asc
Description: PGP signature