[PATCH] fix compat with emacs 25 due using temporary-file-directory

[Tom Gillespie]

Small bugfix for emacs 25 compat. Best!
Tom
From f04a44e5cc8143fc6cdbbc92b9d2afb76de4a459 Mon Sep 17 00:00:00 2001
From: Tom Gillespie 
Date: Mon, 16 Jan 2023 00:25:47 -0500
Subject: [PATCH] fix compat with emacs 25 due using temporary-file-directory
 function

* lisp/ob-core.el: org-babel-temporary-stable-directory use the symbol
version of temporary-file-directory since the function form is not
available on emacs 25.
---
 lisp/ob-core.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 5d5edadd2..255a767bb 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -3276,7 +3276,7 @@ Emacs shutdown.")
   (while (or (not dir) (file-exists-p dir))
 (setq dir (expand-file-name
(format "babel-stable-%d" (random 1000))
-   (temporary-file-directory
+   temporary-file-directory)))
   (make-directory dir)
   dir))
   "Directory to hold temporary files created to execute code blocks.
-- 
2.38.2

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tom Gillespie]

> So I guess the timestamp format and the code which manages them will
> need the ability to use the full TZ name and not just the abbreviated
> form (and I guess an option to allow the user to select). In fact, we
> probably need a way to select between abbreviated/full dynamically as
> well as you might use the different TZ types as a way to flag which
> timestamps you want to adjust due to TZ changes (either in TZ db or in
> user location) and those you don't want changed.

I think the only sane way to do this is to require timezone abbreviations
/expansions to be defined in the file itself and never in an init.el there is
simply too much ambiguity and if the information is lost we are out of luck.

Of course then the question comes whether we can use something like
#+tzinfo: US/Central CT
#+tzoff: CST -06:00
#+tzoff: CDT -05:00
I don't think it is wise to allow users to map #+tzinfo: US/Central CST
because that will produce surprising and results when US/Central
changes to DST. Ugh, what a mess.

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tom Gillespie]

> In anticipation to add time zones in future, I have added the following
> to the Org timestamp spec (see
> https://orgmode.org/worg/org-syntax.html#Timestamps):
>
> DATE TIME REPEATER-OR-DELAY
>
> TIME (optional)
> An instance of the pattern H:MMREST where H represents a one to two digit 
> number (and can start with 0), and M represents a single digit. REST can 
> contain anything but \n or closing bracket.
>
> Note that REST imply that almost arbitrary suffix can be in TIME without
> braking the existing Org timestamp parsing code.

I'm not sure how I feel about the REST in the grammar, I think it is a
reasonable approach but need to double check. I'm worried that there
can be some nasty interactions with REPEATER-OR-DELAY syntax, but that
may not actually be an issue.

I will note that this doesn't address the issue of syntax for
historical and future dates. For historical dates those almost always
require significant additional metadata to compensate for things like
the julian/gregorian calendar switchover etc. for future dates we may
want to go ahead and specify something beyond -.

I'm less concerned about the rest of the issues beyond the fact that
adding syntactic support for timezones seems to have opened up
countless usability and bad assumption issues that have been mentioned
elsewhere in the thread.

So, I think the syntax may be ok, but as written I think there can be
quite nasty interactions with REPEATER-OR-DELAY (not to mention what
happens if a delay tries to track across a change in timezones).

Best,
Tom

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Max Nikulin]

On 16/01/2023 02:14, Jean Louis wrote:


As PostgreSQL type TIMESTAMP WITH TIME ZONE is stored with underlying
UTC time, so should be Org times also be calculated with underlying
UTC times.


Org currently can properly handle the following case:

Let's assume that current date is 2022-07-01. A user living in Mexico 
City schedules a local event at 2023-07-01 16:00 (local time, 
America/Mexico_City time zone). That day the region had DST active, so
current time at the moment of appointment creation has the form 
2022-07-01 16:00:00 CDT -0500.


Since that date it was decided to cancel DST transitions, so currently 
(2023-01-16) planned event time is not CDT -0500 but


TZ=America/Mexico_City date -d '2023-07-01 16:00' '+%F %T %Z %z'
2023-07-01 16:00:00 CST -0600

Agenda in Org has no problem as soon as tzdata is up to date.

As a PosgreSQL expert, could you, please, explain how to handle it in 
Postgres?


1. Downgrade tzdata to 2022e version or older, restart Postgres
2. Create a suitable table
3. Store "2023-07-01 16:00" America/Mexico_City timestamp using column 
types you find appropriate for such case

4. Update tzdata to 2022f version or newer, restart Postgres
5. Check that the event is still scheduled at 16:00 in Mexico City

I am interested in the table schema, insert and select commands.

To check timezone data you may use

zdump  -v America/Mexico_City

Feel free to take another example of tzdata change instead of
https://github.com/eggert/tz/commit/2050724fa1144bacb0d35c7cd9b862da858406c4
that I found it in /usr/share/doc/tzdata/changelog.Debian.gz

I do not want a regression in Org due to a feature that is intended to 
improve timestamp handling. I see the point in the Postgres wiki 
recommendations, but I see their limitations as well. I do not feel that 
time offset and absence of DST can be considered as a settled state for 
the timezone I live in.

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

[Samuel Wales]

not really related, but wrt structure editing, is there anything that
preserves integrity of levels?  [my old maint version allows double
demotion [perhaps this is related to inline tasks], and i wonder about
org-yank, and org-lint does not complain.]

i have encountered cases in org where i find it annoying htat i hae to
c-g to stop transient mark mode.  will report if able.


On 1/15/23, Ihor Radchenko  wrote:
> Hi,
>
> 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:
>
>* Heading 1
>text
>** Sub
>* Heading 2
>* Heading 3
>
>{M-}
>
>* Heading 1
>text
>* Heading 2
>* Heading 3
>** Sub
>
> The patchset below addresses (2) by making org-metaup/org-metadown
> aware of headings in region (when region starts at heading).
>
> In addition, it alters M-/M-/M-/M- to not
> deactivate active selection (Transient mark mode).  This way, one can
> issue, say, M- repeatedly without having to re-select
> everything.
>
> Similarly, bulk editing commands like setting schedule, deadline,
> tags, and todo do not deactivate region.
>
> I'd appreciate testing on edge cases and ideas for tests.
>
> Ihor Radchenko (4):
>   Preserve active region after structure edits
>   Preserve active region when toggling heading state
>   org-metaup, org-metadown: Move subtrees in active region
>   org-manual.org: Document changes in 8f6fcd709, 5719a8163, and
> eda9909a9
>
>  etc/ORG-NEWS |  20 ++
>  lisp/org-list.el |   3 +-
>  lisp/org.el  | 146 +++
>  testing/lisp/test-org.el |  54 +++
>  4 files changed, 179 insertions(+), 44 deletions(-)
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>
>
>


-- 
The Kafka Pandemic

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

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Samuel Wales]

to be clear, i won't object to that syntax, as i think it is as
intuitive as anything else in tses already, but do have the concerns i
raised in general.


On 1/15/23, Samuel Wales  wrote:
> On 1/15/23, Ihor Radchenko  wrote:
>> My proposal is as little new syntax as I was able to come up with.
>
> i kind of like it actually.  :]
>
> but i just wanted to bring up the issue of 1] the possibility of
> drawing a line in the sand at some point wrt creeping syntax [even if
> not in tses for repeaters], [in principle in tses if tz complexity
> turns out to demand more user specification etc.], and 2] 3rd party
> and personal code that ... who knows what parsing lurks.  unintended
> consequences and all that.
>
> i checked my very old own code and indeed i'm not trying to get the
> repeater with strict re character group, but in principle i can
> imagine code by others could have.
>
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

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

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Samuel Wales]

On 1/15/23, Ihor Radchenko  wrote:
> My proposal is as little new syntax as I was able to come up with.

