Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Max Nikulin]

On 31/01/2023 15:11, Charles Philip Chan wrote:

According to the author, bookmarklets are getting less
and less useful because CSP (Content Security Policy) blocking them on many
sites (for example Github)[2].
[2]  https://github.com/vifon/org-protocol-for-firefox


Have you experienced the issue with simple bookmarklets, similar to ones 
suggested in the Org manual, after the following fix?


https://bugzilla.mozilla.org/show_bug.cgi?id=1478037
Bug 1478037 Allow bookmarklets to run even when the CSP on the page 
would normally block javascript: execution

Fixed in Firefox-69 2019-05-31 14:56 PDT

If I understand it correctly, the problem persists with bookmarklets 
injecting 3rd party scripts into current page, see


https://bugzilla.mozilla.org/show_bug.cgi?id=866522
Bug 866522 Bookmarklets affected by CSP

So the popup to confirm launching external protocol handler may be 
considered annoying, but bookmarklets are not really broken. An add-on 
may improve user experience.


Likely mentioning browser extensions in the manual is the way to fix 
this bug in the scope of Org. Unsure if a link to 
https://chrome.google.com/webstore/ may be considered as promoting of 
non-free software (Google Chrome) by a GNU project.

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

[Max Nikulin]

On 05/02/2023 04:38, Ypo wrote:


If I wanted to assist to a "Mastering Emacs book club" meeting in 
America/Vancouver, while living in Spain: Doubt: Should I use local time 
of America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 
@America/Vancouver] (I don't like space before the @, for the Poll).


Below is my vision. Others may have their own opinions concerning 
particular details.


Depending of choice of persons in charge of this event you should add to 
your .org file either
- <2024-02-04 12:00 @America/Vancouver> if convenience of local 
participants is the most important point
- <2024-02-04 Sun 20:00:00 @Z> == <2024-02-04 Sun 12:00:00 @-0800> if 
enough online participants are expected, so the time is fixed for 
everybody independently of possible changes of the America/Vancouver 
time zone.


You may add <2024-02-04 do. 21:00>, but it will increase maintenance 
burden, see below.


1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 
21:00]. (Spain local time). Correct?


Agenda may display timestamps in your current time zone using overlays 
or just by formatting during generation of agenda.


2. If I went on vacation to Brasília, my agenda timestamp should change 
to: [2024-02-04 do. 17:00]. (Brasília local time).
    Doubt: How must the local time zone be updated to get that timestamp 
changed?


If you have in your file either <2024-02-04 12:00 @America/Vancouver> or 
<2024-02-04 Sun 20:00:00 @Z> then you do not need to update anything. 
You just set your current time zone to proper location in Brazil (and 
perhaps regenerate agenda)


3. Back to Spain, I see that, for political reasons, Vancouver's winter 
time-zone changed from UTC-8 to UTC-9.

    Doubt: How would my tz database be updated?


On Linux tzdata package is updated several times every year, this case 
you just need to keep your system up to date.


    Doubt: After updating the tz database, my agenda timestamp would 
change automatically to  [2024-02-04 do. 22:00]. Correct?


If you saved the event as <2024-02-04 do. 21:00> certainly it is up to 
you to find an update entries (and unsure that no timestamps is updated 
twice) to <2024-02-04 do. 22:00>. In the case of <2024-02-04 12:00 
@America/Vancouver> or <2024-02-04 Sun 20:00:00 @Z> just regenerate 
agenda after update of time zone database (perhaps emacs restart will be 
required).


4. For the Poll: What would be the expected behavior if we used the UTC 
offset?  [2024-02-04 12:00 @-08,America/Vancouver]

     - We should know beforehand the DST of Vancouver,


Obtaining offset from UTC is not a problem:

LANG=en_US.UTF-8 TZ=America/Vancouver date  -d '2024-02-04 12:00' '+<%F 
%a %T @%z>'

<2024-02-04 Sun 12:00:00 @-0800>

or there would be 
warnings. It seems more difficult for the user: maybe the "-08," should 
be optional?


I expect that both time zone identifier and offset are added either to 
resolve ambiguity of local time around change of time offset or to catch 
updates of timezone database. In the latter case it is optional, but it 
helps to notify you that event time is updated.


     - Case 3: After updating the tz database we would get warnings too. 
To correct those warnings, should the UTC offset be changed manually in 
the timestamp?. If there were 35 meetings in Vancouver throughout the 
year, to change all the UTC offsets could be non trivial for a normal 
user: UTC of the summer and winter would differ.


org-lint may present list of inconsistent timestamps. I am afraid, in 
some cases you will have to contact organizers to ensure that event was 
scheduled correctly (either in respect to local time or bound to UTC). 
Communications may require significantly more efforts than fixing 3 
dozens of timestamps.

