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

[Max Nikulin]

On 21/01/2023 06:38, Tim Cross wrote:


- Use UTC for meetings which are not face-to-face and which involve
   people form different time zones.


I agree with you that it should considered as first option by whose who 
are planning an event. They still may prefer to choose timezone of 
particular location because it is mixed meeting with attenders of both 
types: face to face and online, or just because most of on-line 
participants are expected from particular area.


However timezone may be out of your control if you receive invitation to 
join on-line to some meeting. Attempt to convert it to UTC may lead to 
problems. So the reason to choose UTC or specific timezone for 
particular timestamp is not really technical one. It is just decision of 
some people.


Do you have any objection to the following statements:
- UTC is a recommendation for planning when participants are scattered 
over multiple timezones.
- You admit that some timestamps in your files may be specified as time 
zone identifier + local time relative to this zone.
- In both cases you may configure overlays to use local timezone or 
another one whatever you currently find convenient.

- Time chooser offers several time zone options.


I would also argue UTC is good for 'traditional' timestamps which record
a specific point in time and for situations where you want accurate
calculations of time durations.


Mostly agree, so I prefer to postpone discussion of details till 
confirming agreement in respect to future timestamps.

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

[Max Nikulin]

On 21/01/2023 07:37, Thomas S. Dye wrote:

1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not include UTC 
or a time zone; and 3)
Event not relative to user, where the timestamp includes the relevant 
time zone.


For a while I prefer to concentrate on future timestamps and postpone 
discussion of ones in the past.


As to format for storage timestamps in Org files, particular timestamps 
may have or not explicitly specified timezones, but it is unrelated to 
these 3 cases. It may be convenient to keep work.org file with TIMEZONE 
keyword for location of the office and do not specify it for each 
timestamps, so during a trip it allows to see correct time of regular 
meetings. In addition you may have personal.org file where most 
timestamps assumes timezone of your current presence. In both files some 
timestamps may have explicit timezone either "local follow me", UTC, or 
for particular location.


From my point of view these, 3 cases might be relevant to date-time 
picker UI, but not for storage format. While parsing, interpretation of 
each timestamp without explicit timezone depends on preferences chosen 
at higher scope.


Or, it might be a recurring virtual meeting that the boss wants to 
initiate at 9:00 AM her time, regardless of the time zone she happens to 
inhabit, as might happen on a business trip.


I believe that some manual action is required in this case anyway. You 
almost certainly already have 9:00 AM in your agenda as a reoccurring 
timestamp either with implicit or explicit timezone of usual presence. 
For the period of the trip it is necessary to add series of meetings 
with explicitly specified timezones (UTC or locations during the trip). 
Another approach is to define ad hoc "boss" timezone and update it to 
reflect all trips.


At the Org side it might be support of multiple ad hoc "timezones": a 
one for you personal trips and several ones for people you frequently 
communicate with. It is a nice option, but might be too complicated for 
usage. It may be easier to suspend regular entry and to add custom ones 
with no requirements related to the code. Anyway it assumes some 
communication between participants.

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

[Thomas S. Dye]

Aloha Tim,

Tim Cross  writes:


"Thomas S. Dye"  writes:


Aloha Max,

Max Nikulin  writes:


On 20/01/2023 23:09, Thomas S. Dye wrote:

Max Nikulin writes:
Now, if Amsterdam's timezone arbitrarily changes its relation 
to UTC before the

conference takes place,
then everyone who participates in the conference must notice 
this (or miss the

start of the conference).


My point is that if timestamp is stored in UTC than it becomes 
incorrect in the
case of time offset change. If such timestamp is stored as 
local time + time
zone identifier then application presenting the timestamp to 
users will show

correct time as soon as zoneinfo data is updated.

A virtual conference is organized by someone in Amsterdam, 
who sets a start
time corresponding to 9AM in Amsterdam at a date some years 
in the future and
invites participants from all over the world.  Now, if 
Amsterdam's timezone
arbitrarily changes its relation to UTC before the conference 
takes place,
then must everyone notice this?  Or, should Org, from the 
time the arbitrary change is

made public, simply adjust the conference time for all the
participants in the Amsterdam timezone?


Both variants are possible and a planning application should 
support them. It is
matter of negotiation between the committee and the 
participants. Timestamp

should be stored in UTC only in one case.


Agreed.  So, IIUC, there are three cases:

1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not include 
UTC or a time zone; and 3)
Event not relative to user, where the timestamp includes the 
relevant time zone.




I would argue case 2 is really just a specialisation of case 3 
i.e. it
has an implicit time zone which is the user's local time zone. 

Case 2 covers things the user wants to do at a particular time, 
regardless of where they are and the time zone they are in.  For a 
repeating task the time zone might change from one instance to the 
next.  It needs to follow the user around and can presumably rely 
on software to keep track of that.


For completeness, Case 3 might benefit from a procedure to 
change the relevant time zone.
For instance, when the boss has scheduled time for you at 9:00 
AM her time, but doesn't

know where she will be on that day.



If it is to be a fact-to-face meeting (event), implying it 
therefore has
a location, you would assume your local time zone. If not 
face-to-face
(occurrence), it needs a UTC offset in order to ensure same 
point in
time for all participants. The boss either needs to specify the 
time
zone they are referencing the 9am to or the user will need to 
make a

guess, which may or may not be correct.


Or, it might be a recurring virtual meeting that the boss wants to 
initiate at 9:00 AM her time, regardless of the time zone she 
happens to inhabit, as might happen on a business trip.  Here, the 
virtual meeting is an event because the boss relates it to her own 
space/time.  Inconvenient for employees, but some bosses are like 
that.  Here, the time zone needs to follow the boss around.


My current hypothesis is that the three cases are exhaustive.

All the best,
Tom

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

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

[Tim Cross]

"Thomas S. Dye"  writes:

> Aloha Max,
>
> Max Nikulin  writes:
>
>> On 20/01/2023 23:09, Thomas S. Dye wrote:
>>> Max Nikulin writes:
>>> Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before 
>>> the
>>> conference takes place,
>>> then everyone who participates in the conference must notice this (or miss 
>>> the
>>> start of the conference).
>>
>> My point is that if timestamp is stored in UTC than it becomes incorrect in 
>> the
>> case of time offset change. If such timestamp is stored as local time + time
>> zone identifier then application presenting the timestamp to users will show
>> correct time as soon as zoneinfo data is updated.
>>
>>> A virtual conference is organized by someone in Amsterdam, who sets a start
>>> time corresponding to 9AM in Amsterdam at a date some years in the future 
>>> and
>>> invites participants from all over the world.  Now, if Amsterdam's timezone
>>> arbitrarily changes its relation to UTC before the conference takes place,
>>> then must everyone notice this?  Or, should Org, from the time the 
>>> arbitrary change is
>>> made public, simply adjust the conference time for all the
>>> participants in the Amsterdam timezone?
>>
>> Both variants are possible and a planning application should support them. 
>> It is
>> matter of negotiation between the committee and the participants. Timestamp
>> should be stored in UTC only in one case.
>
> Agreed.  So, IIUC, there are three cases:
>
> 1) Occurrence, where the timestamp includes UTC;
> 2) Event relative to user, where the timestamp does not include UTC or a time 
> zone; and 3)
> Event not relative to user, where the timestamp includes the relevant time 
> zone.
>