i kind of like it actually.  :]

but i just wanted to bring up the issue of 1] the possibility of
drawing a line in the sand at some point wrt creeping syntax [even if
not in tses for repeaters], [in principle in tses if tz complexity
turns out to demand more user specification etc.], and 2] 3rd party
and personal code that ... who knows what parsing lurks.  unintended
consequences and all that.

i checked my very old own code and indeed i'm not trying to get the
repeater with strict re character group, but in principle i can
imagine code by others could have.

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


-- 
The Kafka Pandemic

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> Unfortunately, the common abbreviated forms like EST, AEST etc are
>> inconsistent here. Some places will have a standard and a daylight
>> savings type i.e. AEST and AEDT, while others will have just AEST. TO
>> make it worse, two locations with the same time zone offset my use
>> different versions i.e. Australia/Melbourn is AEST (+10/+11) and
>> Australia/Sydney is AEST (+10) and AEDT (+11) and Australia/Brisbane is
>> just AEST (+10). If everywhere which has daylight savings ensured they
>> used a different abbreviation for daylight saving and non-daylight
>> saving times, life would be easier, but they don't). Then of course
>> there are many countries which don't have a symbolic letter abbreviation
>> i.e. just have e.g -05 as their abbreviated TZ name.
>>
>> It is this and other related reasons why just relying on Emacs' internal
>> API for times and dates is not sufficient. The abbreviated times have
>> ambiguity and the full timezone specification is cumbersome and
>> ugly. Even worse is that issue won't be shown up as failures - you will
>> just silently get wrong results.  
>
> So, basically we may need a way to (1) identify ambiguous TZ
> specifications; (2) signal to user about potential issues.
>
> Note that these are also optional features we may implement any time
> once we have basic timezone support.
>
> For (2) we may use something similar to `world-clock' - display user
> timestamp at point for different time zones. Maybe via eldoc.


If the timestamp only contains the abbreviated name e.g. AEST, then
there is no automatic way to disambiguate - best we could
do is issue a warning. The abbreviated TZ name, unlike the full TZ name,
is really just a shorthand for the time offset from UTC at a specific
point in time. The full TZ name on the other hand states not only the
UTC offset, but also the TZ rules (and with things like the IANA TZ
database, the specific TZ rules in place at the point in time that
timestamp represents). This is essentially Max's main point - if
timestamps for the future have the full TZ name, then we can manage
things like changes in TZ database rules which occur after creation of
the timestamp or adjusting timestamps (for scheduled tasks) based on
changes in location etc). This would not be possible with abbreviated TZ
or just UTC offsets.

As an example, I'm in Australia/Brisbane TZ and I create a timestamp. If
it only has the AEST TZ info, when I travel to Australia/Melbourne org
would not be able to identify I'm in a TZ with an offset of +1100 rather
than +1000 because both use AEST (for NSW it likely would work as NSW
uses AEDT during daylight savings time). However, if the TZ was full
name i.e. Australian/Brisbane, then it does know and can adjust because
my local TZ has changed to Australia/Melbourne. 

So I guess the timestamp format and the code which manages them will
need the ability to use the full TZ name and not just the abbreviated
form (and I guess an option to allow the user to select). In fact, we
probably need a way to select between abbreviated/full dynamically as
well as you might use the different TZ types as a way to flag which
timestamps you want to adjust due to TZ changes (either in TZ db or in
user location) and those you don't want changed.

I also note a comment from an earlier thread regarding timestamps and
historical changes in tz info. I don't think this is an issue.  As far
as I know, past TZ rules/information rarely, if ever, change. It is only
with respect to future dates it is a problem and I doubt there is much
that can be done. For example Postgres recognises that a future
timestamp may become incorrect due to changes in TZ rules post creation
of the timestamp, but they specifically state they don't handle that
situation and that their model has an implicit assumption that the TZ
rules associated with a TZ don't change. In other words, from their
perspectrive, you would have to have a different process which monitors
TZ database information and when it changes, examine your db of
timestamps for ones which have been affected and adjust accordingly
(assuming it matters enough of course). I think org could eventually
reach a middle ground - if a future timestamp has the full tz name, then
changes can be applied, but if not they cannot and leave it to the user
to decide which is used. 

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

[No Wayman]

No Wayman  writes:

Sorry, wrong commit value in the previous patch.
Fixed the patch attached here.

>From a4cd70e17455894aec5d15d97eb41b56769e5cde Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sun, 15 Jan 2023 15:44:45 -0500
Subject: [PATCH] * mk/targets.mk (GITVERSION): support shallow repo clones

If Org is being built from a shallow clone, tags are not locally available.
Query the upstream remote via git ls-remote and parse the output.
Note this will result in a "n/a" indicator in org-version where the
number of commits since the last tag is usually present.
e.g. "release_9.6.1-n/a-gabc123"
---
 mk/targets.mk | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 4435daa9..20d375aa 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -14,7 +14,14 @@ ifneq ($(wildcard .git),)
   # Use the org.el header.
   ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
 --visit lisp/org.el --eval '(princ (lm-header "version"))'))
-  GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
+  ifneq ($(wildcard .git/shallow),)
+REMOTETAGS := $(strip $(shell git ls-remote --tags 2>/dev/null | tail -n 1))
+COMMIT := $(shell git rev-parse --short=6 HEAD)
+TAGPREFIX  := $(subst refs/tags/,,$(lastword $(REMOTETAGS)))
+GITVERSION ?= $(subst ^{},-n/a-g$(COMMIT),$(TAGPREFIX))
+  else
+GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
+  endif
   GITSTATUS  ?= $(shell git status -uno --porcelain)
 else
  -include mk/version.mk
-- 
2.39.0

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Ihor Radchenko  [2023-01-14 16:23]:
> Tim Cross  writes:
> 
> > Consider for example an agenda file where the TODO items have been added
> > while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly
> > to Europe where I will be working for the next 6 weeks. I need all my
> > TODOs with active timestamps to be updated to Berlin's TZ. How does this
> > work?
> 
> I am not sure what is the problem.
> The timestamps that should stay in local time will be automatically
> updated as your system TZ is updated.

Then Org shall know what was local time! Without being specified in
the time stamp, it has to be specified somewhere, as computer can't
know at which time zone was it specified.

> The timestamps that should be tied to specific time zone will specify
> that required time zone and will thus remain functional.

That is clear.

> > The representation of the timestamps is the easy part. It is the
> > management, display, calculations, etc where the complications
> > arise. From looking at the supported time related functions in Emacs,
> > while most of the key ones do have support for passing in time zone
> > data, there seems little (if any) code to support the lookup and
> > retrieval of time zone data - in particular, ability to lookup time zone
> > data for a specific date, not just a location.
> 
> But why do we need any time zone data? All we need to converting from
> and to internal Emacs' time representation supplying the correct time
> zone to it.

Converting alone shall be easy, but that does not resolve the
problem. 

You need to review practical examples as they are already listed in
this thread by various people.

Time zones are important for people who work with different time
zones, and for those who share headings and Org files on the planet.

They are not important for people who are static in one city, who do
not travel and do not share Org files with others.

-- 
Jean

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

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross  [2023-01-15 00:40]:
> The internal representation of timestamps used by Postgres is ALWAYS
> UTC, regardless of whether the field was defined as timestamp or
> timestamp with timezone.

Right.

> The only real difference is that if the field is defined as just
> timestamp, postgres assumes the data being entered is in local time
> and will adjust using the local timezone offset.

I was never thinking about it because I have never observed it or
maybe I was unable to see it. I don't see it is adjusting
anything. Because time without time zone is just UTC time, so it is
not adjusting, but adding the time.

CREATE TABLE my (timestamp_without timestamp without time zone default
now(), 
timestamp_with timestamp with time zone default
now());


\d my
Table "public.my"
  Column   |Type | Collation | Nullable | 
Default 
---+-+---+--+-
 timestamp_without | timestamp without time zone |   |  | now()
 timestamp_with| timestamp with time zone|   |  | now()

[local] maddox@admin=# insert into my default values;
INSERT 0 1
[local] maddox@admin=# select * from my;
 timestamp_without  |timestamp_with 
+---
 2023-01-15 23:07:35.753599 | 2023-01-15 23:07:35.753599+03
(1 row)

What if user comes to UTC time zone by Greenwich and then sets the
time zone with PostgreSQL:

SET TIME ZONE 'UTC';

select * from my;
 timestamp_without  |timestamp_with 
+---
 2023-01-15 23:07:35.753599 | 2023-01-15 20:07:35.753599+00
(1 row)

One can see that time stamp with time zone is being adjusted.

Because it is not same time:

select timestamp_with - timestamp_without from my;
 ?column?  
---
 -03:00:00

There is 3 hours difference, though the entry in the database was in
the same time and time "looks same" while it is not.

The difference is not that PostgreSQL adjusts something but timestamp
without time zone is treated as UTC and with time zones is treated as
different to UTC, those are different times then even though they may
look apparently same.

> It will ignore any tz information in the input. If the field is
> defined as timestamp with time zone, it will use the offset defined
> by the timezone in the input to determine the UTGC value.

Or no need for offset, as in the above example.

> When displaying a timestamp, postgres always uses the local time
> zone unless you request a different timezone using the 'at time
> zone' construct.

Actualy not, it does not always use local time zone, as for timestamp
without time zone, it does not show any different representation
regardless of local time zone:

set time zone '+4';
SET
[local] maddox@admin=# select * from my;
 timestamp_without  |timestamp_with 
+---
 2023-01-15 23:07:35.753599 | 2023-01-16 00:07:35.753599+04

> >> Thinking more about this, I can see how it can be important for
> >> clocking, and similar auto-recorded information. Users may be surprised
> >> to record clocking on some task yesterday just to find the clocking data
> >> in future upon travelling from Singapore to San Fran.

That is so much right.

> >> So, when implementing time zones, we may need to take care about adding
> >> the time zone info when auto-inserting timestamps.

That is good conclusion. It just comes so late in time.

> >> In addition, we may provide some mechanism to set the time zone for:
> >> 1. Individual files
> >> 2. For all files, including possible time zone transitions over
> >> time.

One has system time, but one can work with different system file and
specifying different time zone, so yes, one shall have global options
of the time zone, which should allow settings different than system
time. 

It requires in Org export to understand what is local time zone so
that Org export can set global variable of local time zone, as if it
was not set, so that when Org file is used in different time zone,
that proper time calculation can take place.

Settings shall be available:

- based on operating system time zone;

- which could be rewritten by Org settings for all files;

- which could be rewritten by file setting;

- which could be rewritten by heading property;

- which could be rewritten by timestamp itself;

Then the function reading timestamps should understand it, and later
provide all calculations.

> > Definitely. But the time stamp (with time zone) in itself doesn't
> > carry enough context to actually decide that.

Ha, ha, that is right, as time with time zone in Org context is not
UTC time internally, so that way is very difficult to achieve
accuracy, as it should involve all political changes about time zones
at any time 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Max Nikulin  [2023-01-15 08:05]:
> I totally agree with the recommendation to use timestamptz for data related
> to something in history: billing, bank transactions, etc.
> 
> However it is call to trouble for planned events and schedules. Not
> frequent, so almost untested use cases.
> 
> If I remember correctly, another type, timestamp (without tz), may be cast
> on demand to any timezone (stored in another column or passed from
> application). So it may be used obtain correct UTC timestamp after update of
> timezone database.

It is about representation.

If time is represented as UTC, by user in Brazil, how is somebody in
Russia going to understand when is the meeting?

Call for trouble is when there is UTC time only as that requires users
to calculate themselves the different time zone, instead, computer is
for such calculations there.

When time is specified with time zone, then user in any ther time
zone can see that in his own time zone.

In the context of Org files, that would mean that there must exist
function which would convert time zone timestamps into local time zone
for proper representation.

Only with such functions problems are gone.

Without such function to convert time zones in different time zone,
user will see time zone from Brazil and will run into difficulties.

-- 
Jean

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

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Ihor Radchenko  [2023-01-14 20:08]:
> > When you have appointments with people in totally diverse time zones,
> > perhaps dates tend to be more fixed wrt UTC.
> 
> AFAIK, people don't usually bother.

Can't agree to that, we who do bother will simply find different
solutions but Org, like I have developed it for myself or other CRM
systems where all time issues are solved fundamentally on the database
level.

Haven thanks, it is very easy within seconds to find how many people
are affected by time zones, so I have run 

"SELECT DISTINCT get_contacts_name(hyobjects_assignedperson) FROM
hyobjects WHERE hyobjects_assignedperson IS NOT NULL;"

And I got round number of 50 people! 

All our staff members used Org mode before, now not, there is no need
for it, apart from few lines, or generated Org buffers for usage
similar like browsing. And this is only for reasons of having fancier
themes. 

You can't know if people bother if you do not ask. 

Yes, I feel that it is not considerate enough when you say that people
don't usually bother. 

When I expressed my on this mailing list that there are issues, that
was back in time, and I would consider any issue here mentioned ever
once, that "people do bother". 

In media and newspaper business, we know that when there is one
reader's letter, that there are 1000 other people who have the same
opinion. Maybe statistics changed, but you should use that principle
on mailing list and in any community software development. One person
writing on mailing list may mean hundreds affected in background.

I can observe on other development places that people raise issue
before 10 years, before 8 years, until it finally gets solved, and the
package get its boost because it became really useful.

All the people who were direct and indirect users of Org mode since
2016, switched to different system. They are not bothered to learn
about Org, which is useful as it minimizes distraction. Though Org
mode remains useful in work of managers.

-- 
Jean

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

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross  [2023-01-15 01:13]:
> I think I basically agree with the last statement. However, perhaps we
> need to step back and ask ourselves what it is that people do want which
> drives this feature request. I doubt it is simply the ability to add TZ
> information to timestamps. I suspect the underlying motivation here is
> to have org mode actually use this information in a meaningful way,
> which essentially means all the complicated stuff I'm concerned about
> and which you seem to imply we wouldn't manage anyway.

It means for representation and calculations.

Person in East Africa writes task to somebody in Washington, with
deadline with time zone in Croatia, when notary has to sign a document
for somebody in Croatia. Because there is hypothetical timezone
parameter at file, or header level or timestamp level, then user in
Washington can see proper time in his time zone.

Representation should depend on user's local system. But how to know
how to display the time, without having time zone defined in first
place?

It requires global timezone parameter, heading and timestamp based.

Apparently it is confusing and asks for work. Sorry for that. It is
something one had to think ahead of time when dealing with people all
over the world. 

I think that any function reading timestamps should get its "bypass"
to re-calculate timestamp according to specified time zone.

If user Joe in East Africa wrote a meeting appointment with person in
Greek by Greek timezone, and sent that appointment to Washington, USA,
then person in Washington should read the time in his time zone, and
would know when is meeting accurately, in how many hours for him. 

Greek, East African and Washington people would all see different
times, but would meet accurately at same time.

> To put it another way, we need to clarify what people mean when they
> request the feature of timestamp support in org-mode datestamps. What
> does this actually mean? Is it as simple as just being able to specify
> the timezone (seems relatively easy to implement, but doens't really add
> much) or is the expectation that once you have time zone information, it
> will be used to do things like adjust date+time in agenda based on
> change in locale or change in daylight savings status etc.

I am sure that adjustments must come there. 

Practically, Org headings and files are easily shareable. Users in
different time zones could instead plan their own, receive the agenda
planned by other people, they would see it in their own calculated
time zone, while other people watching same agenda, would see it in
their own.

-- 
Jean

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

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

[PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

[No Wayman]

In order to properly generate org-version.el, the current build in 
mk/targets.mk requires a query of the repo's tags. Shallow clones 
do not have tags and so org-version will be generated as "N/A". In 
the attached patch, support for generating org-version.el from 
shallow clones is added. It is done by querying the upstream 
remote via git ls-remote and parsing the output. In this case, a 
more well formed org-version string will be generated. However, it 
will be missing the "commits since last tag" information. e.g.


"release_9.6.1-n/a-gabc123"

>From 28c596320f48e4606f8eaf69fdc1c83fb084749e Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sun, 15 Jan 2023 14:55:11 -0500
Subject: [PATCH] * mk/targets.mk (GITVERSION): support shallow repo clones

If Org is being built from a shallow clone, tags are not locally available.
Query the upstream remote via git ls-remote and parse the output.
Note this will result in a "n/a" indicator in org-version where the
number of commits since the last tag is usually present.
e.g. "release_9.6.1-n/a-gabc123"
---
 mk/targets.mk | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 4435daa91..300fc8e0b 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -14,7 +14,14 @@ ifneq ($(wildcard .git),)
   # Use the org.el header.
   ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
 --visit lisp/org.el --eval '(princ (lm-header "version"))'))
-  GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
+  ifneq ($(wildcard .git/shallow),)
+REMOTETAGS := $(strip $(shell git ls-remote --tags 2>/dev/null | tail -n 1))
+COMMIT := $(shell echo $(firstword $(REMOTETAGS)) | cut -c 1-6)
+TAGPREFIX  := $(subst refs/tags/,,$(lastword $(REMOTETAGS)))
+GITVERSION ?= $(subst ^{},-n/a-g$(COMMIT),$(TAGPREFIX))
+  else
+GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
+  endif
   GITSTATUS  ?= $(shell git status -uno --porcelain)
 else
  -include mk/version.mk
-- 
2.39.0



Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ 
Version 3.24.36, cairo version 1.17.6)

of 2023-01-08
Package: Org mode version 9.6.1 (release_9.6.1-137-gecb62e @ 
/home/n/.emacs.d/elpaca/builds/org/)

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* to...@tuxteam.de  [2023-01-14 20:16]:
> What I can imagine being useful (besides allowing timestamps to carry
> that extra info) is the possibility to set defaults, perhaps at the
> file (even, who knows, at the heading) level. A special attribute
> seems pretty adequate, if I'm not missing some monster.

So far only supported for iCalendar backend:

(info "(org) iCalendar Export")

Though it should be supported on file level, then any timezone can be
recalculated for representation.

-- 
Jean

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

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Thomas S. Dye]

Aloha all,

IIUC, timestamps in Org might be used to track two things: events 
and occurrences.


An event refers to a particular region of space/time, in Org's 
case the space/time occupied by the user, regardless of which time 
zone the user occupies.  An event might be "Brush teeth before 
bed" set for 10:00 PM, which the user would want to make happen at 
that time, regardless of the time of day in the timezone in which 
the timestamp was applied to the event.


An occurrence refers to changes in the nature and relations of 
substances at a time.  It takes place in absolute time in order to 
avoid circularity.  An occurrence might be "Attend virtual 
meeting" set for 9:00 AM on a certain day, which the user would 
want to make happen at 9:00 AM on that day in the time zone where 
the timestamp was applied to the occurrence, regardless of the 
time zone where the user happened to be.


I found this distinction in a book called On Truth by Frank 
Ramsey, that was unfinished at his untimely death at age 26. 
"Event" and "occurrence" were Ramsey's suggestions.  He seemed to 
like "event", but thought "occurrence" would work, though it might 
be improved.


I enjoy having terms for these two kinds of happenings and I'm 
hopeful you'll find them useful, too.


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross  [2023-01-15 10:58]:
> WRT future timestamps, we would probably have to take the same
> approach as postgres i.e. the timezone rules in force at the time
> the timestamp is created are assumed to be 'forever'. While this is
> not true, it is really the only solution you can adopt and you just
> have ot accept that there is the chance that the rule will change in
> the future and the timestamp will then be incorrect.

Not sure if that is so. It is about representation. 

Database user in different time zone would see different time in his
time zone, while user in other time zone would see it different. This
makes more sense for people then using UTC, which is confusing for
people and which would imply that people somehow have to convert UTC
to their local time. Isn't it?

Imagine online meeting with 2 people in different time zones, they
share the Org heading with time stamp, but when user opens that Org
heading in Florida, will see different time according to his time
zone, while user in East Africa will see different time. 

Due to correct representation, both users now know when is the meeting
taking place, and they meet in same time.

If they would share UTC time, or any time without time zone
representation, they would get time coordination difficulties.

The type TIMESTAMP WITH TIME ZONE in PostgreSQL is always stored as
UTC and time zone rules are not forever.

The type TIMESTAMP WITH TIME ZONE automatically converts to proper
time zone. 

One could think for Org to simply become able to designate time zone
somewhere, be it generally for Org file or/and specific heading, or/and
specific timestamp. 

Then implement function to transform time to UTC, and then use
libraries or Emacs to transform UTC to designated time zone.

https://www.postgresql.org/docs/15/datatype-datetime.html

For timestamp with time zone, the internally stored value is always in
UTC (Universal Coordinated Time, traditionally known as Greenwich Mean
Time, GMT). An input value that has an explicit time zone specified is
converted to UTC using the appropriate offset for that time zone. If
no time zone is stated in the input string, then it is assumed to be
in the time zone indicated by the system's TimeZone parameter, and is
converted to UTC using the offset for the timezone zone.

When a timestamp with time zone value is output, it is always
converted from UTC to the current timezone zone, and displayed as
local time in that zone. To see the time in another time zone, either
change timezone or use the AT TIME ZONE construct (see Section 9.9.4).

Conversions between timestamp without time zone and timestamp with
time zone normally assume that the timestamp without time zone value
should be taken or given as timezone local time. A different time zone
can be specified for the conversion using AT TIME ZONE.



-- 
Jean

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

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross  [2023-01-14 23:25]:
> Yes, this is a problem. We really want a symbolic TZ
> specification and we would need 'smarts' i the timestamp generation code
> that is able to handle potential offset changes due to daylight savings
> transition etc. Even then, the transition time can change between when
> the timestamp is set for and when it actually occurs.

As PostgreSQL type TIMESTAMP WITH TIME ZONE is stored with underlying
UTC time, so should be Org times also be calculated with underlying
UTC times.

And in that case I just assume that operating system libraries ar
handling problem you have stated.

-- 
Jean

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

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Ihor Radchenko  [2023-01-14 16:23]:
> But why do we need any time zone data? All we need to converting from
> and to internal Emacs' time representation supplying the correct time
> zone to it.

When Org file is very personal and location centric, then there is no
need for it.

When Org file has assigned, shared tasks, and is related to other
people in various locations over the world, then it becomes important.

And when people travel from place to place they change time zones. You
changed it personally I bet, sometimes, did you? But as your work is
very personal it does not matter.

A record in Org file must be Org specific record. I guess that with
the general timezone property, such Org file, provided it has all the
same time zone, can have that specific time zone, and if shared to
somebody in other zone, that other person will see accurate time.

Because Org is very much single user centric for majority will not
matter really.

I can just imagine person in Brazil writing time zone records, so it
makes sense to know in which time zone that record was done, as if
somebody reads it in India, it will make less sense and it could cause
confusion.

-- 
Jean

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

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Max Nikulin  [2023-01-14 19:59]:
> On 14/01/2023 20:08, Jean Louis wrote:
> > * Max Nikulin [2023-01-14 10:14]:
> > > Let's assume <2023-01-15 Sun 09:00 +1>
> > > 
> > > It may be suitable for timestamps in the past, but future is more tricky.
> > > There is no problem if you are going to watch Lunar eclipse. However if 
> > > your
> > > plan is to attend a local event there is a chance that you will arrive at
> > > wrong time. Sometimes offset of timezones is changed and it may happen
> > > between the moment when you added a scheduled time and the moment of the
> > > event.
> > 
> > Can't follow you.
> > 
> > with "+1" I would say it is time zone.
> > 
> > Basic point is that users shall learn to express themselves by using
> > time zone.
> 
> "+1" is not a timezone, it is current offset shared by several timezones.
> You can not assure that time offset at a particular location would not
> change due to new administrative rules.

Fine, that was example to indicat time zone. I don't really use Org
for timestamps since quite some time, as every time stamp on my side
must be stored in database.

My Org usage is with generated read-only buffers these days. It is
good for representation and sometimes conversion to other files.

-- 
Jean

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

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

[BUG] ob-sql sql-connection-alist

[Andreas Gerler]

HI!

Last week I heard about using ob-sql with credentials stored in the variable 
used by isql.
However I had to modify ob-sql to get it actually working.
Can somebody test the pach before I send in a commit?

#+begin_src sql :engine mysql :dbconnection testdb
show tables;
#+end_src

(setq sql-connection-alist
  '((testdb (sql-product 'mysql)
(sql-server "127.0.0.1")
(sql-user "mysql”)
(sql-port 3306)
(sql-password “foo")
(sql-database "mysql"

I was considering writing another patch to map the sql-product to engine.
That way we could get rid of another parameter in the src block.
Opinions?



ob-sql.el.diff
Description: Binary data



Thanks in advance…


Andreas Gerler

—

http://www.bundesbrandschatzamt.de/~baron



signature.asc
Description: Message signed with OpenPGP

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Tim Cross  writes:

> Unfortunately, the common abbreviated forms like EST, AEST etc are
> inconsistent here. Some places will have a standard and a daylight
> savings type i.e. AEST and AEDT, while others will have just AEST. TO
> make it worse, two locations with the same time zone offset my use
> different versions i.e. Australia/Melbourn is AEST (+10/+11) and
> Australia/Sydney is AEST (+10) and AEDT (+11) and Australia/Brisbane is
> just AEST (+10). If everywhere which has daylight savings ensured they
> used a different abbreviation for daylight saving and non-daylight
> saving times, life would be easier, but they don't). Then of course
> there are many countries which don't have a symbolic letter abbreviation
> i.e. just have e.g -05 as their abbreviated TZ name.
>
> It is this and other related reasons why just relying on Emacs' internal
> API for times and dates is not sufficient. The abbreviated times have
> ambiguity and the full timezone specification is cumbersome and
> ugly. Even worse is that issue won't be shown up as failures - you will
> just silently get wrong results.  

So, basically we may need a way to (1) identify ambiguous TZ
specifications; (2) signal to user about potential issues.

Note that these are also optional features we may implement any time
once we have basic timezone support.

For (2) we may use something similar to `world-clock' - display user
timestamp at point for different time zones. Maybe via eldoc.

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Max Nikulin  writes:

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#30
> Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
> Thu, 14 Apr 2022 15:46:58 -0700
>> If you want to keep the TZDB identifier for advice about how to 
>> interpret dates relative to a timestamp, that's fine. But you should 
>> keep the UT offset in addition to the TZDB identifier, if you want your 
>> app to be fully accurate and useful. For example, you should store 
>> "1950-07-01 00:00:00 + Europe/Lisbon" for a timestamp generated by 
>> TZDB release 2021a, so that when you interpret the timestamp in release 
>> 2021b you'll have an idea of what you're dealing with.
>
> So keeping redundant information may be crucial to get warnings that 
> some timestamps need to be reviewed.