Re: netspend table

[Jude DaShiell]

Thanks much for your help on this problem.  I've never done anything with
ledger-cli yet and wasn't aware such a package existed.



Jude 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Sun, 5 Feb 2023, Dr. Arne Babenhauserheide wrote:

>
> Jude DaShiell  writes:
>
> > This is a running balance table and I don't know what kind of a #TBLFMT
> > line would be useful for that either.
> >
> > | date | transaction  | amount |   fee | balance |
> > |--+--++---+-|
> > | [2023-01-11] | original balance |  +0.00 | +0.00 | +423.17 |
> > | [2023-01-12] | dunkin   | -18.68 | -1.00 |  403.49 |
> > | [2023-01-13] | WalMart  | -28.68 | -1.00 |  384.88 |
> > | [2023-01-16] | Deposit  |  + |   |  634.88 |
> > | [2023-01-17] | Capris   |  - | - |  615.34 |
> > | [2023-01-17] | Mcdonalds|  -4.74 | -1.00 |  609.60 |
> > | [2023-01-18] | verizon  |  - | - |  543.35 |
> > | [2023-01-26] | dunkin   |  - | - |  542.37 |
> > | [2023-02-01] | damgoodcafe  | -13.28 | -1.00 |  528.09 |
> > |  |  ||   | |
>
> One thing I could see as useful is a check column to enusre that
>
> balance - amount - fee actually gives the previous balance:
>
> | date | transaction  | amount |   fee | balance |  check |
> |--+--++---+-+|
> | [2023-01-11] | original balance |  +0.00 | +0.00 | +423.17 | 423.17 |
> | [2023-01-12] | dunkin   | -18.68 | -1.00 |  403.49 | 423.17 |
> | [2023-01-13] | WalMart  | -28.68 | -1.00 |  384.88 | 414.56 |
> | [2023-01-16] | Deposit  |  + |   |  634.88 | 634.88 |
> | [2023-01-17] | Capris   |  - | - |  615.34 | 615.34 |
> | [2023-01-17] | Mcdonalds|  -4.74 | -1.00 |  609.60 | 615.34 |
> | [2023-01-18] | verizon  |  - | - |  543.35 | 543.35 |
> | [2023-01-26] | dunkin   |  - | - |  542.37 | 542.37 |
> | [2023-02-01] | damgoodcafe  | -13.28 | -1.00 |  528.09 | 542.37 |
> |  |  ||   | |  0 |
> #+TBLFM: $6='(- $5 $4 $3);N
>
> As you can see, The balance after WalMart does not add up, so I think
> this could be a good check to have.
>
> > Suggestions for any other improvements I could make on this table will be
> > appreciated and implemented if possible.
>
> I use ledger-cli for such tables which can generate suitable output.
>
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ledger.html
> https://www.ledger-cli.org/3.0/doc/ledger3.html#Org-mode-with-Babel
>
> You could do some clever stuff like
>
> #+name: ledger-to-table
> #+begin_src elisp :var data=""
> (concat "#+name: ledger-results\n"
>   data
>   "#+tblfm: \n"))
> #+end_src
>
> #+begin_src ledger :results raw :post ledger-to-table(*this*) :cmdline 
> --register-format "| %(format_date(date)) | %(payee) | %(display_account) | 
> %(display_amount) | %(display_total) | \n" reg -M --wide --date-format 
> %y-%m-%d
> 2022-06-15 * py2guile
> ArneBab:Assets:Autorenhonorar:epubli 3.13?
> ArneBab:Income:sale:nonrpg:epubli
> #+end_src
>
>
>
> #+begin_src elisp :exports results
> (org-babel-do-load-languages
>  'org-babel-load-languages
>  '((ledger . t) ;this is the important one for this tutorial
>   ))
> nil
> #+end_src
>
> #+RESULTS:
>
> If you use ledger-cli for accounting, you can do pretty clever
> post-processing inside org-mode. Here?s an example that uses
> [[https://www.ledger-cli.org/3.0/doc/ledger3.html#Output-customization][--register-format]]
>  to provide the register results directly as an
> org-mode table:
>
> #+begin_src org
> ,#+name: ledger-to-table
> ,#+begin_src elisp :var data=""
> (concat "#+name: ledger-results\n"
>   data
>   "#+tblfm: \n"))
> ,#+end_src
>
> ,#+begin_src ledger :results raw :post ledger-to-table(*this*) :cmdline 
> --register-format "| %(format_date(date)) | %(payee) | %(display_account) | 
> %(display_amount) | %(display_total) | \n" reg -D --wide --date-format 
> %Y-%m-%d
> 2022-06-15 * py2guile
> ArneBab:Assets:Autorenhonorar:epubli 3.13?
> ArneBab:Income:sale:nonrpg:epubli
> ,#+end_src
>
> #+end_src
>
> This results in output like this (evaluated live on every export of this 
> website):
>
> #+name: ledger-to-table
> #+begin_src elisp :var data=""
> (concat "#+name: ledger-results\n"
>   data
>   "#+tblfm: \n"))
> #+end_src
>
> #+begin_src ledger :results raw :post ledger-to-table(*this*) :cmdline 
> --register-format "| %(format_date(date)) | %(payee) | %(display_account) | 
> %(display_amount) | %(display_total) | \n" reg -D --wide --date-format 
> %Y-%m-%d
> 2022-06-15 * py2guile
> 