I would argue case 2 is really just a specialisation of case 3 i.e. it
has an implicit time zone which is the user's local time zone. 

> For completeness, Case 3 might benefit from a procedure to change the 
> relevant time zone.
> For instance, when the boss has scheduled time for you at 9:00 AM her time, 
> but doesn't
> know where she will be on that day.
>

If it is to be a fact-to-face meeting (event), implying it therefore has
a location, you would assume your local time zone. If not face-to-face
(occurrence), it needs a UTC offset in order to ensure same point in
time for all participants. The boss either needs to specify the time
zone they are referencing the 9am to or the user will need to make a
guess, which may or may not be correct.

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

[Tim Cross]

Max Nikulin  writes:

> On 20/01/2023 15:17, Tim Cross wrote:
>> So far, nobody has shown any reason why using UTC to distinguish the
>> case where the times need to be adjusted and local tz when they don't
>> won't work a a  mechanism that can be used to allow org to handle things
>> better than it does now.
>
> Let's try to move in small steps. UTC as storage format.
>
> An issue with events scheduled as local time in some particular timezone (not 
> your current
> one) and stored as UTC timestamp when IANA tzdata is updated to use new 
> timezone offset:
>
> https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
> Storing UTC is not a silver bullet
>
> Do you think it should be ignored? I faced such issue.

I now think I can see where you have become confused.

I am NOT arguing that all timestamps should be stored in UTC.

I am only saying that when you have a meeting which is not face to face
and involves people from various time zones, the date+time for that
meeting should be stored in UTC. This is the only way org will be able
to ensure the meeting time (which would be converted into local time for
the user) stays relative to the other participants after a daylight
savings transition.

The use cases here is completely different from the example outlined in
that long article.  Firstly, much of the complications arising in that
example are due to tryhing to coordinate dates and times for multiple
parties. Here we are only focusing on 1 party. Secondly, I am only
proposing UTC for meetings where there is no physical location for the
meeting. In the case where there is a physical location, that is a
fact-to-face meeting and it should be recorded in the time zone of the
location of that meeting. In most cases, that will be the user's local
time zone, so for most face=to=face meetings, no explicit time zone is
necessary as the local time zone will be assumed.

So in summary, my argument is

- Use UTC for meetings which are not face-to-face and which involve
  people form different time zones.

- Use the time zone of the location of a meeting when the meeting is
  face-to-face and has a physical locaiton.

- Provide an interface in org to make it easier for users to select the
  correct format (UTC or lcoal/meeting tz). Exactly the best way to do
  this is yet to be determined. It could be just a general solution
  which allows you to select the TZ when you call the functions with C-u
  or it could be something more sophisticated and specific to booking
  meetings which asks questions (i.e. type of record meeting wiard).

- It is assumed that in most cases, timestamps will b displayed to the
  user in their local time zone regardless of how they are actualy
  recorded int he org file.

I suspect where you have become confused is because you read my first
post in the thread where I suggested using UTC for meetings would be
sufficient. However, I revised that based on responses and then proposed
only using UTC for meetings which are not face-to-face and where
participants are from different time zones. It appears you have missed
those posts. 

I would also argue UTC is good for 'traditional' timestamps which record
a specific point in time and for situations where you want accurate
calculations of time durations. In fact, I would argue that UTC is a
good choice for a majority of time stamps, but acknowledge there are
some situations, notably when scheduling an event with a physical
location, where it is better to use the time zone of the location. 

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

[Tim Cross]

Max Nikulin  writes:

> On 20/01/2023 15:11, Tim Cross wrote:
>> Max Nikulin writes:
>> 
>>> Tim, I am trying to say that any meeting either face to face or on-line may 
>>> be associated
>>> with arbitrary primary timezone.
>> and what you are saying is helpful how? In what way does what you are
>> sayhing help address my use case?
>
> Tim, are you trying to convince me that for Org it is enough to have 
> timestamps either as
> local time <2023-02-20 15:00> or as UTC something like <2023-02-20 05:00Z> 
> and ability to
> specify arbitrary timezone instead of UTC is redundant?
>

No. I have never stated anything like that. 

> I believe that in the case of support of optional arbitrary timezone in Org 
> files there is
> no point of distinction between you cases when all participants meet face to 
> face
> (<2023-02-20 15:00> or <2023-02-20 15:00@Australia/Sydney>) or it is online 
> meeting
> scheduled as <2023-02-20 09:00@Etc/UTC>.

That is all I've been saying! For meetings where everyone is in same
time zone, just use either  OR > and for meetings where there are participants from
different time zones, use . That simple.

All that remains is to figure out the best interface to make it easy for
the user to have the correct timestamp for the correct meeting type. 

>
>>> UI might offer you to choose time in your timezone and to select another 
>>> timezone for
>>> storage. For your convenience it still may be presented to you in your 
>>> local timezone even
>>> it is stored in UTC or some other one.
>> and I have said as much. So, how exactly is your contribution assisting
>> with the use case I've outlined?
>
> I had a hope to assure you that unifying the cases you are considering as 
> distinct should
> not make user experience worse.
>
> Local event and UTC is meaningful for UI to enter or adjust timestamp where 
> such cases
> should be easier to select than arbitrary timezone. For parsing, generating 
> agenda, or
> export a more abstract model can be used.

I really don't understand your continued reference to 'arbitrary
timezone' or how it is relevant. I also am not clear what you mean by
'unifying the cases'. If you mean handling the two different cases in
the same UI, that is exactly what I've been suggesting. If you mean
using the same time zone for both cases, I don't see how that could
possibly work and if you mean something else, I don't understand.

My position is very simple and very specific. Either use no TZ info or
local TZ spec for meetings where all participants are in the same TZ and
ust UTC where you have participants from different TZs. Note that htis
says nothing about how the timestamp is displayed (I would argue for
user's local time using an overlay or similar, like we do for links and
markup) and it says nothing about how the other participants record the
meeting (it is specific to the org user) and it says nothing about other
users for timestamps - only in reference to scheduled events.

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

[Tim Cross]

Daryl Manning  writes:

> Perhaps a leading question (leading to outrage =p ), but does anybody even 
> use those anymore? 
>
> I don't believe I've used them at all in 5 years of using org-mode (and if I 
> did it was most likely because of
> some arcane older feature which required them). 
>
> Daryl. 
>
> On Fri, Jan 20, 2023 at 5:57 PM Ihor Radchenko  wrote:
>
>  Ihor Radchenko  writes:
>
>  > <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are 
> often ambiguous)
>  > <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>
>
>  One thing we all missed in the discussion is diary sexps.
>
>  In particular, "last Sunday of month" <%%(diary-float t 0)> may depend
>  on the time zone because the number of days in month may vary.
>
>  How can we approach this? What could the format to specify the time zone
>  for diary timestamps?
>
>  -- 
>  Ihor Radchenko // yantar92,
>  Org mode contributor,
>  Learn more about Org mode at .
>  Support Org development at ,
>  or support my work at 

If your speaking about diary sexp support, I don't use them, but I have
seen a number of threads within the last year regarding people wanting
assistance with getting them right and I get the impression for some use
cases, particularly for repeating events, diary seexp specification is
the easiest way to define them.

Re: [BUG] ob-sql sql-connection-alist

[Andreas Gerler]

Hi Daniel,

I already contributed to Orgmode a few years ago for Vertica support and filled 
the copyright assignment back then.

Andreas

> On Jan 20, 2023, at 9:47 PM, Daniel Kraus  wrote:
> 
> Thanks.
> 
> @Ihor, since this is the first patch I install from another contributor,
> is there anything I should look out for?
> 
> E.g. does this need a TINYCHANGE entry or something?
> Or do you have already copyright assignments filled out, Andreas and
> then it's not necessary?
> Can I see somewhere who I need to ask for copyright assignments or not?
> 
> Thanks,
>  Daniel
> 

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin  writes:


On 20/01/2023 23:09, Thomas S. Dye wrote:

Max Nikulin writes:
Now, if Amsterdam's timezone 
arbitrarily changes its relation to UTC before the conference 
takes place,
then everyone who participates in the conference must notice 
this (or miss the

start of the conference).


My point is that if timestamp is stored in UTC than it becomes 
incorrect in the
case of time offset change. If such timestamp is stored as local 
time + time
zone identifier then application presenting the timestamp to 
users will show

correct time as soon as zoneinfo data is updated.

A virtual conference is organized by someone in Amsterdam, who 
sets a start
time corresponding to 9AM in Amsterdam at a date some years in 
the future and
invites participants from all over the world.  Now, if 
Amsterdam's timezone
arbitrarily changes its relation to UTC before the conference 
takes place,
then must everyone notice this?  Or, should Org, from the time 
the arbitrary 
change is made public, simply adjust the conference time for 
all the

participants in the Amsterdam timezone?


Both variants are possible and a planning application should 
support them. It is
matter of negotiation between the committee and the 
participants. Timestamp

should be stored in UTC only in one case.


Agreed.  So, IIUC, there are three cases:

1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not include 
UTC or a time zone; and 
3) Event not relative to user, where the timestamp includes the 
relevant time zone.


For completeness, Case 3 might benefit from a procedure to change 
the relevant time zone.  For instance, when the boss has scheduled 
time for you at 9:00 AM her time, but doesn't know where she will 
be on that day.


hth,
Tom

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

Re: [BUG] ob-sql sql-connection-alist

[Daniel Kraus]

Thanks.

@Ihor, since this is the first patch I install from another contributor,
is there anything I should look out for?

E.g. does this need a TINYCHANGE entry or something?
Or do you have already copyright assignments filled out, Andreas and
then it's not necessary?
Can I see somewhere who I need to ask for copyright assignments or not?

Thanks,
  Daniel

Re: [FR] Add C-u and C-u C-u prefix arguments to org-paste-subtree (was: Make org-paste-subtree more predictable and useful)

[Philipp Kiefer]

On 20.01.2023 11:21, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Further, you suggest I use C-S- to demote the subtree after
pasting it at the same level as the subtree at point. But what if I used
a numerical prefix argument to copy or cut several subtrees, maybe 5 or
10? Not very convenient at all to demote them all by hand...

I still hold that pasting headings / subtress either at the same level
or at the child level of the target heading is part of the bread and
butter of outline editing and should be as straightforward as possible.
I'm rather sure the current numeric prefixes of org-paste-subtree to
select a distinct level at which to paste are needed / used much less
frequently than a "paste at child level" prefix (maybe C-u C-u?) would
be if it was implemented.

Could you please provide concrete ideas what C-u/C-u C-u should do?
In particular, how it will interact with point located at heading,
at heading beginning, at empty heading, or inside a heading section.
To be honest, I don't see much need for fine-grained special cases. I'd 
be very happy with C-u yanking at the level of the heading at point and 
C-u C-u yanking at one level below that, regardless of the exact 
position of point. I realize that would mean C-u doubling what can 
already be done by calling org-paste-subtree with point at the beginning 
of a heading but accessing both options (paste as sibling or child) with 
a single or repeat C-u seems more consistent to me than having one 
depend on position and getting at the other via the command prefix.


Thanks a lot for your dedication in working on this!

Re: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite

[Edgar Lux]

LOL What an idio...! (sorry)

January 20, 2023 at 11:59:22 AM CET Ihor Radchenko  
wrote:Edgar Lux  writes:

> I send the attached patch for your consideration. It allows to use biber for
bibliographies. I tested it with this:

Thanks, but could you please attach the patch?

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

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


oc-natbib.el.patch.gz
Description: File Attachment: oc-natbib.el.patch.gz

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]

Ihor Radchenko  writes:


No Wayman  writes:

Feel free to take this the patch as a base to do whatever you 
please with it.


Then, I am thinking about a simple approach that will not 
involve

internet connection. See the attached.


I think that's the best solution. I landed on something similar 
for Elpaca (and will likely suggest the same for straight.el).


Note that you, in fact, can fetch the latest tags from remote 
into

shallow clone. See
https://stackoverflow.com/questions/66349002/get-latest-tag-git-describe-tags-when-repo-is-cloned-with-depth-1


Seems more complicated than it's worth at this point.


   # 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)
+  GITVERSION ?= $(shell git describe --match release\* 
--abbrev=6 HEAD 2>/dev/null || echo  "release_N/A-N/A-$(shell 
git log --format=%h HEAD^..HEAD)")


Why not use ORGVERSION here? Is the metadata in org.el's version 
header not updated when a commit is tagged as a release?

Re: [BUG] ob-sql sql-connection-alist

[Andreas Gerler]

Sorry. That was the wrong patch.



0001-lisp-ob-sql.el-allow-string-in-sql-connection-alist.patch
Description: Binary data