My takeaway from here is that automatically generated timestamps for
past events should better contain redundant information:

"1950-07-01 00:00:00 + Europe/Lisbon"

+ is what matters for time calculation while Europe/Lisbon indicates
the actual timezone being implied.

Then, if there is an event of TZ database change, Org might compare
+ vs. Europe/Lisbon and display warning if there is discrepancy.

For us, it means that we might potentially reserve 

<1950-07-01 00:00:00+@Europe/Lisbon> as a valid timestamp format.
Warning is optional feature we might implement in future.

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

Re: [BUG] CUSTOM_id ignored on blocks by ox-beamer

[Alan Schmitt]

Hello,

Please let me know if there is something I should do to help integrate
this patch.

Best,

Alan

On 2023-01-08 17:25, Alan Schmitt  writes:

> Hello,
>
> On 2023-01-05 09:26, Ihor Radchenko  writes:
>
>> If you look inside `org-beamer--format-block', it uses
>> `org-beamer-environments-default' and `org-beamer-environments-extra' to
>> format the blocks. See docstring for the latter for details.
>>
>> The code responsible for LaTeX block generation is
>>
>>  (when (nth 2 env-format) ; when we non-column block
>>   (concat
>>(org-fill-template ...) ; opening \begin lines
>>contents ; block body
>>... ; block closing \end lines
>>)
>>
>> org-fill-template is using the template from the
>> `org-beamer-environments-*' replacing %-chars as described in the
>> docstring.
>>
>> In order to handle CUSTOM_ID property, you can
>> (1) Introduce a new %-substitude to be handled in org-fill-template
>> call. It will insert block ID. (for example, using
>> `org-beamer--get-label')
>> (2) modify `org-beamer-environments-default' to insert label
>> appropriately.
>>
>> Patches welcome!
>
> Thank you for the detailed instructions. Here is my attempt at this.
> I’ve tested it and it works.
>
>>From 1747786c7106d0d90d9e8752e361552afacb2d4d Mon Sep 17 00:00:00 2001
> From: Alan Schmitt 
> Date: Sun, 8 Jan 2023 17:20:31 +0100
> Subject: [PATCH] Add labels to latex export of beamer blocks
>
> A new option %l is available to be used in `org-beamer-environments-*'
> to insert the label of the current block, obtained using
> `org-babel--get-label'
> ---
>  lisp/ox-beamer.el | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
> index 689bf1559..3518a0f50 100644
> --- a/lisp/ox-beamer.el
> +++ b/lisp/ox-beamer.el
> @@ -178,10 +178,10 @@ through `org-beamer-environments-extra' variable.")
>  ("quotation"  "q" "\\begin{quotation}%a %% %h""\\end{quotation}")
>  ("quote"  "Q" "\\begin{quote}%a %% %h""\\end{quote}")
>  ("structureenv"   "s" "\\begin{structureenv}%a %% %h" 
> "\\end{structureenv}")
> -("theorem""t" "\\begin{theorem}%a[%h]""\\end{theorem}")
> -("definition" "d" "\\begin{definition}%a[%h]" 
> "\\end{definition}")
> -("example""e" "\\begin{example}%a[%h]""\\end{example}")
> -("exampleblock"   "E" "\\begin{exampleblock}%a{%h}"   
> "\\end{exampleblock}")
> +("theorem""t" "\\begin{theorem}%a[%h]%l""\\end{theorem}")
> +("definition" "d" "\\begin{definition}%a[%h]%l" 
> "\\end{definition}")
> +("example""e" "\\begin{example}%a[%h]%l""\\end{example}")
> +("exampleblock"   "E" "\\begin{exampleblock}%a{%h}%l"   
> "\\end{exampleblock}")
>  ("proof"  "p" "\\begin{proof}%a[%h]"  "\\end{proof}")
>  ("beamercolorbox" "o" "\\begin{beamercolorbox}%o{%h}" 
> "\\end{beamercolorbox}"))
>"Environments triggered by properties in Beamer export.
> @@ -578,6 +578,7 @@ used as a communication channel."
>   (cons "O" (or raw-options ""))
>   (cons "h" title)
>   (cons "r" raw-title)
> +(cons "l" (format "\\label{%s}" (org-beamer--get-label 
> headline info)))
>   (cons "H" (if (equal raw-title "") ""
>   (format "{%s}" raw-title)))
>   (cons "U" (if (equal raw-title "") ""
> -- 
> 2.39.0
>
>
> Best,
>
> Alan


signature.asc
Description: PGP signature

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Tim Cross  writes:

>> In any case, selection of time zone for user timestamps is not something
>> we need to worry about in Org code. Users are to decide. Org might
>> assist, but I do not see anything meaningful we can do to help with DST.
>
> I think I basically agree with the last statement. However, perhaps we
> need to step back and ask ourselves what it is that people do want which
> drives this feature request. I doubt it is simply the ability to add TZ
> information to timestamps. I suspect the underlying motivation here is
> to have org mode actually use this information in a meaningful way,
> which essentially means all the complicated stuff I'm concerned about
> and which you seem to imply we wouldn't manage anyway.

I don't imply that. What I am saying is that we first need to decide on
syntax and provide basic support for time zones. It will already be
helpful as I won't need to convert timestamps into local time or think
if I need to convert timestamps ahead of time before a flight to
different time zone.

More things can be implemented once we have the basic support.

> To put it another way, we need to clarify what people mean when they
> request the feature of timestamp support in org-mode datestamps. What
> does this actually mean? Is it as simple as just being able to specify
> the timezone (seems relatively easy to implement, but doens't really add
> much) or is the expectation that once you have time zone information, it
> will be used to do things like adjust date+time in agenda based on
> change in locale or change in daylight savings status etc.

Converting timestamps with time zone to local time is indeed one of the
basic features we need to support.

> Clarifying the end goal will likely focus the discussion a lot
> more. My interpretation, which could well be too extreme, is that people
> want more than just the ability to add TZ info to their timestamps. They
> want their agenda to reflect correct meeting/schedule times based on
> their current locale, which may have changed since the initial timestamp
> was recorded. They want time duration calculations which are able to
> handle DS transitions etc, they want their agenda/calendar to adjust in
> a similar way to how their Google calendar will adjust based on DS
> transitions. 

I do not see any obstacle to having these basic features either. We
already use `encode-time' in time calculations across Org. So, all the
operations on times already use internal time representation. We will
get all the features you named pretty much for free just by supplying
time zone to `encode-time' calls.

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

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Samuel Wales  writes:

> On 1/14/23, Ihor Radchenko  wrote:
>> However, I do not see why we cannot implement them within the current
>> Org timestamp syntax:
>
> my concern would be personal code and 3rd-party packages, which might
> have their own peculiar parsing.

I proposed a single slight change in timestamp syntax:

<2023-01-14 Sat +1w/5x>

However, it is almost the same with what we have for habits:

<2023-01-14 Sat +1w/2w>

I do not see how things are going to break even if third-party packages
use some home-grown parsers.

> if otoh org provides really good api that can even do that, then i
> suppose you could tell those devs to use that api.

`org-get-repeat', `org-get-wdays', and `org-element-timestamp-parser'.

> also my personal preference is for less new org syntax.  which is one
> reason why i like cl-style sexp kw for future features and
> subfeatures.  syntax can be hard to look up in the org manual, hard to
> remember, etc.  but that's mho.

My proposal is as little new syntax as I was able to come up with.

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Max Nikulin  writes:

> On 14/01/2023 18:42, Ihor Radchenko wrote:
>> 
>> <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are 
>> often ambiguous)
>
> Such format is ambiguous for timezones with DST around backward time 
> jump. Before/after time transition should be specified in addition, e.g. 
> by combining identifier and offset or some way to state namely before or 
> after.

Are you referring to one hour in year when the clock is moved one hour
forward?

<2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute)
<2023-10-29 Sun 2:01@-DST/Europe/Berlin>