Re: netspend table

[Dr. Arne Babenhauserheide]

Jude DaShiell  writes:

> This is a running balance table and I don't know what kind of a #TBLFMT
> line would be useful for that either.
>
> | date | transaction  | amount |   fee | balance |
> |--+--++---+-|
> | [2023-01-11] | original balance |  +0.00 | +0.00 | +423.17 |
> | [2023-01-12] | dunkin   | -18.68 | -1.00 |  403.49 |
> | [2023-01-13] | WalMart  | -28.68 | -1.00 |  384.88 |
> | [2023-01-16] | Deposit  |  + |   |  634.88 |
> | [2023-01-17] | Capris   |  - | - |  615.34 |
> | [2023-01-17] | Mcdonalds|  -4.74 | -1.00 |  609.60 |
> | [2023-01-18] | verizon  |  - | - |  543.35 |
> | [2023-01-26] | dunkin   |  - | - |  542.37 |
> | [2023-02-01] | damgoodcafe  | -13.28 | -1.00 |  528.09 |
> |  |  ||   | |

One thing I could see as useful is a check column to enusre that

balance - amount - fee actually gives the previous balance:

| date | transaction  | amount |   fee | balance |  check |
|--+--++---+-+|
| [2023-01-11] | original balance |  +0.00 | +0.00 | +423.17 | 423.17 |
| [2023-01-12] | dunkin   | -18.68 | -1.00 |  403.49 | 423.17 |
| [2023-01-13] | WalMart  | -28.68 | -1.00 |  384.88 | 414.56 |
| [2023-01-16] | Deposit  |  + |   |  634.88 | 634.88 |
| [2023-01-17] | Capris   |  - | - |  615.34 | 615.34 |
| [2023-01-17] | Mcdonalds|  -4.74 | -1.00 |  609.60 | 615.34 |
| [2023-01-18] | verizon  |  - | - |  543.35 | 543.35 |
| [2023-01-26] | dunkin   |  - | - |  542.37 | 542.37 |
| [2023-02-01] | damgoodcafe  | -13.28 | -1.00 |  528.09 | 542.37 |
|  |  ||   | |  0 |
#+TBLFM: $6='(- $5 $4 $3);N

As you can see, The balance after WalMart does not add up, so I think
this could be a good check to have.

> Suggestions for any other improvements I could make on this table will be
> appreciated and implemented if possible.

I use ledger-cli for such tables which can generate suitable output.

https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ledger.html
https://www.ledger-cli.org/3.0/doc/ledger3.html#Org-mode-with-Babel

You could do some clever stuff like

#+name: ledger-to-table
#+begin_src elisp :var data=""
(concat "#+name: ledger-results\n"
  data
  "#+tblfm: \n"))
#+end_src

#+begin_src ledger :results raw :post ledger-to-table(*this*) :cmdline 
--register-format "| %(format_date(date)) | %(payee) | %(display_account) | 
%(display_amount) | %(display_total) | \n" reg -M --wide --date-format %y-%m-%d
2022-06-15 * py2guile
ArneBab:Assets:Autorenhonorar:epubli 3.13€
ArneBab:Income:sale:nonrpg:epubli
#+end_src



#+begin_src elisp :exports results
(org-babel-do-load-languages
 'org-babel-load-languages
 '((ledger . t) ;this is the important one for this tutorial
  ))
nil
#+end_src

#+RESULTS:

If you use ledger-cli for accounting, you can do pretty clever
post-processing inside org-mode. Here’s an example that uses
[[https://www.ledger-cli.org/3.0/doc/ledger3.html#Output-customization][--register-format]]
 to provide the register results directly as an
org-mode table:

#+begin_src org
,#+name: ledger-to-table
,#+begin_src elisp :var data=""
(concat "#+name: ledger-results\n"
  data
  "#+tblfm: \n"))
,#+end_src

,#+begin_src ledger :results raw :post ledger-to-table(*this*) :cmdline 
--register-format "| %(format_date(date)) | %(payee) | %(display_account) | 
%(display_amount) | %(display_total) | \n" reg -D --wide --date-format %Y-%m-%d
2022-06-15 * py2guile
ArneBab:Assets:Autorenhonorar:epubli 3.13€
ArneBab:Income:sale:nonrpg:epubli
,#+end_src

#+end_src

This results in output like this (evaluated live on every export of this 
website):

#+name: ledger-to-table
#+begin_src elisp :var data=""
(concat "#+name: ledger-results\n"
  data
  "#+tblfm: \n"))