> On 20. Jan 2023, at 18:24, Andreas Gerler  
> wrote:
> 
> <0001-lisp-ob-eval.el-Display-error-fix.patch>
> 
>> On 16. Jan 2023, at 11:25, Daniel Kraus  wrote:
>> 
>> Hi!
>> 
>> Andreas Gerler  writes:
>> 
>>> 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
>> 
>> I actually use this feature daily.
>> You have to quote the dbconnection. So this works currently:
>> 
>>> #+begin_src sql :engine mysql :dbconnection 'testdb
>> 
>> but I would agree that not needing the quote makes sense.
>> And since `assoc-string` works with symbol and string (i.e. it's backwards 
>> compatible)
>> I would install the patch if you send it.
>> 
>>> 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?
>> 
>> I agree. Specifying :engine when it's already in the connection-alist is 
>> unnecessary.
>> 
>> Thanks,
>> Daniel
> 



signature.asc
Description: Message signed with OpenPGP

Re: [BUG] ob-sql sql-connection-alist

[Andreas Gerler]

0001-lisp-ob-eval.el-Display-error-fix.patch
Description: Binary data


> On 16. Jan 2023, at 11:25, Daniel Kraus  wrote:
> 
> Hi!
> 
> Andreas Gerler  writes:
> 
>> 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
> 
> I actually use this feature daily.
> You have to quote the dbconnection. So this works currently:
> 
>> #+begin_src sql :engine mysql :dbconnection 'testdb
> 
> but I would agree that not needing the quote makes sense.
> And since `assoc-string` works with symbol and string (i.e. it's backwards 
> compatible)
> I would install the patch if you send it.
> 
>> 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?
> 
> I agree. Specifying :engine when it's already in the connection-alist is 
> unnecessary.
> 
> Thanks,
>  Daniel



signature.asc
Description: Message signed with OpenPGP

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

[Max Nikulin]

On 20/01/2023 23:09, Thomas S. Dye wrote:

Max Nikulin writes:

Now, if Amsterdam's timezone 
arbitrarily changes its relation to UTC before the conference takes 
place, then everyone who participates in the conference must notice this 
(or miss the start of the conference).


My point is that if timestamp is stored in UTC than it becomes incorrect 
in the case of time offset change. If such timestamp is stored as local 
time + time zone identifier then application presenting the timestamp to 
users will show correct time as soon as zoneinfo data is updated.


A virtual conference is organized by 
someone in Amsterdam, who sets a start time corresponding to 9AM in 
Amsterdam at a date some years in the future and invites participants 
from all over the world.  Now, if Amsterdam's timezone arbitrarily 
changes its relation to UTC before the conference takes place, then must 
everyone notice this?  Or, should Org, from the time the arbitrary 
change is made public, simply adjust the conference time for all the 
participants in the Amsterdam timezone?


Both variants are possible and a planning application should support 
them. It is matter of negotiation between the committee and the 
participants. Timestamp should be stored in UTC only in one case.

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin  writes:


On 20/01/2023 15:17, Tim Cross wrote:
So far, nobody has shown any reason why using UTC to 
distinguish the
case where the times need to be adjusted and local tz when they 
don't
won't work a a  mechanism that can be used to allow org to 
handle things

better than it does now.


Let's try to move in small steps. UTC as storage format.

An issue with events scheduled as local time in some particular 
timezone (not
your current one) and stored as UTC timestamp when IANA tzdata 
is updated to use

new timezone offset:

https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
Storing UTC is not a silver bullet

Do you think it should be ignored? I faced such issue.


Good example!  Thanks for the link.

Note that the problem of arbitrary change of a timezone's relation 
to UTC might be handled differently for occurrences and events.


The blog example is 9AM in Amsterdam at a date some years in the 
future.  Because the example includes a place, it refers to 
space/time, and is an event (not an occurrence).  Now, if 
Amsterdam's timezone arbitrarily changes its relation to UTC 
before the conference takes place, then everyone who participates 
in the conference must notice this (or miss the start of the 
conference).


Let's consider an occurrence.  A virtual conference is organized 
by someone in Amsterdam, who sets a start time corresponding to 
9AM in Amsterdam at a date some years in the future and invites 
participants from all over the world.  Now, if Amsterdam's 
timezone arbitrarily changes its relation to UTC before the 
conference takes place, then must everyone notice this?  Or, 
should Org, from the time the arbitrary change is made public, 
simply adjust the conference time for all the participants in the 
Amsterdam timezone?  The latter makes sense to me--all the 
participants in Amsterdam will be aware of the arbitrary change, 
so will not be surprised when Org calculates a different start 
time. Such a change would almost certainly confuse participants 
unaware of the arbitrary change in Amsterdam timezone.


hth,
Tom



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

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

[Max Nikulin]

On 18/01/2023 23:20, Jean Louis wrote:

Is there any program, software, system, that is really so good with
time, apart from PostgreSQL database that I know with 1195 defined
time zones?

...

   name  | abbrev | utc_offset | is_dst
+++
  NZ | NZDT   | 13:00:00   | t
  GB-Eire| GMT| 00:00:00   | f


What conclusion should we make looking at this long table? I am unsure 
concerning difference from content of tzdata package (IANA or Olson DB) 
that is rather standard on Linux. Emacs uses it though libc (API has 
some limitations, but conversion from UTC to local time should be 
accurate). Various programming languages have libraries to use this 
database.


https://www.iana.org/time-zones

I can not say anything concerning Windows besides that I have seen 
tables for mapping of tzids to IANA timezones.

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

[Max Nikulin]

On 20/01/2023 15:11, Tim Cross wrote:

Max Nikulin writes:


Tim, I am trying to say that any meeting either face to face or on-line may be 
associated
with arbitrary primary timezone.


and what you are saying is helpful how? In what way does what you are
sayhing help address my use case?


Tim, are you trying to convince me that for Org it is enough to have 
timestamps either as local time <2023-02-20 15:00> or as UTC something 
like <2023-02-20 05:00Z> and ability to specify arbitrary timezone 
instead of UTC is redundant?


I believe that in the case of support of optional arbitrary timezone in 
Org files there is no point of distinction between you cases when all 
participants meet face to face (<2023-02-20 15:00> or <2023-02-20 
15:00@Australia/Sydney>) or it is online meeting scheduled as 
<2023-02-20 09:00@Etc/UTC>.



UI might offer you to choose time in your timezone and to select another 
timezone for
storage. For your convenience it still may be presented to you in your local 
timezone even
it is stored in UTC or some other one.


and I have said as much. So, how exactly is your contribution assisting
with the use case I've outlined?


I had a hope to assure you that unifying the cases you are considering 
as distinct should not make user experience worse.


Local event and UTC is meaningful for UI to enter or adjust timestamp 
where such cases should be easier to select than arbitrary timezone. For 
parsing, generating agenda, or export a more abstract model can be used.

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

[Daryl Manning]

I just usually put those in the cal manually, with a date if they have
"unusual" recurrences that can;t be denoted by the standard datestamp
recurrences . =]

Though for religious holidays like Easter and, I imagine, some lunar based
ones, I imagine it might be handy. But honestly, I am surprised people use
them anymore. I certainly have managed to avoid them up to now. They feel
slightly anachronistic (much like putting in dates without timezones... =]
).

