Re: Bar drawing in display engine, master indent-spacing variable

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

>> >>> I propose the addition of indent-bars to ELPA.
>> >>>
>> >>> https://github.com/jdtsmith/indent-bars
> ...

May I know the reason why Org mailing list is in CC? Or was it by accident?

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

Re: Bar drawing in display engine, master indent-spacing variable

[Pedro Andres Aranda Gutierrez]

Pure accident! Sorry... need another coffee ;-)
/PA

On Mon, 16 Sept 2024 at 09:10, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> >> >>> I propose the addition of indent-bars to ELPA.
> >> >>>
> >> >>> https://github.com/jdtsmith/indent-bars
> > ...
>
> May I know the reason why Org mailing list is in CC? Or was it by accident?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: support range durations

[Guido Stevens]

On 9/15/24 14:02, Ihor Radchenko wrote:

Guido Stevens  writes:


As per https://orgmode.org/manual/Column-attributes.html I'm using range
durations to express effort estimations. Those get summarized nicely in
column views, using the {est+} summarizer. But when I access an agenda
view that encounters a task that has such a range duration directly set,
the agenda chokes with an error message:

org-duration-to-minutes: Invalid duration format: "1d-2d"


May you please provide more details on how to trigger the error?


Sure. I'm providing the Doom keybindings for the actions I'm taking.

1. Abbreviated snippet from my Doom config:

(use-package! org
  :defer t
  (setq!
   org-global-properties
   `(("Effort_ALL" . "0 0.5d 0.5d-1d 1d 1d-2d"

2. Set estimate "1d-2d" on a task (C-c C-x e)

3. Open an agenda view that contains that task (C-c n a t)

org-duration-to-minutes: Invalid duration format: "1d-2d"





...
* lisp/org-duration.el (org-duration-to-minutes): Do not choke on
low-high range durations (e.g. "2d-5d") when rendering an agenda. Calculate the 
average
of the range instead.

Range durations are valid when estimating effort, and supported
elsewhere via the {est+} summarizer.


Org mode durations have no notion of ranges. It is completely
org-colview thing. So, modifying `org-duration-to-minutes' is not
appropriate. We need to fix org-colview, not org-duration.



The reproduction above does not involve org-colview.

The disagreement apparently is, that org-colview says range durations 
are supported for effort estimates, and even has code handling them via 
the {est+} summarizer, when they are not supported in org-duration.


https://github.com/emacs-mirror/emacs/blob/f27553c30a772a0103d2e6762e4d7f588f302e4b/lisp/org/org-colview.el#L1419

I get your point about not accepting this patch. None of the other 
functions or docstrings in org-duration mentions or handles ranges, fair 
enough.


I'm puzzled though, because I did not come up with this feature. It's 
genuinely useful and it appears to have worked in the past.

https://lists.gnu.org/archive/html/emacs-orgmode/2014-12/msg00435.html

Maybe sorting agenda views by effort was not active at that stage: I 
suspect that is what is triggering the error. Which points to a 
potential solution (and also to a potential speed optimization): even 
when I am not sorting on effort at all, this error is thrown, so why is 
org-duration-to-minutes even called at all in the agenda view? Is there 
a way to disable that?


I.e. even when I simplify my sorting strategy to:

   org-agenda-sorting-strategy
   '((agenda priority-down)
 (todo priority-down)
 (tags priority down)
 (search priority-down))
   )

org-duration-to-minutes is called and throws an error. Why is it even 
called?


I'm out of my depth in Lisp and don't know how to properly step that 
call flow.



--
Guido Stevens|   Cosent   | https://cosent.nl

s o c i a l   k n o w l e d g e   t e c h n o l o g y

Re: [PATCH] Add repeat-map for navigation commands

[Visuwesh]

[ஞாயிறு செப்டம்பர் 15, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> BTW, should we add C-n and friends to org-navigation-repeat-map or just
>> have n, p, etc.?  I personally find C-n in the repeat-map disruptive
>> since I usually want to move the cursor after jumping to a specific
>> heading, in which case C-n not being next-line is annoying.
>
> +1 for less disruptive :)

Please find attached.  I tried my best to write the manual entry but it
still reads awkward.

>From c66ff969e23d0d29746941383e5afa54d0e9e060 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 9 Sep 2024 19:46:47 +0530
Subject: [PATCH] Add repeat-mode keymap for navigation commands