#+end_src

#+begin_src ledger :results raw :post ledger-to-table(*this*) :cmdline 
--register-format "| %(format_date(date)) | %(payee) | %(display_account) | 
%(display_amount) | %(display_total) | \n" reg -D --wide --date-format %Y-%m-%d
2022-06-15 * py2guile
ArneBab:Assets:Autorenhonorar:epubli 3.13€
ArneBab:Income:sale:nonrpg:epubli
#+end_src

#+RESULTS:
#+name: ledger-results
| 2022-06-15 | - 2022-06-15 | ArneBab:Assets:Autorenhonorar:epubli | 3.13€ | 
3.13€ | 
| 2022-06-15 | - 2022-06-15 | ArneBab:Income:sale:nonrpg:epubli | -3.13€ | 
0.00€ | 
#+tblfm: 


Also see 

- https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ledger.html
- https://www.ledger-cli.org/3.0/doc/ledger3.html#Org-mode-with-Babel




Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc

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

[Samuel Wales]

tldr: carry on.  :]


On 2/4/23, Samuel Wales  wrote:
> On 2/1/23, Ihor Radchenko  wrote:
>> the best we can do is minimizing the breakage when designing the new
>> syntax
>
> as a small nit [followup is not needed as i do not want to distract
> from the big boys talking about quantum dst on pluto for timestamps
> with [axial precession change :[]*, or follow up, as i have given up
> on the topic of tz for timestamps :]]:
>
> it might be that i was not making a point for which it is entirely
> true that what you and everybody else is proposing, i.e. extending
> existing ts syntax for tz, is the best we can do, in principle.  :]
> what you said is true if you stick, for tz-using tses, with extending
> /existing/ ts syntax, as opposed to countenancing, for those tses, an
> extensible syntax that is also usable for ts-unrelated features and
> subfeatures so as to reduce proliferation of new, heterogenous, syntax
> as it will arise in future and has arisen for many years [i prefer
> less syntax], and other stuff like reusable infrastructure for
> semantics and parsing and display etc. and optional ability for users
> to extend syntax themselves readily without it being heterogenous but
> instead merely cl-style kw, and also if you don't take potential
> issues with compatibility with piles of regexps in 3rd party and
> personal code, including non-emacs, into account [not saying
> unreasonable].  etc.  never fear: i have given up on all of that
> completely.  at least for tz.  your syntax looks great and everybody
> seems delighted so i have no business butting in and cannot follow up
> for unrelated reasons in any case.  so just a nit.  this paragraph
> might be unreadable and in that case you can just ignore it.
>
> [*] i have read that global warming relates to earth axis precession
> change due to contemporary mass loss primarily in Greenland.  for all
> i know, also the origins of org coincidentally being due to an
> astrophysicist, this could affect tses.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH 0/4] Structure editing when region is active

[Samuel Wales]

thanks for the patches.  out of curiosity, does e.g. m-up m-up up deactivate?

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

[Samuel Wales]

On 2/1/23, Ihor Radchenko  wrote:
> the best we can do is minimizing the breakage when designing the new syntax

as a small nit [followup is not needed as i do not want to distract
from the big boys talking about quantum dst on pluto for timestamps
with [axial precession change :[]*, or follow up, as i have given up
on the topic of tz for timestamps :]]:

it might be that i was not making a point for which it is entirely
true that what you and everybody else is proposing, i.e. extending
existing ts syntax for tz, is the best we can do, in principle.  :]
what you said is true if you stick, for tz-using tses, with extending
/existing/ ts syntax, as opposed to countenancing, for those tses, an
extensible syntax that is also usable for ts-unrelated features and
subfeatures so as to reduce proliferation of new, heterogenous, syntax
as it will arise in future and has arisen for many years [i prefer
less syntax], and other stuff like reusable infrastructure for
semantics and parsing and display etc. and optional ability for users
to extend syntax themselves readily without it being heterogenous but
instead merely cl-style kw, and also if you don't take potential
issues with compatibility with piles of regexps in 3rd party and
personal code, including non-emacs, into account [not saying
unreasonable].  etc.  never fear: i have given up on all of that
completely.  at least for tz.  your syntax looks great and everybody
seems delighted so i have no business butting in and cannot follow up
for unrelated reasons in any case.  so just a nit.  this paragraph
might be unreadable and in that case you can just ignore it.