D.

On Fri, Jan 20, 2023 at 6:36 PM Ihor Radchenko  wrote:

> Daryl Manning  writes:
>
> > Perhaps a leading question (leading to outrage =p ), but does anybody
> even
> > use those anymore?
> >
> > I don't believe I've used them at all in 5 years of using org-mode (and
> if
> > I did it was most likely because of some arcane older feature which
> > required them).
>
> diary exps is the only available way to limit the number of repetitions
> of an even.
>
> Also, see org-class, which will automatically skips holidays (let's just
> ignore the issue with time zones and holidays, please; just accept the
> limitation)
>
> Some real word examples of diary sexps scheduling in the wild:
> - https://emacs-apac.gitlab.io/ :: <%%(diary-float t 6 4)>
> - https://emacs-berlin.org/ :: <%%(diary-float t 3 -1)>
>
> Finally, religious holidays can be defined and Nth weekday before/after
> month/date.
>
> Some people even use diary sexps exclusively.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

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

[Max Nikulin]

On 20/01/2023 19:44, Ihor Radchenko wrote:

diff --git a/mk/targets.mk b/mk/targets.mk
index 4435daa..164b092 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -14,7 +14,7 @@ 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)
+  GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD 2>/dev/null || echo  "release_N/A-N/A-$(shell git log --format=%h 


another option is to use --always

git describe --match release\* --abbrev=6 --always HEAD
52f29d

and some make code that prepends it with release_$(ORGVERSION)- if it 
has not release prefix.


Earlier posted patches attempts to make remote query even if history 
depth of local copy is enough to include a commit tagged as release. I 
have found some recipes how to modify "git fetch" to get enough objects 
for "git describe", but I have never used them, so unsure concerning 
their reliability. Perhaps they may be used in CI configuration, namely 
in the script preparing source directory, since fetch is not 
responsibility of make.

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

[Alexander Adolf]

Ihor Radchenko  writes:

> [...]
> 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.
> [...]
>
> Converting timestamps with time zone to local time is indeed one of the
> basic features we need to support.
> [...]

I fully concur with Ihor.

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

[Ihor Radchenko]

Ihor Radchenko  writes:

> Could you please re-submit the patch altering the commit message stating
> the reason I stated? Also, Please quote Elisp symbols in the commit
> message as we usually do. See
> https://orgmode.org/worg/org-contribute.html#commit-messages

This is no longer needed as this exact line generated a bug reported in
https://list.orgmode.org/4579f9d7-af96-2818-e12d-546040157...@gmail.com/T/#t

I removed the `temporary-file-directory' function call while fixing that
bug.

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

Re: org-ref (including cite or not) and references with numbers exporting to HTML

[Ihor Radchenko]

Uwe Brauer  writes:

> Well concerning the LaTeX exporter, you are right, but for the HTML
> exporter

I think you need to use CSL then.

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

Re: org-ref (including cite or not) and references with numbers exporting to HTML

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>> 1. When I use org-ref-helm-insert-cite-link, either I obtain
>> cite:tao06:_global
>> or
>> cite:Choquet-Bruhat_09
>> but I cannot spot any difference  in my bibfile, save that the
>> tao06 reference has a : in its key and indeed adding a : to the
>> second  reference also insert a cite:
>> any reason for this behavior?

> CCing John.

>> 2. Independent of this, when exporting to HTML
>> In the text, the references are tao06:_global with a link
>> how can I have numbers with links instead

> You just need an appropriate bibliography style. See
> https://github.com/jkitchin/org-ref/blob/master/org-ref.org#bibliography-links

Well concerning the LaTeX exporter, you are right, but for the HTML
exporter



cite:tao06:_global


bibliographystyle:plain
bibliography:/home/oub/texmf/bibtex/bib/bibgraf.bib


Does not make any difference.

But I don't know how to configure the HTML exporter with that respect. I
know how to configure the list of references, say the name of the
Journal in bold face for example.

But not how to configure the citation form in the text




-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

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

[Ihor Radchenko]

No Wayman  writes:

> Feel free to take this the patch as a base to do whatever you 
> please with it.

Then, I am thinking about a simple approach that will not involve
internet connection. See the attached.

Note that you, in fact, can fetch the latest tags from remote into
shallow clone. See
https://stackoverflow.com/questions/66349002/get-latest-tag-git-describe-tags-when-repo-is-cloned-with-depth-1

>From 93a75bcd3f8badf11c9234e5336e450d2d2baf60 Mon Sep 17 00:00:00 2001
Message-Id: <93a75bcd3f8badf11c9234e5336e450d2d2baf60.1674218582.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Fri, 20 Jan 2023 15:25:33 +0300
Subject: [PATCH] * mk/targets.mk(GITVERSION): Provide commit number for
 shallow clones

Fall back to using git log when git describe fails in Org repo.

See https://orgmode.org/list/87bkmve8qv@gmail.com
---
 mk/targets.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 4435daa..164b092 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -14,7 +14,7 @@ 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)
+  GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD 2>/dev/null || echo  "release_N/A-N/A-$(shell git log --format=%h HEAD^..HEAD)")
   GITSTATUS  ?= $(shell git status -uno --porcelain)
 else
  -include mk/version.mk
-- 
2.39.1


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

"Fraga, Eric"  writes:

> However, having said this, I don't think it's org's responsibility to
> address the Emacs Diary: that would be a feature request for Emacs more
> generally...

Well. Diary sexps do not support time. So, we may already need to add
time info to diary sexps (at least, it is partially supported
by agenda). But if we add time support, the time stamp question also
arises.

Of course, more generally, there is also a question of things like
calendar displaying time in different time zone (for example, when
choosing timestamp date and time in `org-read-date').

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

[Fraga, Eric]

On Friday, 20 Jan 2023 at 18:29, Daryl Manning wrote:
> Perhaps a leading question (leading to outrage =p ), but does anybody
> even use those anymore?

Yes.  I use them for repeating events, in particular those which have
repeating rules like "the first Monday of every month" that org does not
support.

However, having said this, I don't think it's org's responsibility to
address the Emacs Diary: that would be a feature request for Emacs more
generally...

-- 
: Eric S Fraga, with org release_9.6-201-gb58fba in Emacs 30.0.50

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

[Ihor Radchenko]

Daryl Manning  writes:

> Perhaps a leading question (leading to outrage =p ), but does anybody even
> use those anymore?
>
> I don't believe I've used them at all in 5 years of using org-mode (and if
> I did it was most likely because of some arcane older feature which
> required them).

diary exps is the only available way to limit the number of repetitions
of an even.

Also, see org-class, which will automatically skips holidays (let's just
ignore the issue with time zones and holidays, please; just accept the
limitation)

Some real word examples of diary sexps scheduling in the wild:
- https://emacs-apac.gitlab.io/ :: <%%(diary-float t 6 4)>
- https://emacs-berlin.org/ :: <%%(diary-float t 3 -1)>