* lisp/org-keys.el (org-up-heading): Add new alias for
outline-up-heading.
(org-mode-map): Remap outline-up-heading to the new alias.
(org-navigation-repeat-map, org-link-navigation-repeat-map)
(org-block-navigation-repeat-map): Add new repeat-maps to make
navigation easier.
* doc/org-manual.org (Repeating commands): Document the new feature in the manual.
* etc/ORG-NEWS (Some navigation commands can now be repeated): Announce it.
---
 doc/org-manual.org | 14 ++
 etc/ORG-NEWS   |  6 ++
 lisp/org-keys.el   | 34 ++
 3 files changed, 54 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 9365c66b1..254764c31 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21657,6 +21657,20 @@ of ~org-yank-dnd-method~.  Image files pasted this way also respect
 the value of ~org-yank-image-save-method~ when the action to perform
 is =attach=.
 
+** Repeating commands
+:PROPERTIES:
+:DESCRIPTION: Repeating navigation commands
+:END:
+
+#+cindex: repeat-mode, org-mode
+#+cindex: repeating navigation commands
+When ~repeat-mode~ is turned on, headline motion commands, link and
+block navigation commands by only pressing a single key.  For example,
+when navigation to the next headline using {{{kbd(C-c C-n)}}}, a
+repeat map is activated that lets you quickly execute headline motion
+commands.  When a key not in the map is pressed, it exits ~repeat-mode~
+and the command corresponding to the key is executed.
+
 * Hacking
 :PROPERTIES:
 :DESCRIPTION: How to hack your way around.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 392788055..8acc2f6b4 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -77,6 +77,12 @@ You can now create links to =shortdoc= documentation groups for Emacs
 Lisp functions (see =M-x shortdoc-display-group=).  Requires Emacs 28
 or newer.
 
+*** Some navigation commands can now be repeated
+
+When ~repeat-mode~ is turned on, certain navigation can be repeated.
+These include the headline navigation commands, ~org-next-link~ and
+~org-previous-link~, and ~org-next-block~ and ~org-previous-block~.
+
 ** New and changed options
 
 # Chanes deadling with changing default values of customizations,
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 1daedaae8..f6de753af 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -232,6 +232,7 @@ (declare-function org-up-element "org" ())
 (declare-function org-update-statistics-cookies "org" (all))
 (declare-function org-yank "org" (&optional arg))
 (declare-function orgtbl-ascii-plot "org-table" (&optional ask))
+(declare-function outline-up-heading "outline" (arg &optional invisible-ok))
 
 
 