[*] i have read that global warming relates to earth axis precession
change due to contemporary mass loss primarily in Greenland.  for all
i know, also the origins of org coincidentally being due to an
astrophysicist, this could affect tses.

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/)]

[Kyle Meyer]

Kyle Meyer writes:

> I'm not sure what's intended here.  There are spots in public-inbox that
> favor a date from Received headers.  I've sent a message to
> public-inbox's list:
>
>   https://public-inbox.org/meta/87edr5gx63@kyleam.com

Eric replied with a patch that resolved the issue.  I've installed it.

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

[Ypo]

Great link!
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

"Given a local time and an offset, you can know UTC time, but you do 
not know which time zone you’re in (because multiple timezones have 
the same offset)."


So, given a time zone you can know the offset (Google it, for example)..
Then, given the time zone and the local time, you can know UTC.
If orgmode gets the UTC there is not ambiguity.

But, that would mean that the offset related to the different time 
zones must be downloaded and updated from some site.
As you said before, that offset can change. For example, peninsular 
Spain has the same time as Berlin, but as this doesn't make much 
sense, it could change, so updates would be necessary.
I have been thinking about how I would use this feature. So use cases 
appeared, which arose some doubts about how to use this feature, and an 
opinion for the Poll surged:


If I wanted to assist to a "Mastering Emacs book club" meeting in 
America/Vancouver, while living in Spain: Doubt: Should I use local time 
of America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 
@America/Vancouver] (I don't like space before the @, for the Poll).
1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 
21:00]. (Spain local time). Correct?
2. If I went on vacation to Brasília, my agenda timestamp should change 
to: [2024-02-04 do. 17:00]. (Brasília local time).
   Doubt: How must the local time zone be updated to get that timestamp 
changed?
3. Back to Spain, I see that, for political reasons, Vancouver's winter 
time-zone changed from UTC-8 to UTC-9.

   Doubt: How would my tz database be updated?
   Doubt: After updating the tz database, my agenda timestamp would 
change automatically to  [2024-02-04 do. 22:00]. Correct?
4. For the Poll: What would be the expected behavior if we used the UTC 
offset?  [2024-02-04 12:00 @-08,America/Vancouver]
    - We should know beforehand the DST of Vancouver, or there would be 
warnings. It seems more difficult for the user: maybe the "-08," should 
be optional?
    - Case 3: After updating the tz database we would get warnings too. 
To correct those warnings, should the UTC offset be changed manually in 
the timestamp?. If there were 35 meetings in Vancouver throughout the 
year, to change all the UTC offsets could be non trivial for a normal 
user: UTC of the summer and winter would differ.
  [2024-09-04 12:00 @-07,America/Vancouver] should be changed to 
[2024-09-04 12:00 @-08,America/Vancouver]
  [2024-02-04 12:00 @-08,America/Vancouver] should be changed to 
[2024-02-04 12:00 @-09,America/Vancouver]

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

[Detlef Steuer]

 
> 
> May you please also take into account the amendments I made in my
> patch I attached earlier? For example, you still appear to use
> time-to-live and "time to life" inconsistently herein.
> 

Oh, sorry, something went terribly wrong on my end.

Next try.

Thx for your patience!

Detlef
>From 43cd5b0ce1fd591a92bb40d52f3dfb3ca5491930 Mon Sep 17 00:00:00 2001
From: Detlef Steuer 
Date: Sat, 4 Feb 2023 21:40:09 +0100
Subject: [PATCH] lisp/ox-icalendar.el: Add defcustom `org-icalendar-ttl' to
 ox-icalendar

* lisp/ox-icalendar.el: The option `org-icalendar-ttl' allows to advise
a subscriber to the exported ICS file to reload after the given time interval.