Finally, religious holidays can be defined and Nth weekday before/after
month/date.

Some people even use diary sexps exclusively.

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

Re: New face: org-agenda-calendar-timerange

[Bastien Guerry]

Hi,

Ihor Radchenko  writes:

> Now, just waiting for confirmation from Bastien about your copyright
> status records.

Yes, I confirme Gautier's FSF copyright record is in order.

> AFAIU, the commit fixed a different scenario:
> https://orgmode.org/list/byapr07mb573496c31816fe64b71e9d70a5...@byapr07mb5734.namprd07.prod.outlook.com
>
> <2019-08-05 Mon 08:30-11:00>--<2019-08-09 Fri 08:30-11:00>
>
> (which is, by the way, is not a proper time range, according to Org
> syntax)

I agree we should not allow this syntax from David's initial example.

> Bastien, the commit asserts that when time parts of the timestamp range
> are equal, treat them as repeating event, like <2019-08-05 Mon 08:30-11:00 
> +1d>
> However, when there is an actual date range as in Gautier's example,
> things are broken.
>
> I am inclined to revert your commit because the original bug report was
> trying to make Org use timestamp format, Org does not really
> recognize.

Yes, please do. Thanks!

-- 
 Bastien

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

[Daryl Manning]

Perhaps a leading question (leading to outrage =p ), but does anybody even
use those anymore?

I don't believe I've used them at all in 5 years of using org-mode (and if
I did it was most likely because of some arcane older feature which
required them).

Daryl.

On Fri, Jan 20, 2023 at 5:57 PM Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
> > <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations
> are often ambiguous)
> > <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>
>
> One thing we all missed in the discussion is diary sexps.
>
> In particular, "last Sunday of month" <%%(diary-float t 0)> may depend
> on the time zone because the number of days in month may vary.
>
> How can we approach this? What could the format to specify the time zone
> for diary timestamps?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: New face: org-agenda-calendar-timerange

[Ihor Radchenko]

gaut...@gautierponsinet.xyz writes:

> Please find attached a patch containing two commits.
> The first one applies the face `org-agenda-calendar-event' to entries
> with a time range within a single day.
> The second one defines the new face `org-agenda-calendar-daterange'
> and applies it to entries with a time range on several days. (The
> second commit assumes the first one is already applied.)
>
> Since I am still learning elisp and this is my first contribution, it
> would be very nice if someone could double check the patch, and any
> feedback would be very welcome.

The patch looks good.
Now, just waiting for confirmation from Bastien about your copyright
status records.

> By the way, while trying to understand the code I have discovered the
> commit "cb19f5c94e3dc94da78169ec675d5bd07af34427" by Bastien which I
> don't really understand. The commit message says, talking about
> entries with a timerange:
> "* lisp/org-agenda.el (org-agenda-get-blocks): When both dates are of
> the same value, assume this is a time to display for each date in the
> range."
>
> It seems to me that this should be done by creating repeating tasks
> rather than an entry with a timerange, because suppose I want to put
> in my agenda an event spanning on several days including the precise
> hours at which it starts and ends but which starts and ends on the
> same hour, for example an entry with the following timerange:
>
> <2023-01-19 jeu. 12:00>--<2023-01-26 jeu. 12:00> .

AFAIU, the commit fixed a different scenario:
https://orgmode.org/list/byapr07mb573496c31816fe64b71e9d70a5...@byapr07mb5734.namprd07.prod.outlook.com

<2019-08-05 Mon 08:30-11:00>--<2019-08-09 Fri 08:30-11:00>

(which is, by the way, is not a proper time range, according to Org syntax)

Bastien, the commit asserts that when time parts of the timestamp range
are equal, treat them as repeating event, like <2019-08-05 Mon 08:30-11:00 +1d>
However, when there is an actual date range as in Gautier's example,
things are broken.

I am inclined to revert your commit because the original bug report was
trying to make Org use timestamp format, Org does not really recognize.

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

Re: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite

[Ihor Radchenko]

Edgar Lux  writes:

> I send the attached patch for your consideration. It allows to use biber for 
> bibliographies. I tested it with this:

Thanks, but could you please attach the patch?

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

Ihor Radchenko  writes:

> <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are 
> often ambiguous)
> <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>

One thing we all missed in the discussion is diary sexps.

In particular, "last Sunday of month" <%%(diary-float t 0)> may depend
on the time zone because the number of days in month may vary.

How can we approach this? What could the format to specify the time zone
for diary timestamps?

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

Tim Cross  writes:

> OK, I just give up.
>
> I don't understand why my very simple point seems so hard for anyone to
> grasp and why everyone seems so focused on the booking and scheduling of
> meetings with outhers. This was never in the scope of the very simple
> issue I want solved. 

FYI, I feel like you two and some other people in the thread are talking
about the same thing and simply misunderstand the terms used in
each-other's explanations.

> All that remains is to work out a good interface to make it easy to set
> the correct timestamp type (i.e. in local time or UTC) based on the
> requirements for that meeting (which is determined by whether the
> meeting has any participants in different time zones). How sophisticated
> we want ot make this is undecided. My simple sugestion wa that have the
> commands which insert timestamps use the universal argument - when
> called with the universal argument, set the timestamp using UTC and when
> it isn't, set it as it is now (or set it with the local TZ added, based
> on user preference).

Universal argument is already taken to insert time in addition to date.