I, however, do not feel like we need this +/-DST special notation.
Chances that one needs a timestamp in this specific hour are slim. At
the end, countries deliberately choose the time transition to not
interfere with business activity.

Instead, we can simply allow
https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
formats. All of them are supported by `encode-time' anyway.

At least, in theory.
I just tried:

(time-subtract
(encode-time 0 1 3 29 10 2023 nil -1 ":Europe/Berlin")
(encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin"))

(see https://www.timeanddate.com/time/zone/germany/berlin)

and it looks like the expected return value should be 1 hour 2 minutes
(3720), but it is not, on my system.

I am probably missing something though.

>> <2023-01-14 Sat 18:22+0800>
>> <2023-01-14 Sat 18:22+08>
>> <2023-01-14 Sat 18:22@+0800>
>> <2023-01-14 Sat 18:22@+08>
>
> May become incorrect for future events due to updates of timezone database.

Emm. No? +8 is offset from UTC. It will not be affected by anything.
Or are you referring to scenarios when user actually wants to specify the
timestamp for specific country/city? Then the TZ variant should be used
instead.

What I am essentially proposing in these examples is allowing:
1. TZ format as described in 
https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

Of course, individual variants of time zone specs may be ambiguous
depending on the purpose. Users are to choose what they prefer

>> <2023-01-14 Sat 18:22@+08 +1w -5d>
>
> May be not suitable for time zones with DST since offset changes due to 
> time transitions.
>
> I am afraid, sometimes rather long (maybe even redundant) specification 
> is required, so overlays becomes must have (as for links) to keep 
> readability.

Not necessarily. Most of the timestamps can do just fine specifying
either explicit offset or a time zone name:

<2023-01-14 Sat 18:22@Asia/Singapore>
<2023-01-14 Sat 18:22+08>

More exotic scenarios will not be common.

And, if the users wish, we do have `org-time-stamp-custom-formats'.

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