Default for `org-icalendar-ttl' is nil.  In that case the setting will
not be used in the exported ICS file.

The option may also be set using the ICAL-TTL keyword.
---
 etc/ORG-NEWS | 17 ++
 lisp/ox-icalendar.el | 53 +++-
 2 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c5e9cd568..52c1bae93 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -24,6 +24,23 @@ consider [[https://gitlab.com/jackkamm/ob-python-mode-mode][ob-python-mode-mode]
 has been ported to.
 
 ** New and changed options
+*** New custom setting ~org-icalendar-ttl~ for the ~ox-icalendar~ backend
+
+The option ~org-icalendar-ttl~ allows to advise a subscriber to the
+exported ~.ics~ file to reload after the given time interval.
+
+This is useful i.e. if a calendar server subscribes to your exported
+file and that file is updated regularly.
+
+See IETF RFC 5545, Section 3.3.6 Duration, and
+https://en.wikipedia.org/wiki/ICalendar#Other_component_types for
+details.
+
+Default for ~org-icalendar-ttl~ is nil.  In that case the setting will
+not be used in the exported ICS file.
+
+The option may also be set using the ICAL-TTL keyword.
+
 *** ~org-clock-x11idle-program-name~ now defaults to =xprintidle=, when available
 
 When =xprintidle= executable is available at =org-clock= load time, it
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 81a77a770..9651c74a0 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -295,7 +295,31 @@ Interesting value are:
 	  (const :tag "Local time" ":%Y%m%dT%H%M%S")
 	  (const :tag "Explicit local time" ";TZID=%Z:%Y%m%dT%H%M%S")
 	  (const :tag "Universal time" ":%Y%m%dT%H%M%SZ")
-	  (string :tag "Explicit format")))
+	  (string :tag "Other")))
+
+(defcustom org-icalendar-ttl "PT1H"
+  "The time-to-live 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 in an ICS file.  Setting org-icalendar-ttl to \"PT1H\"
+would advise a server to reload the file every hour.
+
+See https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html
+for a complete description of possiblee values of this option.  For example
+\"PT1H\" stands for 1 hour, \"PT0H27M34S\" stands for 0 hours, 27 minutes
+and 34 seconds.  Default value is nil, which means no such option
+is set in the ICS file.
+
+This option can also be set with the ICAL-TTL keyword."
+  :group 'org-export-icalendar
+  :type '(choice
+  (const :tag "no refresh" nil)
+  (const :tag "One day" "PT1D")
+  (const :tag "One week" "PT7D")
+  (string :tag "Other"))
+  :package-version '(Org . "9.7"))
+
 
 (defvar org-icalendar-after-save-hook nil
   "Hook run after an iCalendar file has been saved.
@@ -333,6 +357,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,24 +897,29 @@ 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
+   (plist-get info :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
 PRODID:-//%s//Emacs with 

netspend table

[Jude DaShiell]

May I have some help with  this table?
I don't have times for the dates which is why I left the times and week
days out of the dates.
This is a running balance table and I don't know what kind of a #TBLFMT
line would be useful for that either.
I think if I ever get good with #TBLFMT lines I'd like to write up tables
that cover many more useful and simpler calculation tables now missing
from documented orgmode.
Suggestions for any other improvements I could make on this table will be
appreciated and implemented if possible.

| date | transaction  | amount |   fee | balance |
|--+--++---+-|
| [2023-01-11] | original balance |  +0.00 | +0.00 | +423.17 |
| [2023-01-12] | dunkin   | -18.68 | -1.00 |  403.49 |
| [2023-01-13] | WalMart  | -28.68 | -1.00 |  384.88 |
| [2023-01-16] | Deposit  |  + |   |  634.88 |
| [2023-01-17] | Capris   |  - | - |  615.34 |
| [2023-01-17] | Mcdonalds|  -4.74 | -1.00 |  609.60 |
| [2023-01-18] | verizon  |  - | - |  543.35 |
| [2023-01-26] | dunkin   |  - | - |  542.37 |
| [2023-02-01] | damgoodcafe  | -13.28 | -1.00 |  528.09 |
|  |  ||   | |


Jude 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

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

[ypuntot]

Great link!
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

"Given a local time and an offset, you can know UTC time, but you do not know 
which time zone you’re in (because multiple timezones have the same offset)."

So, given a time zone you can know the offset (Google it, for example)..
Then, given the time zone and the local time, you can know UTC.
If orgmode gets the UTC there is not ambiguity.

But, that would mean that the offset related to the different time zones must 
be downloaded and updated from some site.
As you said before, that offset can change. For example, peninsular Spain has 
the same time as Berlin, but as this doesn't make much sense, it could change, 
so updates would be necessary.

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/)]

[Kyle Meyer]

Oy, sorry about mangling the subject :x

I started to change it to cc  but then decided to
start send a separate message, but forgot about the in-between subject
change.

future value for Date header can pin thread to top of $inbox/ 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/bui

[Kyle Meyer]

Ihor Radchenko writes:

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

Hmm, that's unfortunate.

> 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.

Look again at its date header:

  $ curl -fSsL 
https://list.orgmode.org/ZT2vNKsf3Lp5xit3@protected.localdomain/raw | \
grep Date:
  Date: Sun, 29 Oct 2023 04:02:44 +0300

> Are we observing public inbox bug?

I'm not sure what's intended here.  There are spots in public-inbox that
favor a date from Received headers.  I've sent a message to
public-inbox's list:

  https://public-inbox.org/meta/87edr5gx63@kyleam.com

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/)]

[Max Nikulin]

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


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


At the epoch of livejournal some users intentionally assign some date in 
the the future to pin posts at the top of their blogs.



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.


See the "Date" header

Date: Sun, 29 Oct 2023 04:02:44 +0300
Are we observing public inbox bug?


Earlier I have seen spam messages from the future. I think, it just was 
easier to take time from the Date header. Parsing of "Received" headers 
is more complicated and it is necessary to configure which one can be 
trusted. Sender may add some fake "Received" headers as well. Moreover 
it is necessary to ensure that time is correct on the trusted server. 
(It must be done anyway, incorrect time may lead to failure of TLS 
handshake before message transfer.)


I am not convinced that mail list must drop messages with future date.

Public inbox may have some feature like override map Message-ID -> 
correct date or parsing "Received" headers. The latter may increase 
server load during mail processing.

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO

[Max Nikulin]

On 02/02/2023 16:37, Heinz Tuechler wrote:

tomas wrote/hat geschrieben on/am 02.02.2023 09:33:

On Thu, Feb 02, 2023 at 08:45:51AM +0100, Heinz Tuechler wrote:

It seems to me that this shows the time zone I selected at set up of the
computer, in my case Europe/Berlin. Using package lutz in R with correct
coordinates I see Europe/Vienna, based on open street map.
Days ago I did not even know that Berlin and Vienna are in different
time zones.


It is not uncommon problem. People set a time zone having the same 
offset and later complain that historical data can not be trusted.


Ubuntu guesses timezone likely using their GeoIP service. For me it 
works correctly. Approach implemented in Debian installer can be called 
at least questionable. They allows to choose from incomplete subset of 
time zones that is based on locale (selected several steps before). 
Developers refuse requests to add an option with complete list of time 
zones. So some users either finishes with incorrect time zone or have to 
run dpkg-reconfigure tzdata.


I forgot to mention some methods to guess location and so time zone when 
I was writing https://list.orgmode.org/orgmode/tqj9af$vhk$1...@ciao.gmane.io/



Vienna is special :)


There is no reason to add a timezone if there is nothing special.

zdump -v Europe/Berlin

Europe/Berlin  Sun Sep 28 00:59:59 1980 UT = Sun Sep 28 02:59:59 1980 
CEST isdst=1 gmtoff=7200
Europe/Berlin  Sun Sep 28 01:00:00 1980 UT = Sun Sep 28 02:00:00 1980 
CET isdst=0 gmtoff=3600


zdump -v Europe/Vienna

Europe/Vienna  Sat Sep 27 21:59:59 1980 UT = Sat Sep 27 23:59:59 1980 
CEST isdst=1 gmtoff=7200
Europe/Vienna  Sat Sep 27 22:00:00 1980 UT = Sat Sep 27 23:00:00 1980 
CET isdst=0 gmtoff=3600


03:00 -> 02:00 vs 24:00 -> 23:00 transition time.

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

[Ihor Radchenko]

[ adding Org ML back to CC ]

contrapunctus  writes:

> It seems it's not just org-publish, but the Org HTML exporter which does not 
> obey org-footnote-section.
>
>> Please provide more details about how to reproduce the issue.
>> May you attach a small example file and details steps demonstrating the 
>> issue? See https://orgmode.org/manual/Feedback.html#Feedback
>
> Steps -
> 1. emacs -q
> 2. (setq org-footnote-section nil)
> 3. Export the attached Org file to HTML buffer or file
>
> Observation - the HTML buffer/file has a "Footnotes" heading
>
> Expectation - there should be no "Footnotes" heading, and footnotes should be 
> placed at the end of each section in the exported HTML, to be consistent with 
> the behaviour of org-footnote-section.

Ok. I see what happens now.

Org behaves as expected. Setting org-footnote-section to nil only makes
export ignore existing "Footnotes" heading, if it is present in Org.

You don't have any in your example file, so Org ignores nothing.

Then, ox-html specifically exports footnotes into a separate section at
the end of the html document by its design. See
`org-html-footnotes-section'.