I instead suggest allowing `org-read-date' provide completion interface
for TZ once user presses @ (for example) in the date prompt.
When the user press Z (for example), @UTC is inserted and the user can
simply add +XX or -XX as needed to complete the UTC offset.

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

Re: evil-mode ' / ' only searches visible

[Ihor Radchenko]

"Fraga, Eric"  writes:

> On Friday, 20 Jan 2023 at 11:07, Michael Maurer wrote:
>> Some more googling made me realize this is an ongoing issue with evil. Ah 
>> well.
>
> Interesting.  I have not experienced this.  In fact, I use the fact that
> I can search hidden sections to get around a very annoying bug in org
> mode where, every now and again, some sections cannot be
> revealed/expanded, a bug that I cannot reproduce at will unfortunately
> and hence I cannot create a minimal example to report this bug.

https://github.com/emacs-evil/evil/issues/1630


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

Re: [FEATURE REQUEST] Make org-copy-subtree and org-cut-subtree work on an active region

[Ihor Radchenko]

Philipp Kiefer  writes:

> When calling either org-copy-subtree or org-cut-subtree, check if there 
> is an active region that starts on a headline and contains at least one 
> more headline of the same level. If so, copy / cut all the subtrees 
> touched by the region. This saves the user having to count the subtrees 
> he / she wants to operate on in order to use the number as a prefix 
> argument for the command. This change  would make the process easier and 
> provide visual feedback.

+1

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

Re: evil-mode ' / ' only searches visible

[Fraga, Eric]

On Friday, 20 Jan 2023 at 11:07, Michael Maurer wrote:
> Some more googling made me realize this is an ongoing issue with evil. Ah 
> well.

Interesting.  I have not experienced this.  In fact, I use the fact that
I can search hidden sections to get around a very annoying bug in org
mode where, every now and again, some sections cannot be
revealed/expanded, a bug that I cannot reproduce at will unfortunately
and hence I cannot create a minimal example to report this bug.

I'm using evil version 20221229.1739 from (m)elpa.

-- 
: Eric S Fraga, with org release_9.6-201-gb58fba in Emacs 30.0.50

[FR] Add C-u and C-u C-u prefix arguments to org-paste-subtree (was: Make org-paste-subtree more predictable and useful)

[Ihor Radchenko]

Philipp Kiefer  writes:

> Further, you suggest I use C-S- to demote the subtree after 
> pasting it at the same level as the subtree at point. But what if I used 
> a numerical prefix argument to copy or cut several subtrees, maybe 5 or 
> 10? Not very convenient at all to demote them all by hand...
>
> I still hold that pasting headings / subtress either at the same level 
> or at the child level of the target heading is part of the bread and 
> butter of outline editing and should be as straightforward as possible. 
> I'm rather sure the current numeric prefixes of org-paste-subtree to 
> select a distinct level at which to paste are needed / used much less 
> frequently than a "paste at child level" prefix (maybe C-u C-u?) would 
> be if it was implemented.

Could you please provide concrete ideas what C-u/C-u C-u should do?
In particular, how it will interact with point located at heading,
at heading beginning, at empty heading, or inside a heading section.

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

[BUG] org-paste-subtree level when point is in the middle of a heading (was: Make org-paste-subtree more predictable and useful)

[Ihor Radchenko]

Philipp Kiefer  writes:

> 1. Org Mode-paste subtree low-level item swallowed: 
> https://imgur.com/a/CZ5lDaH . This relates to what I assume the passage 
> from the manual is trying to say should not happen:
>
> "makes sure that the subtree
> remains an independent subtree and does not swallow low level entries."

Confirmed. But what would be the expected behavior here? Inserting
before the heading at point? After?

Steps to reproduce:

1. Create a file

 1.1.1.1
 1.1.1.2
* 3
** 3.1
*** 3.1.1
 low-level item
*** 3.1.2
*** 3.1.3

2. Copy the first two headings
3. Move point as indicated
4. M-x org-paste-subtree

Observed: 1.* headings inserted after 3.1.1 and before "low-level-item",
thus breaking the sub-tree.

> 2. Org Mode-paste subtree on empty heading glitch: 
> https://imgur.com/a/AT5pDj6 . See my last message.

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

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

Re: evil-mode ' / ' only searches visible

[Michael Maurer]

On Fri, 20 Jan 2023 at 10:59, Michael Maurer  wrote:
>
> I don't know if it's something I pressed, or something that's happened
> after an update, but when I search in evil-mode using /, it now only
> searches headlines and everything visible. It no longer auto-expands.
> Isearch works just fine. Not sure where I should ask this, probably
> evil-mode mailing list, but maybe someone here has had a similar
> experience.

Some more googling made me realize this is an ongoing issue with evil. Ah well.

evil-mode ' / ' only searches visible

[Michael Maurer]

I don't know if it's something I pressed, or something that's happened
after an update, but when I search in evil-mode using /, it now only
searches headlines and everything visible. It no longer auto-expands.
Isearch works just fine. Not sure where I should ask this, probably
evil-mode mailing list, but maybe someone here has had a similar
experience.

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

[Fraga, Eric]

On Friday, 20 Jan 2023 at 16:39, Tim Cross wrote:
> My simple sugestion wa that have the commands which insert timestamps
> use the universal argument -when called with the universal argument,
> set the timestamp using UTC and when it isn't, set it as it is now (or
> set it with the local TZ added, based on user preference).

+1

I travel a lot; I have meetings arranged with others (online) where I
don't know where I will be.  I simply want to be able to have meeting
times set as UTC and let org tell me when it is depending on which time
zone I am in (as I always update the timezone on my laptop when I change
timezones).

Getting caught up with what happens at the transition to daylight
savings etc. is just a distraction, in my view.  Being able to specify
UTC timestamps and have them displayed in local time will be an
incredible step forward for time related management in org.  Does it
solve everything?  No.  But the current situation is a mess for timezone
related issues and this enhancement would be very welcome.

Thank you,
eric
-- 
: Eric S Fraga, with org release_9.6-201-gb58fba in Emacs 30.0.50

Re: [BUG] ob-shell doesn't evaluate last line on Windows (cmd/cmdproxy) [9.6.1 ( @ c:/Users/Osher/AppData/Roaming/.emacs.d/elpa/org-9.6.1/)]

[Ihor Radchenko]

Matt  writes:

> I agree, putting in the newline is simple and it would be easy enough to 
> create a separate path for Windows/cmd if it were a problem.
>
> I wonder if it might make sense to move where the trimming happens so that 
> the body passed into `org-babel-sh-evaluate' is ready to go and we could 
> handle the cmd case separately and earlier (by inserting the newline there)?

I think `org-babel--shell-command-on-region' will be more appropriate.
Because similar issues might appear when attempting to evaluate other
code blocks on Windows, where `shell-file-name' is set to cmdproxy.exe.

It will also be useful to leave a comment in the code explaining why we
need this newline.

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

Re: [BUG] ob-shell doesn't evaluate last line on Windows (cmd/cmdproxy) [9.6.1 ( @ c:/Users/Osher/AppData/Roaming/.emacs.d/elpa/org-9.6.1/)]

[Ihor Radchenko]

Osher Jacob  writes:

> On Wed, Jan 18, 2023 at 11:05 AM Ihor Radchenko  wrote:
>
>> If running cmdproxy.exe /c cmdproxy.exe /path/to/input is not wrong, the
>> problem is on Emacs side.
>
>
>> Osher, could you try putting your example script into a file and running
>> the command line directly? What will it output?
>>
>
> Unfortunately, it seems like cmdproxy.exe and cmd.exe cannot accept an
> input file as a command-line argument and execute it.
>
> In the case of running :
> cmdproxy.exe /c cmdproxy.exe /c C:/tmp/inp
>
> We get:
> cmdproxy.exe /c cmdproxy.exe /c C:/tmp/inp
> 'C:/tmp/inp' is not recognized as an internal or external command,
> operable program or batch file.

... which means that I did not dig deep enough.
Apparently, `process-file' is not passing the file to cmdproxy.exe.  It
calls `call-process', which reads file and passes its contents as input.

So, we don't need to do awkward manoeuvring with "&" and making the src
block contents into a one-liner. It's about understanding how
cmdproxy.exe handles stdin.