@@ -409,6 +410,8 @@ (define-key org-mode-map [remap outline-next-visible-heading]
 (define-key org-mode-map [remap outline-previous-visible-heading]
   #'org-previous-visible-heading)
 (define-key org-mode-map [remap outline-show-children] #'org-fold-show-children)
+(defalias 'org-up-heading #'outline-up-heading)
+(define-key org-mode-map [remap outline-up-heading] #'org-up-heading)
 
  Make `C-c C-x' a prefix key
 (org-defkey org-mode-map (kbd "C-c C-x") (make-sparse-keymap))
@@ -462,6 +465,37 @@ (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontrolleft)
 (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontrolup)
 (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontroldown)
 
+;;; Repeat-mode map.
+(defvar org-navigation-repeat-map (make-sparse-keymap)
+  "Repeat keymap for navigation commands.")
+(org-defkey org-navigation-repeat-map (kbd "b") #'org-backward-heading-same-level)
+(org-defkey org-navigation-repeat-map (kbd "f") #'org-forward-heading-same-level)
+(org-defkey org-navigation-repeat-map (kbd "n") #'org-next-visible-heading)
+(org-defkey org-navigation-repeat-map (kbd "p") #'org-previous-visible-heading)
+(org-defkey org-navigation-repeat-map (kbd "u") #'org-up-heading)
+(map-keymap
+ (lambda (_key cmd)
+   (put cmd 'repeat-map 'org-navigation-repeat-map))
+ org-navigation-repeat-map)
+
+(defvar org-link-navigation-repeat-map (make-sparse-keymap)
+  "Repeat keymap for link navigation commands.")
+(org-defkey org-link-navigation-repeat-map (kbd "n") #'org-next-link)
+(org-defkey org-link-navigation-repeat-map (kbd "p") #'org-previous-link)
+(map-keymap
+ (lambda (_ cmd)
+   (put cmd 'repeat-map 'org-link-navigation-

Org-Capture Window Behavior

[Amol Vaidya]

Hello,

I use a widescreen monitor, and when I initiate an org-capture the frame
transforms mid-capture as follows:

+---+---+---+---+ +---+---+
| 1 | 2 | 3 | 4 | --> |   1   |capture|
+---+---+---+---+ +---+---+

I find this behavior disruptive, as I generally want to condense
information from multiple sources into a single note. Ideally I'd like all
my existing windows to remain open for reference. I would prefer for the
capture buffer to respect my display-buffer settings.

>From what I’ve gathered, this behavior seems to be caused by the
delete-other-windows function in org-capture-place-template. While there
are workarounds developed by users, I’d appreciate the developers’ thoughts
on potentially changing the default behavior of how org-capture manages
windows.

Thank you for your time and consideration.

Best regards,
Amol Vaidya

Re: [BUG] export blocks no longer fontifying [9.7.10 (release_9.7.10 @ /Users/ben/Scripts/emacs/lisp/org/)]

[Benjamin McMillan]

Ok, I am happy to submit a patch. It would be my first, so I will have to
find time to make the commit properly.

On Wed, Sep 11, 2024 at 1:59 AM Ihor Radchenko  wrote:

> Benjamin McMillan  writes:
>
> > At some point in the last few months, org mode stopped fontifying my
> > latex export blocks. However, an older version of emacs on my computer
> > still does fontify.
> > (The difference is seen even opening emacs with the -q flag)
> > It seems that there was a change to the function
> > org-fontify-meta-lines-and-blocks-1 in org.el, specifically at the
> > conditional that checks org-src-fontify-natively.
> > As the comment there explains, the intention is to only fontify src
> > blocks, but I don't see any option exposed to enable fontififcation of
> > export blocks, which is a fairly crucial feature to my workflow.
> >
> > I think fontification of export blocks should follow that of src blocks,
> > or a separate option should be made. (Or, I may be missing some already
> > existing solution!)
> >
> > For what it is worth, I can get the desired behavior by modifying the
> > code mentioned above to include "export", as in the following:
> > (and org-src-fontify-natively
> > ;; Technically, according to
> > ;; `org-src-fontify-natively' docstring, we should
> > ;; only fontify src blocks.  However, it is common
> > ;; to use undocumented fontification of example
> > ;; blocks with undocumented language specifier.
> > ;; Keep this undocumented feature for user
> > ;; convenience.
> > (member block-type '("src" "example" "export")))
>
> Since we already do it for example blocks, I see not why we should not
> for export blocks.
>
> Would you be interested to submit a patch with your modification?
> See https://orgmode.org/worg/org-contribute.html#first-patch
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [FR] yank media: allow customization of absolute path a filter for type candidates

[Visuwesh]

[திங்கள் செப்டம்பர் 16, 2024] pinmacs wrote:

> Hi,
>
> So I was using org-download, and I would like to replace it entirely 
> with yank-media
>
> and what I am missisng is:
>
> 1. do a variable for selecting absolute path: to be able to have a file 
> link that works with absolute path; and the reason is that being 
> relative, this, does not combine good when you move your latex export 
> somewhere else (in my case, I usually move it to /tmp/, and from there I 
> decide when I want to save something persistently), hence it fails, and 
> I got tired on fixing the links, in fact, the absolute path sometimes is 
> smaller than the relative one 
> =file:/tmp/clipboard-20240916T013308.png]]= vs 
> =[[file:../../../tmp/clipboard-20240916T011913.png]]=

This can be done in the org side.  I guess adding another defcustom
would be the way to go? I don't see how it is possible to make
org-yank-image-save-method accept another option.

> 2. do a variable that allow a list that would filter and reduce the type 
> candidates of yank-media. In org-download, everything was png so I was 
> not having the "Several types available, choose one" with 7 options. But 
> then is like, oh, maybe I would like to be able to switch between png 
> (synthetic image), jpg (natural image)... anyway, I hope you see 
> customizing this is interesting for the users.

This needs to be done in the Emacs side.  The querying is done in
yank-media and nothing much can be done from org-mode.

Re: [PATCH] ox-texinfo: Support links in headings

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Ihor Radchenko  writes:
>
>> I tried to run make test and your new test fails: [...]
>
> Yup, `4829bacff', which you merged in the meantime, broke the test, as
> it changed how `@ref's are generated.
>
>> May you please fix this and also rebase the patch onto the latest main?
>
> Rebased.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6443c83bd1

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

Re: [BUG] org-refile-get-targets wrong-type-argument [9.6.15 (release_9.6.15 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Serghei Iakovlev  writes:

> I encountered an issue with `org-mode' in my Emacs configuration
> related to periodic clearing of the refile cache during idle time.  I
> am using the following code snippet, which runs during idle time to
> clear the cache of refile targets:
>
> --8<---cut here---start->8---
> (run-with-idle-timer 600 t (lambda ()
>  (require 'org-refile)
>  (org-refile-cache-clear)
>  (org-refile-get-targets)))
> --8<---cut here---end--->8---
> ...
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   looking-at(nil)
>   org-refile-get-targets()
> ...
>  org-refile-targets '((nil :maxlevel . 4) (my-org-opened-buffer-files 
> :maxlevel . 4)
>   (org-agenda-files :maxlevel . 4))

You are running `org-refile-get-targets' using idle timer.
It means that it may be called in any buffer.

At the same time, you have (nil :maxlevel .4) in your
`org-refile-targets', instructing Org mode to examine current buffer for
refile targets.

Since you are on 9.6.15, Org mode should actually barf if
`org-refile-targets' is called in non-Org buffer.
So, I am a bit puzzled why you are running into errors that seemingly
originate from deeper into `org-refile-get-targets' logic (there is a
single `looking-at' call in `org-refile-get-targets' and it is after
checking major mode).

My only guess is that some of your Org buffers is not properly
initialized somehow. Maybe the timer is triggering in the middle of Org
mode loading or something?

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

Re: [BUG] org-mode failed to open top-level header properly when using the TAB key [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Robbie Morrison  writes:

> Many thanks for your follow up.
>
> I have set `org-element-use-cache' to nil as you suggest. Seems fine.
>
> My org-mode is just via the package management system on Ubuntu, so 
> somewhat behind I guess.

Ok.  I am thus closing this bug report, as there is nothing more we can
do on Org side.

Canceled.

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

Re: BUG: after an org-capture to an inbox entry, statistics-cookies are not updated on certain circumstances

[Ihor Radchenko]

pinmacs  writes:

>> I was able to reproduce using stable version of Org mode.
>> However, the bug is not present on the development version (main
>> branch).
> ..
> Here and there [1] I would like to close this thread saying that on a 
> particular stable version this is fixed, let me know when this change is 
> incorporated in whatever version and I will test it and then I will 
> consider this closed from my side

That will be Org 9.8. Not soon.

Not Org 9.7 because we only put critical and trivial fixes into bugfix
(9.7.X) releases.

To test things, you can install development version from git repository
or from ELPA devel (see 
https://protesilaos.com/codelog/2022-05-13-emacs-elpa-devel/)

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

Re: [BUG] What about excluding .dir-locals.el from GNU ELPA tarball?

[Ihor Radchenko]

Morgan Willcock  writes:

> I believe it is up to the file to opt-out of compilation.

That's true, but .dir-locals is a special file. So, I expected Emacs to
treat it specially during compilation as well. To not break old,
no-longer-maintained packages, if nothing.

> If the file is created with add-dir-local-variable there is a boiler
> plate header inserted which opts out:
>
>   ;;; Directory Local Variables-*- no-byte-compile: t -*-
>   ;;; For more information see (info "(emacs) Directory Variables")
> ...
> ...  The solution would be to add
> the missing header to the .dir-locals.el file.

I do not see any downside of adding this to .dir-locals.el file.
Would you mind submitting a patch?

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

Re: Org-Capture Window Behavior

[Ihor Radchenko]

Amol Vaidya  writes:

> I use a widescreen monitor, and when I initiate an org-capture the frame
> transforms mid-capture as follows:
>
> +---+---+---+---+ +---+---+
> | 1 | 2 | 3 | 4 | --> |   1   |capture|
> +---+---+---+---+ +---+---+
>
> I find this behavior disruptive, as I generally want to condense
> information from multiple sources into a single note. Ideally I'd like all
> my existing windows to remain open for reference. I would prefer for the
> capture buffer to respect my display-buffer settings.

Have you tried the latest version of Org mode (Org 9.7)?
Org 9.7 should honor `display-buffer-alist'.

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

Re: Org-Capture Window Behavior

[Amol Vaidya]

Thank you for your response.

I have tested this with a clean installation of Emacs, where I
installed Org mode 9.7, but I am still encountering the same behavior.

For reference, I’ve attached a screen recording that demonstrates the
issue. I’ve also verified that Org 9.7 is being used, as shown in the
Messages buffer in the left-most window.
https://0x0.st/X3bi.mp4

Please let me know if you need any further information or if there are
any settings I may have overlooked.

Regards,
Amol Vaidya


On Mon, Sep 16, 2024 at 2:22 PM Ihor Radchenko  wrote:
>
> Amol Vaidya  writes:
>
> > I use a widescreen monitor, and when I initiate an org-capture the frame
> > transforms mid-capture as follows:
> >
> > +---+---+---+---+ +---+---+
> > | 1 | 2 | 3 | 4 | --> |   1   |capture|
> > +---+---+---+---+ +---+---+
> >
> > I find this behavior disruptive, as I generally want to condense
> > information from multiple sources into a single note. Ideally I'd like all
> > my existing windows to remain open for reference. I would prefer for the
> > capture buffer to respect my display-buffer settings.
>
> Have you tried the latest version of Org mode (Org 9.7)?
> Org 9.7 should honor `display-buffer-alist'.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [PATCH] Texinfo: Check for math support without warnings and quietly (was: Improve Texinfo math checking)

[Rudolf Adamkovič]

A friendly ping. :)

Rudolf Adamkovič  writes:

> Oops, I found a bug in the patch.
>
> Now fixed.
>
> Rudy
> From a99cb0ecafb6a0a1d4ef841dd20be5fa2da43cff Mon Sep 17 00:00:00 2001
> From: Rudolf Adamkovic 
> Date: Tue, 27 Aug 2024 11:10:56 +0200
> Subject: [PATCH] ox-texinfo: Check for math support without warnings and
>  quietly
>
> * lisp/ox-texinfo.el (org-texinfo-supports-math-p): Two
> improvements: (1) Fix the incorrect `.info' extension used for the
> temporary `.texi' file.  This removes the warning "makeinfo: warning:
> input file testXXX.info; did you mean testXXX.texi?" (2) Suppress
> output when compiling the "Is math supported?" test file.  This is to
> avoid user confusion, as the user cares about their Texinfo file, not
> implementation details.  This removes the message "Processing Texinfo
> file /var/.../testXXX.info...".
> ---
>  lisp/ox-texinfo.el | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
> index 6adee9fca..b11808ed5 100644
> --- a/lisp/ox-texinfo.el
> +++ b/lisp/ox-texinfo.el
> @@ -2037,9 +2037,12 @@ Once computed, the results remain cached."
>(unless (boundp 'org-texinfo-supports-math--cache)
>  (setq org-texinfo-supports-math--cache
>(let ((math-example "1 + 1 = 2"))
> -(let* ((input-file (make-temp-file "test" nil ".info"))
> +(let* ((input-file (make-temp-file "test" nil ".texi"))
> +   (output-file
> +(file-name-with-extension
> + (file-name-sans-extension input-file) "info"))
> (input-content (string-join
> -   (list (format "@setfilename %s" 
> input-file)
> +   (list (format "@setfilename %s" 
> output-file)
>   "@node Top"
>   "@displaymath"
>   math-example
> @@ -2050,7 +2053,8 @@ Once computed, the results remain cached."
>(when-let* ((output-file
> ;; If compilation fails, consider math to
> ;; be not supported.
> -   (ignore-errors (org-texinfo-compile input-file)))
> +   (ignore-errors (let ((inhibit-message t))
> +(org-texinfo-compile 
> input-file
>(output-content (with-temp-buffer
>  (insert-file-contents 
> output-file)
>  (buffer-string
> -- 
> 2.39.3 (Apple Git-146)
>
> -- 
> "I love deadlines.  I love the whooshing noise they make as they go by."
> --- Douglas Adams, The Salmon of Doubt, 2002
>
> Rudolf Adamkovič  [he/him]
> http://adamkovic.org

-- 
"One can begin to reason only when a clear picture has been formed in
the imagination."
--- Walter Warwick Sawyer, Mathematician's Delight, 1943

Rudolf Adamkovič  [he/him]
http://adamkovic.org

please, report on current status of orgmode timestamps with timezone

[pinmacs]

Hi,

From #11 OrgMeetup content [1] I see that a date with timestamp and 
timezone is used:


    <2024-09-11 Wed 19:00-21:00 @+03,Europe/Istanbul>

With orgmode version 9.7.10:

1. If I try to to =C-c C-c= minibuffer says: "Not at a timestamp"; well, 
at least, does not try to remove the timezone part

2. Cannot change anything on it with =S-= nor =S-=
3. If I click the timestamp, minibuffer says: "This should not happen"
4. In the org agenda, the event appears in date 2024-09-11 and in my 
local time 19:00-21:00, so, no timezone calculation is done


I saw that there were some discussions about this, but nothing 
consolidated in the documentation, maybe, at some point, it should be 
here [2]


Is this something is going to arrive on 9.8 ? Is this something that 
only works in development version?


Cheers,
pinmacs

[1] https://list.orgmode.org/87o750dja7.fsf@localhost/T/#u
[2] https://orgmode.org/manual/Timestamps.html