Not a bug.
Canceled.

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

Re: Org html conversion with XyJax

[Ihor Radchenko]

Partha Pratim Ghosh  writes:

> Thanks; this suggestion worked --- at least the xymatrix figure came
> out; however, the arrow was almost not present:
> test

Note that your attached html lacks images and thus cannot be viewed.

> I believe this is a rendering problem. Also the mathematics symbols get
> /tiny/; could rendering of mathematics made bigger, a little bolder, and
> xymatrix diagram arrows made visible?

Check out org-format-latex-options. In particular, :scale.

> I have a huge amount of macros which are constantly used, especially
> because the area of my work (Category Theory) demands use of plenty of
> inline diagrams as well as displayed diagrams; for inline diagrams it is
> best to have macros to speed up the typing. I believe you are saying
> that while these are recognised by LaTeX for PDF documents, the html
> converter just neglects them.
>
> Firstly, is it possible to convert these macros to a form which is
> acceptable by hrml converter?

We rely on MathJax, which, AFAIK, supports a subset of LaTeX. To get
full LaTeX support, you have to use LaTeX, which we allow, via images,
as Rudolf suggested.

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

Re: [MAINTENANCE] Org orphanage?

[Ihor Radchenko]

Bastien Guerry  writes:

> Bastien  writes:
>
>> Shall I create https://git.sr.ht/~bzg/org-orphan-packages ?
>
> Or better https://git.sr.ht/~org-orphanage/ as a new user, to where
> Org orphan repos could be added.
>
> This would mimick emacsorphanage, which is a GitHub organization.