> I think it could be enough to make sure the input ends with a newline, in
> which case it could be done the way I proposed in the first message, that
> is changing:
> (t (org-babel-eval shell-file-name (org-trim body))
> to
> (t (org-babel-eval shell-file-name (concat (org-trim body) "\n"))
>
> I think as long as this change doesn't break the code in non-Windows
> operating systems (How would we go about verifying this?), it would be
> preferable due to its simplicity and minimality.

This looks like the way to go. For non-Windows systems we have some test
coverage.

I am wondering if we should add tests for powershell and cmdproxy.
Though only users with Windows will actually be able to run those.

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

Re: org-ref (including cite or not) and references with numbers exporting to HTML

[Ihor Radchenko]

Uwe Brauer  writes:

> 1. When I use org-ref-helm-insert-cite-link, either I obtain
>cite:tao06:_global
>or
>cite:Choquet-Bruhat_09
>but I cannot spot any difference  in my bibfile, save that the
>tao06 reference has a : in its key and indeed adding a : to the
>second  reference also insert a cite:
>any reason for this behavior?

CCing John.

> 2. Independent of this, when exporting to HTML
>In the text, the references are tao06:_global with a link
>how can I have numbers with links instead

You just need an appropriate bibliography style. See
https://github.com/jkitchin/org-ref/blob/master/org-ref.org#bibliography-links

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

Re: [BUG] org-open-line in tables broken with stripe-table-mode [9.6.1 (release_9.6.1 @ /usr/share/emacs/29.0.60/lisp/org/)]

[Ihor Radchenko]

Thomas Schneider  writes:

> Dear maintainers,
>
> I’ve run into an issue with Org tables in Emacs 29 since it updated Org
> to 9.6.  While I think it is a very similar issue to [0] and thus
> probably not Org’s problem, I nevertheless would like to at least record
> this for others.
>
> This issue only manifests together with stripe-table-mode from [1].
> With that active, C-o (i. e., #'org-open-line) fails with some “argument
> out of range” error.
>
> Steps to reproduce:
> ...

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

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

Re: org-persist-write slow when pp-use-max-width is t

[Ihor Radchenko]

Michael Eliachevitch  writes:

> I submitted a bug report where I attached the index file and a minimal 
> example file which benchmarks running pp on it, with which I could reproduce 
> my issue from emacs -Q:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58687
>
> Let's see what the emacs devs have to say about it.

Since the slowdown has been acknowledged as a known problem to be fixed
in future, I have pushed a workaround for now.

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

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

[Tim Cross]

"Thomas S. Dye"  writes:

> Aloha Max,
>
> Max Nikulin  writes:
>
>> On 20/01/2023 03:09, Tim Cross wrote:
>>> To reiterate for the last time, there are 2 clear and different use
>>> cases for timestamps associated with meetings.
>>> 1. A meeting timestamp for a meeting where all the participants are in
>>> the same time zone.
>> ...> 2. A meeting timestamp for a meeting where all the participants are in
>>> different time zones
>>
>> Tim, every scheduled meeting event is associated with some particular time 
>> zone,
>> often implicitly. So it is single use case.
>>
>> It is up to participants to negotiate which timezone is the primary one for 
>> each
>> event. It is matter of people communication, not technical issue.
>>
>> First Monday 15:00 is (almost) equally precise for
>> - Australia/Canberra having DST
>> - Australia/Darwin where currently no DST
>> - +1000 (the highest chance of improper use unfortunately)
>> - UTC
>>
>> Aside from time transition intervals, it is possible to take any of this 
>> variant
>> and to present time local for other participant across the globe.
>>
>> Storage timezone may differ from the current user preference which time zone
>> should be used to display timestamp or to export it.
>>
>> The problem arises when several participants believe that their timezones are
>> primary ones and they do not sync their schedules through a shared file or a 
>> DB
>> entry. An application can not solve this problem, but it might try to help to
>> identify it. Some efforts are necessary from user side. Timestamp should 
>> contain
>> list of timezones of other participants and cached local time. In such case 
>> an
>> application may warn users that local time values become inconsistent due to 
>> DST
>> transitions or due to update of time zone database. Unsure to what degree it
>> should be implemented in Org.
>>
>> So
>> - It is participants fault if a meeting is not associated with particular
>>  timezone
>> - Having a fair time handling library, it does not matter what time zone is 
>> used
>>  to schedule the meeting.
>
> Or, one can recognize that the meeting is an occurrence that requires 
> absolute time and a
> timestamp with UTC.  Each participant will resolve UTC to the local time 
> where they happen
> to be when the meeting takes place.  The user might toggle between UTC and 
> the local time
> translation using overlays, like pretty entities. This avoids the problem of 
> negotiating a
> timezone caused by forcing an occurrence to be represented as an event 
> relative to a
> fictitious space/time.
>

Exactly.

I am really confused by the constant reference to negotiating between
participants or finding a shared/agreed time zone etc. That is all
totally irrelevant in this use case as outlined. If we were talking
about booking meetings or communicating information about booked
meetings between participants or a different bit of software which
manages sceduling of meetings like one of those many web meeting booking
systems, then that would be a different matter. However, that isn't what
we are talking about. We are talking about org mode. All I am talking
about here is being able to identify two different types of meetings -
ones which need to have times adjusted as a result of daylight savings
time transitions and ones which don't and what mechanism org could use
to distinguish the two. It is that simple. Your occurrence v event
terminology provides two different names which may help label the two
different use cases.

So far, nobody has shown any reason why using UTC to distinguish the
case where the times need to be adjusted and local tz when they don't
won't work a a  mechanism that can be used to allow org to handle things
better than it does now. 

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

[Tim Cross]

Max Nikulin  writes:

> On 20/01/2023 12:39, Tim Cross wrote:
>> No, I disagree with that statement. That is old thinking based when
>> meetings meant face to face meetings. Only meeting which have a specific
>> location can have a time zone and even then, it isn't really the
>> meetings time zone, but instead the time zone of the participants at the
>> meeting.
>
> Tim, I am trying to say that any meeting either face to face or on-line may 
> be associated
> with arbitrary primary timezone. Even when all participants are in Sydney 
> they may decide
> to fix time in Darwin. It is strange, but it is possible. UTC is just one of 
> time zones
> that may be convenient for on-line meeting despite no participant really use 
> it. Local
> timezone is usually preferred for purely face to face meetings. You are not 
> realizing that
> is decision since it is not verbalized. Consider timezone as something 
> unrelated to
> location but just a set of rules how time offset in respect to epoch evolves 
> in time.
>

and what you are saying is helpful how? In what way does what you are
sayhing help address my use case?




> UI might offer you to choose time in your timezone and to select another 
> timezone for
> storage. For your convenience it still may be presented to you in your local 
> timezone even
> it is stored in UTC or some other one.

and I have said as much. So, how exactly is your contribution assisting
with the use case I've outlined?