org-todo-keywords and task sequence

[David Masterson]

I'm not sure I understand 'sequence' and 'type' in org-todo-keywords.
In particular, I can only think of the following simple sequence as
being possible in org-todo-keywords:

TODO -> IN-PROCESS -> DONE

If I want to add in (say) WAITING, the graph (represented as a table)
becomes:

i\o  | TODO | IN-P | WAIT | DONE
TODO |  N   |  Y   |  N   |  N
IN-P |  N   |  N   |  Y   |  Y
WAIT |  N   |  Y   |  N   |  N
DONE |  N   |  N   |  N   |  N

This table could be more complex with more Ys or more states in the task
processing (like HOLD).  I do not see what the proper sequence(s) to use
for representing this table in Org.

Hints?

-- 
David Masterson

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

[Daryl Manning]

I'd argue that setting a specific datestamp  and time for DST would mean
that you expected to meet at that specific time and date as per DST. If the
clocks changed you'd be out of luck (that's where I'd argue you'd use a
non-specified timezone for a meeting that re-occurs at 10:05 regardless of
say PDT or PST).

But if this was an issue with a recurring meeting, then when the clocks
changed someone would be out an hour because they had specifically booked
with DST in mind (note: this is more useful than you think - being in
non-DST countries and having scheduled meetings in DST based countries, a
lot of cal applications get this wrong when what I actually want is for
that DST scheduled meeting to now be reflected in my calendar on the fact
they've switched to ST in their time zone - so shifted an hour.).

But I feel this is something that would be for people who need to take
advantage of this. And, more often than not, is a recurring meeting issue
when DST/ST changes occur.

Daryl.


On Tue, Jan 17, 2023 at 3:54 AM Robert Horn  wrote:

>
> Ihor Radchenko  writes:
>
> > Robert Horn  writes:
> >
> >>> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
> >>>certain times a year or in future or in the past:
> >>>- DST transitions are not stable and change from year to year
> >>>  according to strange rules that may involve Julian dates or
> >>>  counting weekdays
> >>>- DST transition rules may change over time
> >>>- The new year day itself is not necessarily fixed (England
> >>>- Julian/Gregorian transitions happened at different times in
> >>>  different countries
> >>
> >> Note that as a result "time when it happened" has different rules than
> >> "future time when it is scheduled".  There are lots of other times that
> are
> >> scheduled as "future local time, subject to changing DST rules".  This
> >> is particularly tricky for repeating times for regularly scheduled
> events.
> >
> > Not really. Countries may change DST at any moment in future. Or decide
> > to switch calendars (consider countries near the day transition line).
> >
> > And "past local time, according to the DST rules in effect at the time"
> > is also an option that might be useful in certain scenarios.
> >
>
> The issue is clarity of the expected rules for the format.  If I
> schedule a meeting for 10:05 DST, but the rules change so that it is not
> DST at that location at that time in the future, what is the expected
> interpretation?  It could be:
>
>  a) the meeting should be at 10:05 ST, because the intent was to meet at
>  10AM in the then local time.
>
>  b) the meeting should be at 11:05 ST, because the time was chosen to
>  correspond to a particular sun angle.
>
> Getting the rules and explanation clear is the issue.  It's a mistake
> that a great many people make with scheduling meetings.  Those two
> behaviors need different encodings because they behave differently.
>
> --
> Robert Horn
> rjh...@alum.mit.edu
>

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

[Samuel Wales]

oh i was just saying what does modern org e.g. main have for ensuring
star structure integrity, if anything.  i have a git commit that has
something similar to:

  * one
  ** two

which seemed slightly relevant to the patch.

do i misunderstand?  i set region, then set todo kw, which loops me
manually through the region.  when the last todo kw is chosen, the
active region disappears.i personally would find it annoying if
transient mark mode stuck around.  fwiw.


On 1/16/23, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> 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.]
>
> Sorry, but I do not understand what you are referring to.
> Note that "maint", if it is a real branch name, is ancient and no longer
> used upstream.
>
>> 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.
>
> Yes, please. I am not sure about the patch 2/4 in particular that does
> not deactivate Transient mark mode when setting TODO state, tags,
> schedule, and deadlines. Do people need these? Maybe in some other
> commands? Maybe we can make it into a custom setting?
>
> --
> 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: [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/)]

[Matt]

  On Mon, 16 Jan 2023 16:40:27 -0500  Matt  wrote --- 
 > That is, go through the steps to reproduce and before executing the block, 
 > run `M-: (setq shell-command-switch "/k")'.

Whoa, just re-read this after stepping away and it sounds super demanding!  
Please excuse me, I've been trying to use active voice while writing 
documentation.

Let me try that again:

What happens if you go through the steps to reproduce and run `M-: (setq 
shell-command-switch "/k") before executing the block?

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

[Detlef Steuer]

Hi Ihor!

I tried to follow your advice to improve the patch accordingly.
New version attached.

Detlef

Am Sat, 14 Jan 2023 10:26:17 +
schrieb Ihor Radchenko :