+1

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

Re: [PATCH 0/4] Structure editing when region is active

[Ihor Radchenko]

Ihor Radchenko  writes:

> I'd like to propose a patchset that addresses some issues raised in
> https://teddit.zaggy.nl/r/orgmode/comments/10b6ue6/orgmode_is_so_bad_at_rearranging_items_in_an/
>
> 1. When acting on region, promotion, demotion, and other structure
>editing commands immediately deactivate selection. It is annoying
>when one wants to promote several headings togetehr multiple times.
>
> 2. M-/ on region does not care if there are headings inside
>region and simply treats region as plain text:

Applied, onto main, dropping the patch to preserve region upon setting
heading state. I also merged the NEWS patch into the corresponding
feature patches.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b665f8de3
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c8a5fef91

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

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

[Ihor Radchenko]

contrapunctus  writes:

> 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.

Please provide more details about how to reproduce the issue.
May you attach a small example file and details steps demonstrating the
issue? See https://orgmode.org/manual/Feedback.html#Feedback

> ... #+OPTION: org-footnote-section:nil, and as a property in
> org-publish-project-alist (:org-footnote-section nil)

These two options will have no effect. org-footnote-section cannot be
set using OPTIONS and project alist. Just variable.

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

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

[Ihor Radchenko]

Edgar Lux  writes:

> ... 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. 

At this point, we should not jump into the implementation. Rather
discuss possible pros and cons.

For example, looking at my proposal now, I see how the proposed idea is
a bit awkward:

In #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style[...] 
citation-style[...]

I assumed that there is one "major" bibliography-style/citation-style.
However, it is not really the case in practice. The styles are combined.

For example, adding links to bibliography to citations is applied
regardless of the particular citation command being used.

So, I am not leaning closer to only allowing options being passed to
"processor", but not to styles. This will at least come closer to
certain settings being citation package global config applied to
everything. If we have options applied to specific citation commands,
they will rather fit into citation-style/sub-style.

#+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style 
citation-style

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

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

[Ihor Radchenko]

Detlef Steuer  writes:

>> 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?

Yup.

> Next iteration of the patch.

May you please also take into account the amendments I made in my patch
I attached earlier? For example, you still appear to use time-to-live
and "time to life" inconsistently herein.

-- 
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]

Max Nikulin  writes:

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

Agree. If pgtk does not have to use something that absolutely needs to
be pgtk-specific, we should rather introduce a generic customization.
For example, a new `org-clock-idle-function' customization may accept
Elisp function of a string (for a shell command), defaulting to
`org-emacs-idle-seconds'.

-- 
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 (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> >> [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.

Well. "UTC" there is rather arbitrary, but _some_ abbreviation is
required as per TZ spec. Could also be [2022-11-12 14:00 @BLAHBLAH+2]

I used "UTC+2" because it is how offsets are often represented.
For example, https://time.is/London is displaying the following:

Time in London, United Kingdom now
...
Time zone
- Currently Greenwich Mean Time (GMT), UTC +0
- Daylight saving time (British Summer Time (BST), UTC +1) starts March 26, 
2023

Note UTC +0 and UTC +1.
I've seen such format in multiple time websites.

On the other hand, TZ POSIX is reverse from what is commonly meant when
displaying UTC +1.

> 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?
>

You are right. From the point of view of TZ POSIX spec, UTC+2 is not UTC
time zone and not a known time zone. Rather manual nautical time zone
with arbitrary name and fixed UTC offset (+2).

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

It is a correct TZ value 路

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

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

[Ihor Radchenko]

contrapunctus  writes:

> 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.

What if you use the default publishing-function?
`org-html-publish-to-tufte-html' is not a part of Org.

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

Re: Subtree export of empty entry generates spurious letter

[Alain . Cochard]

Ihor Radchenko writes on Thu  2 Feb 2023 10:56:

 > I am unable to reproduce on the latest main.

Me neither...

In addition to the initial release_9.6-204-g2f7052, I can still
reproduce with release_9.6-149-g554935.dirty, release_9.6-118-g04d2cc,
release_9.6-90-gf49ee9.dirty.  But it's not on 9.5.5-g8ef620.
Hopefully, it will show up again some day :-)

Thanks for the feedback.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]