[PATCH 2/4] Preserve active region when toggling heading state

[Ihor Radchenko]

* lisp/org.el (org-todo):
(org-deadline):
(org-schedule):
(org-set-tags-command): Do not deactivate region after applying edits.
---
 lisp/org.el | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 58a3434f4..9fd8189a7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9184,7 +9184,8 @@ (defun org-todo ( arg)
   (if (and (org-region-active-p) org-loop-over-headlines-in-active-region)
   (let ((cl (if (eq org-loop-over-headlines-in-active-region 'start-level)
'region-start-level 'region))
-   org-loop-over-headlines-in-active-region)
+   org-loop-over-headlines-in-active-region
+(deactivate-mark nil))
(org-map-entries
 (lambda () (org-todo arg))
 nil cl
@@ -10155,13 +10156,14 @@ (defun org-deadline (arg  time)
 can either be an Org date like \"2011-07-24\" or a delta like \"+2d\"."
   (interactive "P")
   (if (and (org-region-active-p) org-loop-over-headlines-in-active-region)
-  (org-map-entries
-   (lambda () (org--deadline-or-schedule arg 'deadline time))
-   nil
-   (if (eq org-loop-over-headlines-in-active-region 'start-level)
-  'region-start-level
-'region)
-   (lambda () (when (org-invisible-p) (org-end-of-subtree nil t
+  (let ((deactivate-mark nil))
+(org-map-entries
+ (lambda () (org--deadline-or-schedule arg 'deadline time))
+ nil
+ (if (eq org-loop-over-headlines-in-active-region 'start-level)
+'region-start-level
+   'region)
+ (lambda () (when (org-invisible-p) (org-end-of-subtree nil t)
 (org--deadline-or-schedule arg 'deadline time)))
 
 (defun org-schedule (arg  time)
@@ -10176,13 +10178,14 @@ (defun org-schedule (arg  time)
 either be an Org date like \"2011-07-24\" or a delta like \"+2d\"."
   (interactive "P")
   (if (and (org-region-active-p) org-loop-over-headlines-in-active-region)
-  (org-map-entries
-   (lambda () (org--deadline-or-schedule arg 'scheduled time))
-   nil
-   (if (eq org-loop-over-headlines-in-active-region 'start-level)
-  'region-start-level
-'region)
-   (lambda () (when (org-invisible-p) (org-end-of-subtree nil t
+  (let ((deactivate-mark nil))
+(org-map-entries
+ (lambda () (org--deadline-or-schedule arg 'scheduled time))
+ nil
+ (if (eq org-loop-over-headlines-in-active-region 'start-level)
+'region-start-level
+   'region)
+ (lambda () (when (org-invisible-p) (org-end-of-subtree nil t)
 (org--deadline-or-schedule arg 'scheduled time)))
 
 (defun org-get-scheduled-time (pom  inherit)
@@ -11633,7 +11636,8 @@ (defun org-set-tags-command ( arg)
  ((and (org-region-active-p) org-loop-over-headlines-in-active-region)
   (let ((cl (if (eq org-loop-over-headlines-in-active-region 'start-level)
'region-start-level 'region))
-org-loop-over-headlines-in-active-region) ;  hint: infinite 
recursion.
+org-loop-over-headlines-in-active-region ;  hint: infinite 
recursion.
+(deactivate-mark nil))
(org-map-entries
 #'org-set-tags-command
 nil cl
-- 
2.39.0

[PATCH 1/4] Preserve active region after structure edits

[Ihor Radchenko]

* lisp/org-list.el (org-list-indent-item-generic):
* lisp/org.el (org-do-promote):
(org-do-demote): Do not deactivate mark after edits.
(org-metadown):
(org-metaup): Do not deactivate mark and do not exchange point and
mark in region.
---
 lisp/org-list.el |  3 ++-
 lisp/org.el  | 64 
 2 files changed, 39 insertions(+), 28 deletions(-)

diff --git a/lisp/org-list.el b/lisp/org-list.el
index 1fc99d070..9fa072ce7 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -2688,7 +2688,8 @@ (defun org-list-indent-item-generic (arg no-subtree 
struct)
(no-subtree (1+ (line-beginning-position)))
(t (org-list-get-item-end (line-beginning-position) 
struct))
   (let* ((beg (marker-position org-last-indent-begin-marker))
-(end (marker-position org-last-indent-end-marker)))
+(end (marker-position org-last-indent-end-marker))
+ (deactivate-mark nil))
(cond
 ;; Special case: moving top-item with indent rule.
 (specialp
diff --git a/lisp/org.el b/lisp/org.el
index 59fe3d2d3..58a3434f4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6579,7 +6579,8 @@ (defun org-do-promote ()
   (interactive)
   (save-excursion
 (if (org-region-active-p)
-   (org-map-region 'org-promote (region-beginning) (region-end))
+(let ((deactivate-mark nil))
+  (org-map-region 'org-promote (region-beginning) (region-end)))
   (org-promote)))
   (org-fix-position-after-promote))
 
@@ -6590,7 +6591,8 @@ (defun org-do-demote ()
   (interactive)
   (save-excursion
 (if (org-region-active-p)
-   (org-map-region 'org-demote (region-beginning) (region-end))
+(let ((deactivate-mark nil))
+  (org-map-region 'org-demote (region-beginning) (region-end)))
   (org-demote)))
   (org-fix-position-after-promote))
 
@@ -16884,21 +16886,25 @@ (defun org-metaup ( _arg)
((run-hook-with-args-until-success 'org-metaup-hook))
((org-region-active-p)
 (let* ((a (save-excursion
-   (goto-char (region-beginning))
-   (line-beginning-position)))
-  (b (save-excursion
-   (goto-char (region-end))
-   (if (bolp) (1- (point)) (line-end-position
-  (c (save-excursion
-   (goto-char a)
-   (move-beginning-of-line 0)
-   (point)))
-  (d (save-excursion
-   (goto-char a)
-   (move-end-of-line 0)
-   (point
+(goto-char (region-beginning))
+(line-beginning-position)))
+   (b (save-excursion
+(goto-char (region-end))
+(if (bolp) (1- (point)) (line-end-position
+   (c (save-excursion
+(goto-char a)
+(move-beginning-of-line 0)
+(point)))
+   (d (save-excursion
+(goto-char a)
+(move-end-of-line 0)
+(point)))
+   (deactivate-mark nil)
+   (swap? (< (point) (mark
   (transpose-regions a b c d)
-  (goto-char c)))
+  (set-mark c)
+  (goto-char (+ c (- b a)))
+  (when swap? (exchange-point-and-mark
((org-at-table-p) (org-call-with-arg 'org-table-move-row 'up))
((and (featurep 'org-inlinetask)
  (org-inlinetask-in-task-p))
@@ -16917,21 +16923,25 @@ (defun org-metadown ( _arg)
((run-hook-with-args-until-success 'org-metadown-hook))
((org-region-active-p)
 (let* ((a (save-excursion
-   (goto-char (region-beginning))
-   (line-beginning-position)))
+(goto-char (region-beginning))
+(line-beginning-position)))
   (b (save-excursion
-   (goto-char (region-end))
-   (if (bolp) (1- (point)) (line-end-position
+(goto-char (region-end))
+(if (bolp) (1- (point)) (line-end-position
   (c (save-excursion
-   (goto-char b)
-   (move-beginning-of-line (if (bolp) 1 2))
-   (point)))
+(goto-char b)
+(move-beginning-of-line (if (bolp) 1 2))
+(point)))
   (d (save-excursion
-   (goto-char b)
-   (move-end-of-line (if (bolp) 1 2))
-   (point
+(goto-char b)
+(move-end-of-line (if (bolp) 1 2))
+(point)))
+   (deactivate-mark nil)
+   (swap? (< (point) (mark
   (transpose-regions a b c d)
-  (goto-char d)))
+  (set-mark (+ 1 a (- d c)))
+  (goto-char (+ 1 a (- d c) (- b a)))
+  (when swap? (exchange-point-and-mark
((org-at-table-p) (call-interactively 'org-table-move-row))
((and (featurep 'org-inlinetask)
  (org-inlinetask-in-task-p))
-- 
2.39.0

[PATCH 4/4] org-manual.org: Document changes in 8f6fcd709, 5719a8163, and eda9909a9

[Ihor Radchenko]

* etc/ORG-NEWS (~org-metaup~ and ~org-metadown~ now act on headings in region):
(Many structure editing commands now do not deactivate region):
Document new features when editing headings in region.
---
 etc/ORG-NEWS | 20 
 1 file changed, 20 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c5d9bdf6e..be918a45a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -12,6 +12,26 @@ See the end of the file for license conditions.
 Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
+** New features
+*** Many structure editing commands now do not deactivate region
+
+Moving, promoting, and demoting of headings and items in region now do
+not deactivate Transient mark mode.
+
+Users can thus conveniently select multiple headings/items and use,
+for example, =M-=/=M-= repeatedly without losing the
+selection.
+
+The same applies to setting heading states in region when
+~org-loop-over-headlines-in-active-region~ is non-nil.  ~org-todo~,
+~org-schedule~, ~org-deadline~, and ~org-set-tags-command~ are all
+affected.
+
+*** ~org-metaup~ and ~org-metadown~ now act on headings in region
+
+When region is active and starts at a heading, ~org-metaup~ and
+~org-metadown~ will move all the selected subtrees.
+
 ** New options
 *** New options for the "csl" citation export processor's LaTeX output
 
-- 
2.39.0

[PATCH 3/4] org-metaup, org-metadown: Move subtrees in active region

[Ihor Radchenko]

* lisp/org.el (org-metaup):
(org-metadown): When active region contains headings, move the
containing subtrees according to the selection.  Do not deactive
region.
* testing/lisp/test-org.el (test-org/move-subtree): Add test.
---
 lisp/org.el  | 46 ++
 testing/lisp/test-org.el | 54 
 2 files changed, 100 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 9fd8189a7..0c782769d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16888,6 +16888,30 @@ (defun org-metaup ( _arg)
   (interactive "P")
   (cond
((run-hook-with-args-until-success 'org-metaup-hook))
+   ((and (org-region-active-p)
+ (org-with-limited-levels
+  (save-excursion
+(goto-char (region-beginning))
+(org-at-heading-p
+(when (org-check-for-hidden 'headlines) (org-hidden-tree-error))
+(let ((beg (region-beginning))
+  (end (region-end)))
+  (save-excursion
+(goto-char end)
+(setq end (point-marker))
+(goto-char beg)
+(let ((level (org-current-level)))
+  (when (or (and (> level 1) (re-search-forward (format 
"^\\*\\{1,%s\\} " (1- level)) end t))
+;; Search previous subtree.
+(progn
+  (goto-char beg)
+  (beginning-of-line)
+  (not (re-search-backward (format "^\\*\\{%s\\} " level) 
nil t
+(user-error "Cannot move past superior level or buffer limit"))
+  ;; Drag first subtree above below the selected.
+  (while (< (point) end)
+(let ((deactivate-mark nil))
+  (call-interactively 'org-move-subtree-down)))
((org-region-active-p)
 (let* ((a (save-excursion
 (goto-char (region-beginning))
@@ -16925,6 +16949,28 @@ (defun org-metadown ( _arg)
   (interactive "P")
   (cond
((run-hook-with-args-until-success 'org-metadown-hook))
+   ((and (org-region-active-p)
+ (org-with-limited-levels
+  (save-excursion
+(goto-char (region-beginning))
+(org-at-heading-p
+(when (org-check-for-hidden 'headlines) (org-hidden-tree-error))
+(let ((beg (region-beginning))
+  (end (region-end)))
+  (save-excursion
+(goto-char beg)
+(setq beg (point-marker))
+(let ((level (org-current-level)))
+  (when (or (and (> level 1) (re-search-forward (format 
"^\\*\\{1,%s\\} " (1- level)) end t))
+;; Search next subtree.
+(progn
+  (goto-char end)
+  (not (re-search-forward (format "^\\*\\{%s\\} " level) 
nil t
+(user-error "Cannot move past superior level or buffer limit"))
+  ;; Drag first subtree below above the selected.
+  (while (> (point) beg)
+(let ((deactivate-mark nil))
+  (call-interactively 'org-move-subtree-up)))
((org-region-active-p)
 (let* ((a (save-excursion
 (goto-char (region-beginning))
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 7ed4ffd19..4c66fa038 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -5091,6 +5091,60 @@ (ert-deftest test-org/previous-block ()
 
 ;;; Outline structure
 
+(ert-deftest test-org/move-subtree ()
+  "Test `org-metaup' and `org-metadown' on headings."
+  (should
+   (equal "* H2\n* H1\n"
+  (org-test-with-temp-text "* H1\n* H2\n"
+(org-metadown)
+(buffer-string
+  (should
+   (equal "* H2\n* H1\n"
+  (org-test-with-temp-text "* H1\n* H2\n"
+(org-metaup)
+(buffer-string
+  (should-error
+   (org-test-with-temp-text "* H1\n* H2\n"
+ (org-metadown)
+ (buffer-string)))
+  (should-error
+   (org-test-with-temp-text "* H1\n* H2\n"
+ (org-metaup)
+ (buffer-string)))
+  (should-error
+   (org-test-with-temp-text "* H1\n** H1.2\n* H2"
+ (org-metadown)
+ (buffer-string)))
+  (should-error
+   (org-test-with-temp-text "* H1\n** H1.2\n"
+ (org-metaup)
+ (buffer-string)))
+  ;; With selection
+  (should
+   (equal "* T\n** H3\n** H1\n** H2\n"
+  (org-test-with-temp-text "* T\n** H1\n** H2\n** H3\n"
+(set-mark (point))
+(search-forward "H2")
+(org-metadown)
+(buffer-string
+  (should
+   (equal "* T\n** H1\n** H2\n** H0\n** H3\n"
+  (org-test-with-temp-text "* T\n** H0\n** H1\n** H2\n** H3\n"
+(set-mark (point))
+(search-forward "H2")
+(org-metaup)
+(buffer-string
+  (should-error
+   (org-test-with-temp-text "* T\n** H1\n** H2\n* T2\n"
+ (set-mark (point))
+ (search-forward "H2")
+ (org-metadown)))
+  (should-error
+   (org-test-with-temp-text "* T\n** H1\n** H2\n* T2\n"
+ (set-mark (point))
+ (search-forward "H2")
+ 

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

[Ihor Radchenko]

Hi,

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:

   * Heading 1
   text
   ** Sub
   * Heading 2
   * Heading 3

   {M-}

   * Heading 1
   text
   * Heading 2
   * Heading 3
   ** Sub

The patchset below addresses (2) by making org-metaup/org-metadown
aware of headings in region (when region starts at heading).

In addition, it alters M-/M-/M-/M- to not
deactivate active selection (Transient mark mode).  This way, one can
issue, say, M- repeatedly without having to re-select
everything.

Similarly, bulk editing commands like setting schedule, deadline,
tags, and todo do not deactivate region.

I'd appreciate testing on edge cases and ideas for tests.

Ihor Radchenko (4):
  Preserve active region after structure edits
  Preserve active region when toggling heading state
  org-metaup, org-metadown: Move subtrees in active region
  org-manual.org: Document changes in 8f6fcd709, 5719a8163, and
eda9909a9

 etc/ORG-NEWS |  20 ++
 lisp/org-list.el |   3 +-
 lisp/org.el  | 146 +++
 testing/lisp/test-org.el |  54 +++
 4 files changed, 179 insertions(+), 44 deletions(-)

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

Re: Bug: Inconsistent behaviour about inline markup

[Ihor Radchenko]

 writes:

> But please take this also as a BugReport (because there seems to be no
> regular bug tracker for orgmode). I see no need to restrict the allowed
> characters that way they are. PRE and POST should be the same.
> The only one exception is [ for POST because I suspect this isn't
> implementable via RegEx or would interfere with parsing of links.

The aim of limited PRE and POST is allowing dwim literal "*" in ordinary
text where users do not really intend to use emphasis.

The current approach is probably not ideal, but making changes to regexp
raises the risk of breaking existing Org documents that worked in the
past but may not because emphasis will be incorrectly recognized after
changing the syntax.

Any changes in this area should be done with caution.

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

Re: Bug: Inconsistent behaviour about inline markup

[c.buhtz]

Dear Timothy,

On 2023-01-15 14:22 Timothy  wrote:
> See .

Thanks a lot. That help to make my code consistent.

But please take this also as a BugReport (because there seems to be no
regular bug tracker for orgmode). I see no need to restrict the allowed
characters that way they are. PRE and POST should be the same.
The only one exception is [ for POST because I suspect this isn't
implementable via RegEx or would interfere with parsing of links.

Re: [PATCH][oc-csl] Improve reference parsing

[Ihor Radchenko]

M. ‘quintus’ Gülker  writes:

> I probably have not much to contribute to this rather technical thread,
> but Ihor has redirected me here two times for my citation formatting
> questions[1][2]. So I would like to ask if there is something I can do to
> accelerate its inclusion into org so that I can start using macros in
> citations?

András is the author of citeproc.el. I am not sure who else would be in
position to help us to move this forward.

My understanding of CSL is non-existing. I can only tell that
citeproc.el has its own implementation of citation export
(`citeproc-render-citations'), which expects some limited kind of html
as input. I am hoping that we can somehow work around limited markup
support of citeproc's implementation and instead leverage ox.el to do
the job. Otherwise, we will keep stumbling upon citeproc.el limitations
when exporting bibliography items.

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