> Detlef Steuer  writes:
> 
> > I now finally followed your advice for that patch.
> >
> > Attached a diff against a clean git checkout from two
> > hours ago.  
> 
> Thanks!
> Rather than diff, it would help to format a proper patch with author
> info and commit message (if you can).
> See https://orgmode.org/worg/org-contribute.html#first-patch and
> https://orgmode.org/worg/org-contribute.html#commit-messages
> 
> > (I send it privately, because I'm such a noob regarding elisp...)  
> 
> Do not be afraid to post on the mailing list in future.
> We do not shame anyone or attack in any other way. See
> https://www.gnu.org/philosophy/kind-communication.html
> 
> If there are problems with the code, we will help to improve them. If
> the problems are also discussed in public, other people will have a
> chance to learn as well.
> 
> Let me know if you still prefer private communication.
> 
> > 
> > mail: ste...@hsu-hh.de
> > commit e7574a8d429634112a2eb622759b4eef670ee44c
> > Author: Detlef Steuer 
> > Date:   Fri Jan 13 17:55:57 2023 +0100
> >
> > Add variable org-icalendar-ttl to ox-icalendar.el  
> 
> See https://orgmode.org/worg/org-contribute.html#commit-messages for
> our preferred commit message format.
> 
> > +(defcustom org-icalendar-ttl nil
> > +  "The time to life for the exported calendar.
> > +Subscribing clients to the exported ics file can derive the time
> > interval +to read the file again from the server. One example of
> > such a client is  
> 
> Elisp convention is to use double space (" ") between sentences in
> docstrings. 
> 
> > +the nextcloud calendar, which respects the setting of
> > +X-PUBLISHED-TTL, i.e. X-PUBLISHED-TTL:PT1H .
> > +See https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html
> > +for a complete description of possiblee values of this option. I.e.
> > +PT1H stands for 1 hour, PT0H27M34S for 0 hours, 27 minutes and 34
> > seconds."
> > +  :group 'org-export-icalendar
> > +  :type '(choice
> > +  (const :tag "no refresh" nil)
> > +  (const :tag "One day" "PT1D")
> > +  (const :tag "One week" "PT7D")
> > +  (string :tag "Explizit format")))  
> 
> Maybe just "Other"?
> 
> Also, please add
> 
> :package-version '(Org . "9.7")
> 
> to indicate when the new customization is introduced.
> 
> Finally, please document the new feature in etc/ORG-NEWS file.
> 
> > -(:icalendar-deadline-summary-prefix nil nil
> > org-icalendar-deadline-summary-prefix))
> > +(:icalendar-deadline-summary-prefix nil nil
> > org-icalendar-deadline-summary-prefix)
> > +(:icalendar-ttl nil nil org-icalendar-ttl))  
> 
> >:filters-alist
> >'((:filter-headline . org-icalendar-clear-blank-lines))
> >:menu-entry
> > @@ -872,24 +889,29 @@ as a communication channel."
> > (or (org-string-nw-p org-icalendar-timezone)
> > (format-time-string "%Z")) ;; Description.
> > (org-export-data (plist-get info :title) info)
> > +   ;; TTL
> > +   org-icalendar-ttl  
> 
> Please use (plist-get info :icalendar-ttl) here and later rather than
> the variable. It will then integrate better with Org's export system.
> 
> >  respectively, the name of the calendar, its owner, the timezone
> > -used, a short description and the other components included."
> > -  (concat (format "BEGIN:VCALENDAR
> > +used, a short description, the time-to-live resp. refresh period
> > and   
> 
> "time-to-life"? or maybe "time to life"?
> 



>From 7ad4b2df9609fd5893e71836aa2e172023fe2895 Mon Sep 17 00:00:00 2001
From: Detlef Steuer 
Date: Mon, 16 Jan 2023 23:27:33 +0100
Subject: [PATCH] lisp/ox-icalendar.el: Add customize option
 `org-icalendar-ttl'

* ox-icalendar.el: New option `org-icalendar-ttl' to add en entry
for the X-PUBLISHED-TTL option to ox-icalendar.  Default value is nil,
what means no such entry is exported.  If non nil the value must be
formated according to
https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html.
---
 etc/ORG-NEWS | 15 +++
 lisp/ox-icalendar.el | 45 
 2 files changed, 52 insertions(+), 8 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c5d9bdf6e..47d808df2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,21 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** New options
+*** New custom setting ~org-icalendar-ttl~ for the ~ox-icalendar~ backend
+
+The option ~org-icalendar-ttl~ allows to advise a subscriber to the
+exported ~.ics~ file to reload after the given time interval.
+
+This is useful i.e. if a calendar server subscribes to your exported
+file and that is updated regularly.
+
+See IETF RFC 5545, Section 3.3.6 Duration and
+https://en.wikipedia.org/wiki/ICalendar#Other_component_types for
+details.
+
+Default for 

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

[Robert Horn]

Tom Gillespie  writes:

>> Getting the rules and explanation clear is the issue.  It's a mistake
>> that a great many people make with scheduling meetings.  Those two
>> behaviors need different encodings because they behave differently.
>
> This is related to why I suggested splitting timezones and offsets into
> two separate categories. I think we have to assume that the written
> content of timestamps in an org file cannot/will-not be changed
> automatically.
>

The solution that we used in an operational scheduling system was to
invent a new family of time zones, the "Then Local Time There".  So you
would schedule something like "10:05 TLT (NorthAmerica/New York)".  This
was the most commonly used scheduled time.  It's what most people mean
when they schedule something.  Then the scheduled time encoding did not
change, but the displayed time could.  It was displayed in a format that
met the needs of the users.  When you're dealing with people in many
locations you need to separate the concept of scheduled time in the org
file from the concept of time display in a format useful to the user.

Those who wanted astronomical or other relationships would usually
specify UTC or TAI.  They might use a fixed offset for UTC.  People who
are into the demands of TAI (e.g., orbital mechanics) generally don't
want to deal with the offsets or other issues that come up with UTC, so
they wanted TAI.

-- 
Robert Horn
rjh...@alum.mit.edu

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

[Matt]

Thank you for your report, Osher!

Windows shells aren't currently supported by ob-shell, AFAIK.  I'm open to 
including them.  Unfortunately, I don't have a Windows machine to test against. 
 

  On Mon, 16 Jan 2023 11:27:52 -0500  Osher Jacob  wrote --- 
 > Expected behaviour:
 > On Windows, all lines of the babel shell block should be evaluated, with 
 > full output printed.

What's does `C-h v shell-file-name' say?  That should tell us what shell is 
being used.

 > #+begin_src shell
 >  echo 1
 >  echo 2
 >
 >
 > #+end_src
 >
 > #+RESULTS:
 > | Microsoft             | Windows   | [Version     | 10.0.19044.2364] |      
 >   |           |
 > | (c)                   | Microsoft | Corporation. | All              | 
 > rights | reserved. |
 > |                       |           |              |                  |      
 >   |           |
 > | c:\Users\osherj>echo  | 1         |              |                  |      
 >   |           |
 > | 1                     |           |              |                  |      
 >   |           |
 > |                       |           |              |                  |      
 >   |           |
 > | c:\Users\osherj>More? |           |              |                  |      
 >   |           |
 > 
 > The hacky way I solved it was to change this line:
 > (t (org-babel-eval shell-file-name (org-trim body))
 > to this:
 > (t (org-babel-eval shell-file-name (concat (org-trim body) "\n"))

I don't think org-trim is the issue.

Running the block (eventually) calls the default shell command, 
`org-babel--shell-command-on-region'.  This calls 
`org-babel--get-shell-file-name' on a temp file containing the block source 
using the "-c" flag.

I assume the shell used is cmdproxy.exe 
(https://git.savannah.gnu.org/cgit/emacs.git/tree/nt/cmdproxy.c).   It looks 
like this converts a "-c" to a "/c", among other things.

MSDN says for cmd.exe,

Parameter   Description
/c  Carries out the command specified by string and then stops.
/k  Carries out the command specified by string and continues.

So, the way I reason it, ob-shell tries calling cmdproxy.exe using /c which 
basically calls cmd.exe /c, the block temp file is executed, and the shell 
stops.

I see that `org-babel--shell-command-on-region' calls `process-file' using the 
`shell-command-switch'.  It doesn't appear to be set anywhere else in `ob-eval' 
(see ob-eval:112).

> Let me know if there's any other information you need, or if I can help in 
> any other way.

I wonder if changing `shell-command-switch' to "/k" would make a difference?  

That is, go through the steps to reproduce and before executing the block, run 
`M-: (setq shell-command-switch "/k")'.

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

[Tom Gillespie]

> Getting the rules and explanation clear is the issue.  It's a mistake
> that a great many people make with scheduling meetings.  Those two
> behaviors need different encodings because they behave differently.

This is related to why I suggested splitting timezones and offsets into
two separate categories. I think we have to assume that the written
content of timestamps in an org file cannot/will-not be changed
automatically.

Therefore if the timezone is specified then the numbers will never
change, but the actual time might if the timezone spec changes.

If an offset is used then it will not account for changes due
to DST, but it will always remain stable, shuffling a meeting an hour
one way or the other at some points in the year, which is usually
undesirable compared to say, shuffling a meeting 1 hour in one
direction for people who are not in the defining timezone for the
duration of the mismatch between DST changes in different regions.

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

[Robert Horn]

Ihor Radchenko  writes:

> Robert Horn  writes:
>
>>> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>>>certain times a year or in future or in the past:
>>>- DST transitions are not stable and change from year to year
>>>  according to strange rules that may involve Julian dates or
>>>  counting weekdays
>>>- DST transition rules may change over time
>>>- The new year day itself is not necessarily fixed (England
>>>- Julian/Gregorian transitions happened at different times in
>>>  different countries
>>
>> Note that as a result "time when it happened" has different rules than
>> "future time when it is scheduled".  There are lots of other times that are
>> scheduled as "future local time, subject to changing DST rules".  This
>> is particularly tricky for repeating times for regularly scheduled events.
>
> Not really. Countries may change DST at any moment in future. Or decide
> to switch calendars (consider countries near the day transition line).
>
> And "past local time, according to the DST rules in effect at the time"
> is also an option that might be useful in certain scenarios.
>

The issue is clarity of the expected rules for the format.  If I
schedule a meeting for 10:05 DST, but the rules change so that it is not
DST at that location at that time in the future, what is the expected
interpretation?  It could be:

 a) the meeting should be at 10:05 ST, because the intent was to meet at
 10AM in the then local time.
 
 b) the meeting should be at 11:05 ST, because the time was chosen to
 correspond to a particular sun angle.

Getting the rules and explanation clear is the issue.  It's a mistake
that a great many people make with scheduling meetings.  Those two
behaviors need different encodings because they behave differently.

-- 
Robert Horn
rjh...@alum.mit.edu

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

[Tom Gillespie]

> > As for years BC, <-0001-...> will be a breaking change. But I do not
> > think that we need to really worry about this. Not unless we actually
> > get feature request. What is the practical application?

Using org as a format for writing about history and being able to
reference dates in the past accurately and have the dates be
first class entities that can be parsed and checked etc.

The example in my head is a history professor who wants to
write about e.g. the collapse of the Roman republic and not
have to come up with their own time keeping system or force
any one who wants to work with referenced dates to do a bunch
of math to translate from a roman time system to a modern one.

> Given that the stated approach is to leverage off OS facilities in this
> area, it probably should also be noted that some OSs don't handle
> historical dates, especially BC ones, at all well. For example, some OS
> use a 32 bit number to represent the date+time and can really only
> handle dates between approx 1900 and 2038 (or around there - cannot
> remember specific range). So with respect to timestamps and time related
> calculations, we are limited by the capabilities of the least capable
> supported OS.

I'm mostly concerned about the syntactic features where org already
supports dates well outside the facilities of various operating systems.
I don't think that it is wise or practical for org-mode code to use
anything other than the os provided time keeping facilities right now,
but it is important to enable people who might want to do so. Org as
a format for documents has a wider range of use cases for dates and
times than Org as a life organizer and planner. At the same time those
wider use cases don't always need as much precision or ux considerations
because I don't think anyone using org right now is going to be early or
late to their meeting at [3023-01-16 Thu 12:00] (regardless of the timezone).
But org does tell me that it will be a Thursday! Best,
Tom

Re: [PATCH] ob-sql: Add support for Athena

[Tim Cross]

Ihor Radchenko  writes:

> Daniel Kraus  writes:
>
>> I'm using this patch since a few month that adds support
>> for AWS Athena.
>> The only thing that's maybe against adding it is that
>> `athenacli` (https://github.com/dbcli/athenacli) is not an
>> official AWS tool but just a Python script.
>>
>> What's the opinion on this?
>
> Is this something commonly used?
>
> I see two main issues with the idea:
> 1. I do not like the idea of adding all the possible CLI tools over
>there in ad-hoc manner. It would be cleaner to provide a
>customization to add various cli tools in a defcustom/defvar without
>manually changing the functions.
>
> 2. I feel like it will be hard to maintain such unpopular clients. If
>(1) is addressed + good automatic tests are implemented, things may
>be acceptable for inclusion though.
>
> In summary, I am not against the idea of including a new sql cli, but we
> should better provide a centralized API to do so and make sure that we
> have test coverage, making sure that things are not broken in future,
> when the original committer is gone and nobody else is left familiar
> with specific obscure SQL client.

I think you run a high risk of running into GNU policy issues wrt
licensing and free software support given this is a cleint for an AWS
only database. 

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

[Tim Cross]

Ihor Radchenko  writes:

> Tom Gillespie  writes:
>
>
>> 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 -.
>
> This is somewhat orthogonal to time zones.
>
> I am not sure if julian/gregorian is handled by system time libraries.
> It should, no?
>
> As for years BC, <-0001-...> will be a breaking change. But I do not
> think that we need to really worry about this. Not unless we actually
> get feature request. What is the practical application?

Given that the stated approach is to leverage off OS facilities in this
area, it probably should also be noted that some OSs don't handle
historical dates, especially BC ones, at all well. For example, some OS
use a 32 bit number to represent the date+time and can really only
handle dates between approx 1900 and 2038 (or around there - cannot
remember specific range). So with respect to timestamps and time related
calculations, we are limited by the capabilities of the least capable
supported OS.

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

[Tim Cross]

Daryl Manning  writes:

> I think timezone you're in should be declared globally, surely?  And then 
> defined in the timestamp?
>

Do you mean globally as in at the OS level or globally in org mode. If
the latter, I disagree. The OS has this information and there is no need
for org to repeat it (and possibly hav it wrong). I would go the other
direction and say that the TZ should only be defined in an org file i it
differs from the OS setting.

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

[Ihor Radchenko]

Robert Horn  writes:

>> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>>certain times a year or in future or in the past:
>>- DST transitions are not stable and change from year to year
>>  according to strange rules that may involve Julian dates or
>>  counting weekdays
>>- DST transition rules may change over time
>>- The new year day itself is not necessarily fixed (England
>>- Julian/Gregorian transitions happened at different times in
>>  different countries
>
> Note that as a result "time when it happened" has different rules than
> "future time when it is scheduled".  There are lots of other times that are
> scheduled as "future local time, subject to changing DST rules".  This
> is particularly tricky for repeating times for regularly scheduled events.

Not really. Countries may change DST at any moment in future. Or decide
to switch calendars (consider countries near the day transition line).

And "past local time, according to the DST rules in effect at the time"
is also an option that might be useful in certain scenarios.

>> 5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
>>astronomical Earth observations
>
> Fortunately, the most recent vote reached majority for eliminating leap
> seconds, hopefully within 8 years.

But we will have to keep supporting all the leap seconds that already
happened! So it does not really help all that much wrt timestamp
design.

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

[Robert Horn]

Ihor Radchenko  writes:

> https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
> To summarize:
>
> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>certain times a year or in future or in the past:
>- DST transitions are not stable and change from year to year
>  according to strange rules that may involve Julian dates or
>  counting weekdays
>- DST transition rules may change over time
>- The new year day itself is not necessarily fixed (England
>- Julian/Gregorian transitions happened at different times in
>  different countries
>

Note that as a result "time when it happened" has different rules than
"future time when it is scheduled".  There are lots of other times that are
scheduled as "future local time, subject to changing DST rules".  This
is particularly tricky for repeating times for regularly scheduled events.

> 5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
>astronomical Earth observations
>

Fortunately, the most recent vote reached majority for eliminating leap
seconds, hopefully within 8 years.

-- 
Robert Horn
rjh...@alum.mit.edu

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:

What we should not have is "make autoloads" failing without 
internet.


The attached patch should take care of that.
If the ls-remote errors, GITVERSION will be set to N/A as when it 
is generally unavailable. 

>From 4ce8b2dfc2cf2ca1507aa14be15f5212eb1de229 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 16 Jan 2023 14:00:41 -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 | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 4435daa9..9a62cbd4 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -14,7 +14,15 @@ 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
+  GITVERSION ?= N/A
   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

[Ihor Radchenko]

Daryl Manning  writes:

> I'd just be excited to have us run through the basic use cases and then see
> some more "tricky" ones. I imagine there are things we'd just have to
> say... too tricky for (eg. flight takes off in one TZ and range allows it
> to land in timezone... stuff like that might be tricky.).

https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
To summarize:

1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
   certain times a year or in future or in the past:
   - DST transitions are not stable and change from year to year
 according to strange rules that may involve Julian dates or
 counting weekdays
   - DST transition rules may change over time
   - The new year day itself is not necessarily fixed (England
   - Julian/Gregorian transitions happened at different times in
 different countries

2. There might be arbitrary time gaps due to time transition, including
   time overlaps with the same time of the day happening multiple time a
   day:
   - One hour back during DST transition (northern and southern
 hemispheres do the transitions in opposite directions)
   - Multiple days skipped (Samoa skips a whole day during DST
 transition)
   - Great Britain used 2 hours DST offset during WWII
   - Julian/Gregorian calendar transitions in the past

3. We cannot assume that the same geographical area has fixed time zone
   even at given point of time:
   - Palestinian/Israeli people follow different time zones in the
 contested territories

4. Great Britain had new year on March 25 until 16th century
   (March 24, 1000 -> (+1 day) March 25, 1001)

5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
   astronomical Earth observations

> So, is the TS syntax you've described accepted and canonical now with
> org-mode?

We are still discussing it.

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

>> 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.
>
> Yes, I do not mind to be able to represent 2023-10-29 Sun 2:01 before 
> and after transition in the Europe/Berlin timezone. Notice that Python 
> developers chose "fold" instead of "DST" for argument and field name:
> https://peps.python.org/pep-0495/
> PEP 495 – Local Time Disambiguation
>
> We should have this in mind, but I agree the priority is not highest one.

I think we could allow the "double zone" idea I mentioned in another
discussion branch:

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

Because 2:01 will happen twice that day, it will also be possible to specify 

<2023-10-29 Sun 2:01+0200@Europe/Berlin>

I think it is more intuitive compared to DST/no DST.
And we do not even need to parse this scenario specially:

The variants of the TZ spec will be:

HH:MM@[^\n>\]]+
HH:MMZ
HH:MM[+-−][0-9]{2}\([0-9]{2}\)?
(note that I don't list times like 12:00+02:00 because it will interfere
with time range syntax 08:00-09:00 is a time range, but might also be
08:00-0900 time zone)

then, "@Europe/Berlin" in 2:01+0200@Europe/Berlin will be simply ignored
and we will use the explicit UTC offset.

>> 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"))
>
> Pass list to `encode-time', not separate values in Emacs >= 27, since 
> this case DST is -1 (guess) it is not important, but generally the value 
> is ignored. It is a pitfall in API.

I see. This is not the only pitfall though.

I just discussed the same issue with Tecosaur, and he noted
that <2023-10-29 2:59@Europe/Berlin> is ambiguous because 2:59 occurs
twice during that day:

  2:59 -> 3:00 (DST -1 hour transition) -> 2:01 -> ... -> 2:59 -> 3:00 -> 3:01

The fact that `encode-time' chose 2:59 after the transition is
implementation detail.

To deal with such cases, we may provide org-lint checker that will
compare timestamps with t and nil DST parameter for `encode-time' and
warn if there is a difference.

(encode-time '(0 59 2 29 10 2023 nil -1 ":Europe/Berlin")) ; => (25917 44628)
(encode-time '(0 59 2 29 10 2023 nil t ":Europe/Berlin")) ; => (25917 44!628) 
(same)
(encode-time '(0 59 2 29 10 2023 nil nil ":Europe/Berlin")) ; => (25917 
48!!228) (different)

(encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin") ; => (25917 48!!228)
(encode-time 0 59 2 29 10 2023 nil t ":Europe/Berlin") ; same
(encode-time 0 59 2 29 10 2023 nil nil ":Europe/Berlin") ; same

So, there is a gotcha with `encode-time' API, and we must use the list
argument. (This gotcha is described in the docstring, but in rather
cryptic way)

 <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.
>
> Certainly events are usually associated with some area. I think, users 
> will prefer concise +0800 notation to full timezone ID like 
> Asia/Singapore and will get unexpected results sometimes. Manual should 
> stress that fixing time offset is not a bright idea for planning.

Sure. Having per-file/heading time zone settings will also help.

I don't think that people will mind _occasional_ timestamps having
Asia/Singapore. I'd personally prefer this kind of verbosity for
overseas remote events.

>> 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
>
> Some formats may be confusing for users, e.g. TZ=GMT+5 actually means 
> -0500 offset.

Let's just recommend +- and @location in the manual. And mention
briefly that TZ format is supported in addition.

We might also provide an optional linter for GMT, if necessary.

>> 2. ISO 8601 format 
>> https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
>
> I do not see IANA identifiers here. Moreover currently there is no API 
> to get list of IANA identifiers. On windows additional mapping may be 
> required:
> https://unicode-org.github.io/cldr-staging/charts/37/supplemental/zone_tzid.html
>
> I do not mind to fix timestamps in past by adding offsets like +0100. 
> For planning timezone identifiers should be strongly preferred unless 
> time is really fixed in respect to UTC.

Could you please elaborate? I 

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

[Osher Jacob]

*Expected behaviour:*On Windows, all lines of the babel shell block should
be evaluated, with full output printed.


*Actual behaviour:*All lines but the last are evaluated, the output ends
with 'More?'
instead of the last command's output.


*Steps to reproduce:*In Windows, start a clean Emacs instance (I used
"runemacs.exe -Q"), and evaluate the following blocks:

1) Enable shell language support
#+begin_src elisp
(org-babel-do-load-languages
   'org-babel-load-languages
   '(
 (shell . t)
 )
   )
#+end_src

#+RESULTS:


2) Evaluate this shell code block
#+begin_src shell
  echo 1
  echo 2


#+end_src

#+RESULTS:
| Microsoft | Windows   | [Version | 10.0.19044.2364] |
   |   |
| (c)   | Microsoft | Corporation. | All  |
rights | reserved. |
|   |   |  |  |
   |   |
| c:\Users\osherj>echo  | 1 |  |  |
   |   |
| 1 |   |  |  |
   |   |
|   |   |  |  |
   |   |
| c:\Users\osherj>More? |   |  |  |
   |   |



*Additional info:*After some debugging, it seems to be caused by a missing
newline character at the
end of the code block content.
I believe this is caused by the org-trim function which is called upon the
body of the block.
At the function:
org/ob-shell.el -> (defun org-babel-sh-evaluate ...)
The line:
(org-babel-eval shell-file-name (org-trim body))



*Suggested fix:*The hacky way I solved it was to change this line:
(t (org-babel-eval shell-file-name (org-trim body))
to this:
(t (org-babel-eval shell-file-name (concat (org-trim body) "\n"))
Also attached as a patch file


Let me know if there's any other information you need, or if I can help in
any other way.

Thanks!
Osher


Emacs  : GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-09-13
Package: Org mode version 9.6.1 ( @
c:/Users/Osher/AppData/Roaming/.emacs.d/elpa/org-9.6.1/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-format-latex-header
"\\documentclass{article}\n\\usepackage[usenames]{color}\n[PACKAGES]\n[DEFAULT-PACKAGES]\n\\pagestyle{empty}
% do not remove\n% The settings below are copied from
fullpage.sty\n\\setlength{\\textwidth}{\\paperwidth}\n\\addtolength{\\textwidth}{-3cm}\n\\setlength{\\oddsidemargin}{1.5cm}\n\\addtolength{\\oddsidemargin}{-2.54cm}\n\\setlength{\\evensidemargin}{\\oddsidemargin}\n\\setlength{\\textheight}{\\paperheight}\n\\addtolength{\\textheight}{-\\headheight}\n\\addtolength{\\textheight}{-\\headsep}\n\\addtolength{\\textheight}{-\\footskip}\n\\addtolength{\\textheight}{-3cm}\n\\setlength{\\topmargin}{1.5cm}\n\\addtolength{\\topmargin}{-2.54cm}"
 org-bibtex-headline-format-function '(closure (org-id-locations
org-agenda-search-view-always-boolean org-agenda-overriding-header t)
(entry)
  (cdr (assq :title entry)))
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-time-stamp-custom-formats '("<%m/%d/%y %a>" . "<%m/%d/%y %a %H:%M>")
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
 org-ascii-format-drawer-function '(closure (t) (_name contents _width)
contents)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-fold-show-all append local] 5]
(closure
 (org--rds reftex-docstruct-symbol org--single-lines-list-is-paragraph
visual-fill-column-width org-clock-history
  org-agenda-current-date org-with-time org-defdecode org-def
org-read-date-inactive org-ans2 org-ans1 org-columns-current-fmt-compiled
  org-clock-current-task org-clock-effort org-agenda-skip-function
org-agenda-skip-comment-trees org-agenda-archives-mode
  org-end-time-was-given org-time-was-given org-blocked-by-checkboxes
org-state org-agenda-headline-snapshot-before-repeat
  org-agenda-buffer-name org-agenda-start-on-weekday
org-agenda-buffer-tmp-name buffer-face-mode-face org-struct-menu
org-last-state
  org-clock-start-time texmathp-why remember-data-file
org-agenda-tags-todo-honor-ignore-options calc-embedded-open-mode
  calc-embedded-open-formula calc-embedded-close-formula
align-mode-rules-list org-export-registered-backends crm-separator
  org-id-overriding-file-name org-indent-indentation-per-level
org-element--timestamp-regexp org-element-cache-map-continue-from
  org-element-paragraph-separate org-agenda-buffer-name

org-cite-insert only searches on truncate author list

[Fraga, Eric]

Hello all,

Using org-cite-insert with vertico, matching is done only on the text
that the completion engine shows, text which has been truncated.  See
attached screenshot.  If I continue typing the second authors name,
Oluwamayowa, the second entry currently shown will disappear from the
options.  This is even more annoying when I am trying to search based
on, say, the third author of a paper whose name doesn't even appear in
this truncated table of completions.

I assume that, maybe, this is not org's fault but this kind of problem
only arises when using org-cite-insert so I was wondering if indeed
there is something I can tweak in org or oc- to get better completion
behaviour?  Or maybe something I can specify for vertico?

Note, with emacs -Q, the problem does not arise because the default
completion engine only allows completing based on the start of the entry
anyway.

Thank you,
eric

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

Tom Gillespie  writes:

>> I strongly disagree. I'd prefer to allow only internationally recognized
>> time zone format. Let's not make life harder for Org file parsers.
>
> So offsets and tz database names but no time zone abbreviations?
>
> That seems reasonable since there isn't a sane way to handle the
> timezone with dst vs abbreviation for an offset, so better to force
> only US/Central aka America/Chicago and then -06:00 and -05:00
> if users want CST/CDT to avoid any ambiguity?

No. Let's allow anything that can be understood by `encode-time' (or TZ
variable in other words). And also recommend using America/Chicago-like
and direct offsets in the manual. Abbreviations should be supported, but
not advised.

We may also later provide a linter to warn about ambiguous abbreviations
and times.

Basically, there is literally no way we avoid ambiguous timestamps, yet
keeping the required flexibility. No matter what we try. The best we can
do is support everything, recommend more reliable practices in the
manual, and warn about possible problems.

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

[Tom Gillespie]

> I strongly disagree. I'd prefer to allow only internationally recognized
> time zone format. Let's not make life harder for Org file parsers.

So offsets and tz database names but no time zone abbreviations?

That seems reasonable since there isn't a sane way to handle the
timezone with dst vs abbreviation for an offset, so better to force
only US/Central aka America/Chicago and then -06:00 and -05:00
if users want CST/CDT to avoid any ambiguity?

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

[Max Nikulin]

On 15/01/2023 20:41, Ihor Radchenko wrote:

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.


Yes, I do not mind to be able to represent 2023-10-29 Sun 2:01 before 
and after transition in the Europe/Berlin timezone. Notice that Python 
developers chose "fold" instead of "DST" for argument and field name:

https://peps.python.org/pep-0495/
PEP 495 – Local Time Disambiguation

We should have this in mind, but I agree the priority is not highest one.


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


Pass list to `encode-time', not separate values in Emacs >= 27, since 
this case DST is -1 (guess) it is not important, but generally the value 
is ignored. It is a pitfall in API.



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


You can inspect your local database
zdump -v Europe/Berlin


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


it is assumed that you should explicitly specify DST to get another 
branch (but at first you should determine somehow at which side DST 
should be applied):


(let* ((tz "Europe/Berlin")
   (t1 (encode-time `(0 1 3 29 10 2023 nil nil ,tz)))
   (t2 (encode-time `(0 59 2 29 10 2023 nil t ,tz
  (list
   (format-time-string "%F %T %z %Z" t1 tz)
   (format-time-string "%F %T %z %Z" t2 tz)
   (time-subtract t1 t2)))
("2023-10-29 03:01:00 +0100 CET" "2023-10-29 02:59:00 +0200 CEST" 3720)

Actually behavior is more funny, but I need more time to investigate it 
more close.


The real problem with libc is that TZ DB contains time transitions 
preserving DST value and DST argument of `encode-time' becomes useless:


Europe/Kyiv  Sat Jun 30 21:59:59 1990 UT = Sun Jul  1 01:59:59 1990 MSD 
isdst=1 gmtoff=14400
Europe/Kyiv  Sat Jun 30 22:00:00 1990 UT = Sun Jul  1 01:00:00 1990 EEST 
isdst=1 gmtoff=10800


zdump -v Africa/Juba
...
Africa/Juba  Sun Jan 31 20:59:59 2021 UT = Sun Jan 31 23:59:59 2021 EAT 
isdst=0 gmtoff=10800
Africa/Juba  Sun Jan 31 21:00:00 2021 UT = Sun Jan 31 23:00:00 2021 CAT 
isdst=0 gmtoff=7200



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


Certainly events are usually associated with some area. I think, users 
will prefer concise +0800 notation to full timezone ID like 
Asia/Singapore and will get unexpected results sometimes. Manual should 
stress that fixing time offset is not a bright idea for planning.



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


Some formats may be confusing for users, e.g. TZ=GMT+5 actually means 
-0500 offset.



2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators


I do not see IANA identifiers here. Moreover currently there is no API 
to get list of IANA identifiers. On windows additional mapping may be 
required:

https://unicode-org.github.io/cldr-staging/charts/37/supplemental/zone_tzid.html

I do not mind to fix timestamps in past by adding offsets like +0100. 
For planning timezone identifiers should be strongly preferred unless 
time is really fixed in respect to UTC.

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

[Daryl Manning]

I agree... TZ is optionally defined in a timestamp otherwise understood to
be "local".

I'd just be excited to have us run through the basic use cases and then see
some more "tricky" ones. I imagine there are things we'd just have to
say... too tricky for (eg. flight takes off in one TZ and range allows it
to land in timezone... stuff like that might be tricky.).

So, is the TS syntax you've described accepted and canonical now with
org-mode?

Daryl.



On Mon, Jan 16, 2023 at 6:39 PM Ihor Radchenko  wrote:

> Daryl Manning  writes:
>
> > I think timezone you're in should be declared globally, surely?  And then
> > defined in the timestamp?
>
> It is always defined globally on OS level. In POSIX-complaint OSes, it is
> TZ. Emacs obeys POSIX and time zone settings in other OSes. We don't
> need anything special for it.
>
> As for time zone in timestamps - it must be optional. Timestamps with
> time zone will use that time zone. Timestamps without time zone will use
> "default" time zone - be it OS time zone or whatever custom time zone
> setting we come up with in future. This "default" time zone approach is
> both useful for things like "brush teeth in 10pm in the evening" and
> also, more importantly, for backwards compatibility.
>
> > The use cases for per file or even per-heading tz specifying seems very
> low
> > imho (and introducing a lot more complexity.).
>
> Sure. As I mentioned in another message, not having these features should
> not stop us from merging whatever working time zone code we can come up
> with. They will be nice to have though.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Completely hide properties drawer in 9.6

[Ihor Radchenko]

Sterling Hooten  writes:

> In order to both have newly added properties automatically adopt the
> invisibility text-property the interior characters of the properties
> box needs to be sticky. But this conflicted with being able to type
> with the point before the hidden text. To satisfy both these
> requirements I applied =property-drawer-hidden-interior= as a folding
> spec which was sticky to all but the first two and last two characters
> of the property drawer. Then I applied =property-drawer-hidden-edges=
> to these two remaining chunks. In this way you can add in new
> properties and they'll be invisible, but typing at the edges appears
> visibly.
>
> Is there an alternative way of doing this without two separate folding
> specs? Maybe an additional key for ":interior-sticky" which is sticky
> on all characters sharing the same spec, but not sticky at the front
> and rear?

In theory, it is possible to add something like :interior-sticky.
However, it will be against how Emacs' sticky properties work.

An alternative approach you may use is hooking into font-lock.
Fontification will be re-applied upon editing, and you can hide only the
property drawer and nothing else. And you will not need to deal with
edge cases with inserting text.

> I couldn't quite figure out what the :fragile setting was.

:fragile makes sure that things are unfolded when a drawer is no longer
a drawer. Imagine:

:drawer:
Some text.
:end:


Then, you delete ":":

drawer:
Some text.
:end:

:fragile defines rules allowing to auto-unfold the drawers (or anything
else) as needed.

We would not want the drawer above to remain folded as you would not be
able to use  to unfold any more - tab will no longer see a "drawer"
at point.

> #+begin_src emacs-lisp
>   (defun org-fold-show-property-drawer ( arg)
>   "Unhide property drawer in heading at point.
> With non-nil ARG show the entire subtree."
>   (org-with-wide-buffer 
>(org-back-to-heading)
>(let* ((beg (point))
>   (end (if arg (org-element-property :end (org-element-at-point))
>  (org-next-visible-heading 1)
>  (1+ (point)
>  (org-fold-region beg end nil
>   'property-drawer-hidden-edges)
>  (org-fold-region beg end nil
>   'property-drawer-hidden-interior
>
>   (defun org-fold-hide-property-drawer ( arg)
>   "Completely hide the property drawer in heading at point.
>   With non-nil ARG hide the entire subtree."
>   (org-with-wide-buffer 
>(org-back-to-heading)
>(let* ((beg (point))
>   (end (if arg (org-element-property :end (org-element-at-point))
>  (org-next-visible-heading 1)
>  (1+ (point)
>  (org-fold--hide-property-drawers beg end
> #+end_src
>
> Is there a faster or better way of getting the boundary points for a
> heading without the subheadings? I've wanted this feature in a few
> other situations but don't know a clean way to fetch it. I suppose you
> could also just have that the regex stop searching for the beginning
> of the property box after 2 lines past the heading, since the
> properties box needs to be in the first two lines.

You can use the following at or inside a drawer:
 (org-element-lineage (org-element-at-point) '(section))

:begin and :end will contain current section boundaries. "section" is
all the text under the parent heading, up to the first child. The AST is:

(heading
 (section
   [(planning)]
   [(property-drawer)]
   [(paragraph1)]
   ...)
 (subheading)
 ...)

> The default =org-end-of-meta-data= will go past any blank lines and
> only stop at a non-empty line.  I would prefer for hitting  on
> a headline to act as if the planning line and properties box were
> immutable, and just pass directly after them. For this I wrote a
> version that will stop after the logbooks or property drawer.
>
> Is there a better way to do this? I tried using the match-data but it
> seemed unreliable (if there's nothing but blank lines after the meta
> data it matches on the next heading).

You can just use `org-element-at-point'. At planning, `org-element-type'
will be 'planning. At property drawer - 'property-drawer. At drawer -
'drawer. :end property will include blank lines, but you can also check
:post-blank that will contain the number of blank lines at the end.
Check out `org--at-headline-data-p' implementation.

> I am also experiencing a weird (overlay?) problem with i-search. After
> implementing when I search for things it will make all of the windows
> greyed out, and then only show the matching characters.  I can see the
> text again if I =mark-whole-buffer=. But I don't know what's causing
> this.

No idea here. Need more information.

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

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

[Ihor Radchenko]

Tom Gillespie  writes:

> Small bugfix for emacs 25 compat. Best!
> (format "babel-stable-%d" (random 1000))
> -   (temporary-file-directory
> +   temporary-file-directory)))

Thanks!

Note that Emacs 25 is no longer officially supported. AFAIR, some Org
components are already failing in Emacs 25.

However, the patch itself is reasonable because the return value of
`temporary-file-directory' depends on `default-directory' - something we
don't want to do for `defvar' statement.

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

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

[Ihor Radchenko]

No Wayman  writes:

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

As discussed, this is a reasonable addition.

However, I am concerned about the following scenario:
1. Shallow clone is created
2. make autoloads is issues when system is disconnected from internet

May it be properly handled? We can put N/A at the version tag as well in
such case.

What we should not have is "make autoloads" failing without internet.

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

Tom Gillespie  writes:

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

I strongly disagree. I'd prefer to allow only internationally recognized
time zone format. Let's not make life harder for Org file parsers.

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

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

Sure. That's what I proposed by

<2023-01-16 Mon 12:00@Australia/Melbourne>

But we may as well allow UTC offsets there

<2023-01-16 Mon 12:00+0200>

whichever users prefer to use in their use case.

Both the variants may be preferred depending on the purpose. The first
is good when we need to conform to local time, including all the
possible changes in TZ rules. The second is good when we, say, want to
schedule something "102000 _actual_ hours from the beginning of the
experiment; don't care about what government may decide about
winter/summer time in future"

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

Sure. We should get it for free because both GMT+8 and Asia/Singapore
are the valid TZ values. Both supported by Emacs' `encode-time'.

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

Jean Louis  writes:

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

We already transform timestamps into internal time representation via
`encode-time' (for the most part, at least). It is an equivalent to
transforming to UTC. The internal representation can be later
transformed back via `decode-time' with appropriate target ZONE
parameter.

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

Jean Louis  writes:

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

This is not a problem. We already have `org-time-stamp-custom-formats'
that will use current time zone.

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

Jean Louis  writes:

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

I think you misunderstood my statement here.

"People don't bother" does not make life easier for us.
I was replying to an assertion that it is common for meeting times to be
expressed in non-ambiguous UTC+XX offsets. I gave an example that it is
not the case - some meetings are, in fact, scheduled in local, tricky
time zones. We have to account for those.

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

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

Well. I'd say that repeat count has been requested enough to strongly
consider adding it. I guess an alternative could be setting a heading
property to limit the number of repetitions.

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

Tom Gillespie  writes:

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

The existing code uses `org-ts-regexp-both' and `org-ts-regexp0' for
analysis. + `org-element-timestamp-parser' that is using Elisp logic.

And these requirements are pretty lax. The actual parsing just requires

-MM-DD [day] XX:XX[-XX:XX][optional string containing anything but "\n]>"]

with repeater and warning located anywhere after the required
date/day/time components.

date, repeater and warning periods do not have to contain " " afterwards
and thus can have arbitrary misc data. This feature is used by
org-habit, attaching things like /3w after the repeater.

We have a lot of forward-compatibility in timestamps :)

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

This is somewhat orthogonal to time zones.

I am not sure if julian/gregorian is handled by system time libraries.
It should, no?

As for years BC, <-0001-...> will be a breaking change. But I do not
think that we need to really worry about this. Not unless we actually
get feature request. What is the practical application?

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

Re: [PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

Ihor Radchenko  writes:

> Daniel Kraus  writes:
>
>> I'm using this patch since a few month that adds support
>> for AWS Athena.
>> The only thing that's maybe against adding it is that
>> `athenacli` (https://github.com/dbcli/athenacli) is not an
>> official AWS tool but just a Python script.
>>
>> What's the opinion on this?
>
> Is this something commonly used?

Athena itself is very widely used. But everyone uses either the
AWS Webinterface or connect with JDBC (DBeaver/Datagrip etc) to it.
The Python tool doesn't seem so popular (only 200 GitHub stars),
that's also my main reason for not adding it.


> I see two main issues with the idea:
> 1. I do not like the idea of adding all the possible CLI tools over
>there in ad-hoc manner. It would be cleaner to provide a
>customization to add various cli tools in a defcustom/defvar without
>manually changing the functions.
>
> 2. I feel like it will be hard to maintain such unpopular clients. If
>(1) is addressed + good automatic tests are implemented, things may
>be acceptable for inclusion though.
>
> In summary, I am not against the idea of including a new sql cli, but we
> should better provide a centralized API to do so and make sure that we
> have test coverage, making sure that things are not broken in future,
> when the original committer is gone and nobody else is left familiar
> with specific obscure SQL client.

Completely agree.
If I look in `org-babel-execute:sql` `command`
( https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-sql.el#n256 
)
I think it would make sense to somehow make all those commands
customizeable and let users add their own commands.
But that's obviously a bit more work. I'll see if I find time for it
in the coming months.

Thanks,
  Daniel

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

[Ihor Radchenko]

Daryl Manning  writes:

> I think timezone you're in should be declared globally, surely?  And then
> defined in the timestamp?

It is always defined globally on OS level. In POSIX-complaint OSes, it is
TZ. Emacs obeys POSIX and time zone settings in other OSes. We don't
need anything special for it.

As for time zone in timestamps - it must be optional. Timestamps with
time zone will use that time zone. Timestamps without time zone will use
"default" time zone - be it OS time zone or whatever custom time zone
setting we come up with in future. This "default" time zone approach is
both useful for things like "brush teeth in 10pm in the evening" and
also, more importantly, for backwards compatibility.

> The use cases for per file or even per-heading tz specifying seems very low
> imho (and introducing a lot more complexity.).

Sure. As I mentioned in another message, not having these features should
not stop us from merging whatever working time zone code we can come up
with. They will be nice to have though.

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

[Daryl Manning]

I think timezone you're in should be declared globally, surely?  And then
defined in the timestamp?

The use cases for per file or even per-heading tz specifying seems very low
imho (and introducing a lot more complexity.).

Daryl.

On Mon, Jan 16, 2023 at 6:20 PM Ihor Radchenko  wrote:

> Jean Louis  writes:
>
> > * 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.
>
> Sorry, I think you misunderstood what I am saying here.
>
> I was referring to a need for Org code to retrieve some kind of
> timezone-specific data other than converting timestamps with time zone to
> and back from the internal time representation.
>
> In another message, I also mentioned an idea of specifying time zone
> globally or per file. Other suggestion was per-heading specification. In
> addition to time zone being specified directly inside the timestamp.
>
> --
> 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]

Jean Louis  writes:

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

We need nothing to use current time zone. And we already do it.

System clock knows the current time zone. Emacs has an ability to
determine current time zone. See `current-time-zone'. This works
automatically (and already) because we use `encode-time'.

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

Indeed. This is the whole point of this discussion. Note my replies with
updated ideas. So far, I do not see a need to get some extra information
about time zones though. If you can, please correct me in the relevant
branches of this thread.

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

Jean Louis  writes:

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

Sorry, I think you misunderstood what I am saying here.

I was referring to a need for Org code to retrieve some kind of
timezone-specific data other than converting timestamps with time zone to
and back from the internal time representation.

In another message, I also mentioned an idea of specifying time zone
globally or per file. Other suggestion was per-heading specification. In
addition to time zone being specified directly inside the timestamp.

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

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

[Ihor Radchenko]

Samuel Wales  writes:

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

Sorry, but I do not understand what you are referring to.
Note that "maint", if it is a real branch name, is ancient and no longer
used upstream.

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

Yes, please. I am not sure about the patch 2/4 in particular that does
not deactivate Transient mark mode when setting TODO state, tags,
schedule, and deadlines. Do people need these? Maybe in some other
commands? Maybe we can make it into a custom setting?

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

Re: [PATCH] ob-sql: Add support for Athena

[Ihor Radchenko]

Daniel Kraus  writes:

> I'm using this patch since a few month that adds support
> for AWS Athena.
> The only thing that's maybe against adding it is that
> `athenacli` (https://github.com/dbcli/athenacli) is not an
> official AWS tool but just a Python script.
>
> What's the opinion on this?

Is this something commonly used?

I see two main issues with the idea:
1. I do not like the idea of adding all the possible CLI tools over
   there in ad-hoc manner. It would be cleaner to provide a
   customization to add various cli tools in a defcustom/defvar without
   manually changing the functions.

2. I feel like it will be hard to maintain such unpopular clients. If
   (1) is addressed + good automatic tests are implemented, things may
   be acceptable for inclusion though.

In summary, I am not against the idea of including a new sql cli, but we
should better provide a centralized API to do so and make sure that we
have test coverage, making sure that things are not broken in future,
when the original committer is gone and nobody else is left familiar
with specific obscure SQL client.

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

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

[Ihor Radchenko]

Daniel Kraus  writes:

>> I am looking at the docstring of `sql-connection-alist':
>>
>> An alist of connection parameters for interacting with a SQL product.
>>  Each element of the alist is as follows:
>>
>>(CONNECTION \(SQL-VARIABLE VALUE) ...)
>>
>>  Where CONNECTION is a case-insensitive string identifying the
>>  connection, ...
>>
>> So, your "setq" example is incorrect: must use "testdb" instead of
>> `testdb' symbol.
>
> I'm not sure why but I also have the connection as a symbol in my
> `sql-connection-alist`.
> Looking in `sql.el` `(sql-connect)`, they also use
> `assoc-string` to receive the connection:
> https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/sql.el?h=ac2a6fc83fac6390892b068a830ebe0f22364e05#n4398
>
> So I think that change is good and supports both formats
> (same as `sql-connect`).

Agree. In fact, I missed "insensitive" part of the docstring, reading it
opposite.

Andreas, feel free to send a proper patch with commit message. But
please do not decrease the copyright years :)

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

[PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

Hi,

I'm using this patch since a few month that adds support
for AWS Athena.
The only thing that's maybe against adding it is that
`athenacli` (https://github.com/dbcli/athenacli) is not an
official AWS tool but just a Python script.

What's the opinion on this?

Cheers,
  Daniel
>From ddace051205d20b24c047962ca9d1335bdd90284 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Mon, 16 Jan 2023 11:35:02 +0100
Subject: [PATCH] lisp/ob-sql.el: Add support for Athena

* lisp/ob-sql.el (org-babel-execute:sql): Add support for Athena
---
 lisp/ob-sql.el | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 39a4573a5..640ecb2c0 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -53,14 +53,15 @@
 ;; - rowname-names
 ;;
 ;; Engines supported:
-;; - mysql
+;; - athena
 ;; - dbi
 ;; - mssql
-;; - sqsh
-;; - postgresql (postgres)
+;; - mysql
 ;; - oracle
-;; - vertica
+;; - postgresql (postgres)
 ;; - saphana
+;; - sqsh
+;; - vertica
 ;;
 ;; TODO:
 ;;
@@ -254,6 +255,11 @@ This function is called by `org-babel-execute-src-block'."
(org-babel-temp-file "sql-out-")))
 	 (header-delim "")
  (command (cl-case (intern engine)
+(athena (format "athenacli %s -e %s %s > %s"
+			(or cmdline "")
+			(org-babel-process-file-name in-file)
+database
+			(org-babel-process-file-name out-file)))
 (dbi (format "dbish --batch %s < %s | sed '%s' > %s"
  (or cmdline "")
  (org-babel-process-file-name in-file)
@@ -352,7 +358,7 @@ SET COLSEP '|'
 	(progn (insert-file-contents-literally out-file) (buffer-string)))
   (with-temp-buffer
 	(cond
-	 ((memq (intern engine) '(dbi mysql postgresql postgres saphana sqsh vertica))
+	 ((memq (intern engine) '(athena dbi mysql postgresql postgres saphana sqsh vertica))
 	  ;; Add header row delimiter after column-names header in first line
 	  (cond
 	   (colnames-p
@@ -377,7 +383,7 @@ SET COLSEP '|'
 	  (goto-char (point-max))
 	  (forward-char -1))
 	(write-file out-file
-	(org-table-import out-file (if (string= engine "sqsh") '(4) '(16)))
+	(org-table-import out-file (if (memq (intern engine) '(athena sqsh)) '(4) '(16)))
 	(org-babel-reassemble-table
 	 (mapcar (lambda (x)
 		   (if (string= (car x) header-delim)
-- 
2.39.0

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

[Daniel Kraus]

Ihor Radchenko  writes:

> Andreas Gerler  writes:

>> (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 am looking at the docstring of `sql-connection-alist':
>
> An alist of connection parameters for interacting with a SQL product.
>  Each element of the alist is as follows:
>
>(CONNECTION \(SQL-VARIABLE VALUE) ...)
>
>  Where CONNECTION is a case-insensitive string identifying the
>  connection, ...
>
> So, your "setq" example is incorrect: must use "testdb" instead of
> `testdb' symbol.

I'm not sure why but I also have the connection as a symbol in my
`sql-connection-alist`.
Looking in `sql.el` `(sql-connect)`, they also use
`assoc-string` to receive the connection:
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/sql.el?h=ac2a6fc83fac6390892b068a830ebe0f22364e05#n4398

So I think that change is good and supports both formats
(same as `sql-connect`).

Cheers,
  Daniel

Re: [BUG] org-agenda-span treats 7 differently [9.4.6 (9.4.6-g3ba46c @ ~/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Eppo Math  writes:
>
>>> I think we can update the docstrings for `org-agenda-start-day' and
>>> `org-agenda-start-on-weekday' explaining that the latter takes
>>> precedence when agenda span is a week or more.
>
> See the attached patch.

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

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

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

[Ihor Radchenko]

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
>
> (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 am looking at the docstring of `sql-connection-alist':

An alist of connection parameters for interacting with a SQL product.
 Each element of the alist is as follows:
 
   (CONNECTION \(SQL-VARIABLE VALUE) ...)
 
 Where CONNECTION is a case-insensitive string identifying the
 connection, ...

So, your "setq" example is incorrect: must use "testdb" instead of
`testdb' symbol.

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

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

[Daniel Kraus]

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

[ANN] orgtbl-fit

[tbanelwebmin]

Hi the List!

The new orgtbl-fit package has just been released on Melpa. It
does regression fitting on Org Mode tables.

Example. We suspect that `obs' depends on `x' and `y'.

|  x | y |  obs |
|+---+--|
| 32 | 7 | 38.3 |
| 18 | 3 | 11.4 |
| 43 | 9 | 47.3 |
| 11 | 2 |  8.9 |
| 35 | 8 | 45.1 |

Let us put the cursor on the `obs' column, and type
M-x orgtbl-fit

Two columns are added
- predicted obs column
- difference between obs and predicted

|  x | y |  obs | Best Fit | Fit Diff |
|+---+--+--+--|
| 32 | 7 | 38.3 | 38.2 | -0.1 |
| 18 | 3 | 11.4 | 11.6 |  0.2 |
| 43 | 9 | 47.3 | 47.2 | -0.1 |
| 11 | 2 |  8.9 |  8.7 | -0.2 |
| 35 | 8 | 45.1 | 45.3 |  0.2 |
#+TBLFM: $4=-0.289267886829 - 1.06613976706*$1 + 10.3668885192*$2; 
%.1f::$5=$4-$3; %.1f


So we discovered that
obs = -0.29 -1.07*x +10.37*y

Behind the scene, the calcFunc-fit function from Emacs-Calc is called.

Install through Melpa:
M-x package-install orgtbl-fit

Source and documentation here:
https://github.com/tbanel/orgtblfit/blob/master/README.org

Have fun
Thierry

Re: [BUG] ox-html does not export captions of source blocks without language

[Ihor Radchenko]

Ihor Radchenko  writes:

> Here is the plan to resolve this issue:
>
> 1. We update the manual allowing src blocks to have empty language spec

See the attached patch.

> 2. We update org-syntax document

It turned out to be unnecessary.  org-syntax document already declares
block DATA to be optional:

#+begin_name [DATA]
#+end_name

See https://orgmode.org/worg/org-syntax.html#Blocks

Code blocks fall within a subset of this rule.

> 3. We change org-html-src-block to add caption to src blocks without lang

See the attached patch.

>From a7c5aa3431cc1946aa7f8055c39e18e5afc4cef4 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Mon, 16 Jan 2023 12:59:47 +0300
Subject: [PATCH 1/2] org-manual.org: Clarify that LANGUAGE may be omitted in
 code blocks

* doc/org-manual.org (Structure of Code Blocks):
(Editing Source Code): Clarify that  is optional.  Link to
possible consequences of  being omitted.
---
 doc/org-manual.org | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 4466af8e4..c241e170f 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17313,9 +17313,16 @@ ** Structure of Code Blocks
 - == ::
 
   #+cindex: language, in code blocks
-  Mandatory.  It is the identifier of the source code language in the
+  Optional.  It is the identifier of the source code language in the
   block.  See [[*Languages]], for identifiers of supported languages.
 
+  When == identifier is omitted, the block also cannot
+  have == and ==.
+
+  Language identifier is also used to fontify code blocks in Org
+  buffers, when ~org-src-fontify-natively~ is set to non-~nil~.  See
+  [[*Editing Source Code]].
+
 - == ::
 
   #+cindex: switches, in code blocks
@@ -18951,6 +18958,9 @@ ** Editing Source Code
   header line, then the edit buffer uses that major mode.  Use this
   variable to arbitrarily map language identifiers to major modes.
 
+  When language identifier is omitted in the src block, Org mode's
+  behavior is undefined.
+
 - ~org-src-window-setup~ ::
 
   #+vindex: org-src-window-setup
@@ -18976,10 +18986,13 @@ ** Editing Source Code
 
 #+vindex: org-src-fontify-natively
 #+vindex: org-src-block-faces
-Set ~org-src-fontify-natively~ to non-~nil~ to turn on native code
-fontification in the /Org/ buffer.  Fontification of code blocks can
-give visual separation of text and code on the display page.  To
-further customize the appearance of ~org-block~ for specific
+Fontification of code blocks can give visual separation of text and
+code on the display page.  Set ~org-src-fontify-natively~ to non-~nil~
+to turn on native code fontification in the /Org/ buffer.  The
+fontification follows the major mode used to edit the code block (see
+~org-src-lang-modes~ above).
+
+To further customize the appearance of ~org-block~ for specific
 languages, customize ~org-src-block-faces~.  The following example
 shades the background of regular blocks, and colors source blocks only
 for Python and Emacs Lisp languages.
-- 
2.39.0

>From 8c832d374066bbba430dc21a6b4fb098361c44a9 Mon Sep 17 00:00:00 2001
Message-Id: <8c832d374066bbba430dc21a6b4fb098361c44a9.1673863743.git.yanta...@posteo.net>
In-Reply-To: 
References: 
From: Ihor Radchenko 
Date: Mon, 16 Jan 2023 13:04:01 +0300
Subject: [PATCH 2/2] org-html-src-block: Treat code blocks without LANG
 equally
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ox-html.el (org-html-src-block): Do not treat src blocks
without LANG as example blocks.  Instead, export them using "nil"
language.  This way, such src blocks will get captions, unlike example
blocks.

The new behavior is consistent with ox-latex and ox-ascii.

Reported-by: Johan Bolmsjö 
Link: https://orgmode.org/list/87zgb90win.fsf@localhost
---
 lisp/ox-html.el | 52 -
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 7b79c57d4..5e58ccba3 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -3616,32 +3616,32 @@ (defun org-html-src-block (src-block _contents info)
 	   (klipsify  (and  (plist-get info :html-klipsify-src)
 (member lang '("javascript" "js"
 	   "ruby" "scheme" "clojure" "php" "html")
-  (if (not lang) (format "\n%s" label code)
-	(format "\n%s%s\n"
-		;; Build caption.
-		(let ((caption (org-export-get-caption src-block)))
-		  (if (not caption) ""
-		(let ((listing-number
-			   (format
-			"%s "
-			(format
-			 (org-html--translate "Listing %d:" info)
-			 (org-export-get-ordinal
-			  src-block info nil #'org-html--has-caption-p)
-		  (format "%s%s"
-			  listing-number
-			  (org-trim (org-export-data caption info))
-		;; Contents.
-		(if klipsify
-		(format "%s"
-			lang
-			label
-			(if (string= lang "html")
-" data-editor-type=\"html\""
-			  

Re: [Bug] isearch errors when org-fold-core-style is 'overlays

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> Part of the problem is some undocumented behaviour of isearch.
>> I will need to consult Emacs devs before fixing.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60399

There seems to be no easy way to fix isearch yet retaining the ability
to obey `org-fold-show-context-detail'.  I have disabled
`org-fold-show-context-detail' when revealing folds temporarily +
`org-fold-core-style' = 'overlays.

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

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