Re: Re: [ANN] Looking for new maintainers for ox-latex.el (LaTeX export library)

[Pedro Andres Aranda Gutierrez]

Hi,

> I am happy to help with both ox-latex and ox-beamer with two caveats: my
> time at certain times of the year is very limited (as you know as there
> is still an outstanding item for ox-beamer that I have not been able to
> address since October or longer) and my elisp-fu is sometimes not up to
> scratch.  However, I do have useful LaTeX & beamer expertise which can
> be useful.

I'm certainly time-limited, but use ox-latex and ox-beamer profusely and in
parallel with "pure" LaTEX - whatever you might understand by "pure" ;-)
will be close enough - I could also help when my lectures permit and yes, I
also follow the list

/PA
-- 
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: org-clock idle time in pgtk Emacs

[Julien Cubizolles]

Ihor Radchenko  writes:


>> +(defcustom org-clock-pgtkidle-program-name
>> +  (if (executable-find "jc-idle-time")
>> +  "jc-idle-time")
>> +  "Name of the program which prints idle time in milliseconds.
>
> May I know where "jc-idle-time" is coming from? Is it a built-in command
> on wayland?

Sorry, I forgot to mention. It's a custom python program, working both
in X11 and wayland. I didn't find a built-in command.

--8<---cut here---start->8---
#!/usr/bin/env python3

from idle_time import IdleMonitor

monitor = IdleMonitor.get_monitor()
print(f"{1000*monitor.get_idle_time():.0f}")
--8<---cut here---end--->8---

-- 
Julien Cubizolles

Re: Dates in headlines

[Ihor Radchenko]

Max Nikulin  writes:

> May it happen that in some old Org version timestamps at the end of 
> headings were removed due by code intended to handle statistics cookie 
> [1/10]?

I do not see how.

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

Re: [BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings

[gerard . vermeulen]

On 02.02.2023 09:26, Ihor Radchenko wrote:

gerard.vermeu...@posteo.net writes:


May you please convert the diff into a patch with changelog entry and
commit message? See
https://orgmode.org/worg/org-contribute.html#org045e318


patch attached.


Thanks!


1. I have assigned my copyright for Emacs stuff to the FSF


Bastien, may you please confirm?

2. My initial version of the patch was against bugfix and now I have 
set

:package-version to "9.6"


Correct.
You can also remove :version tag while we are at it. It is redundant
when :package-version is provided (we are slowly getting rid of the
:version tags across Org).

 according to the instructions on the org-contribute page. I do 
not

know if this is acceptable (it
 feels a bit like breaking the rules), but I am happy to redo the
patch for main.


bugfix is fine. This is a trivial patch.


I have attached an amended patch with the :version tag removed.


0001-org.el-Sync-org-babel-load-languages-with-Babel-file.patch
Description: Binary data

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Bruno Barbier]

Hi Max,

Max Nikulin  writes:

> The author suggests to install from github assets instead of official 
> add-on catalog for some reason. Perhaps it is just survived since times 
> when cb_thunderlink was not published yet.

My new version instructs to install the add-on from Thunderbird, with no
OS installation. It's simpler and safer.

>
> My idea was to push '("\\`mid:" . custom/browse-url-mid) to 
> `browse-url-handlers' having (untested)
>
> (defun custom/browse-url-mid (url  _ignored)
>(browse-url
> (replace-regexp-in-string "\\`mid:" "thunderlink:/message-id=" url)))
>
> I am unsure concerning double slash after protocol since host name 
> expected after double slash. At least KDE may try to resolve hostname 
> and to distort URI. I hope, Message-ID never contains characters that 
> may require percent encoding when used in query parameter value.
>
> `browse-url-xdg-open' had a lot of revisions before current 
> `call-process' settled inside. It is the reason why I will prefer to 
> avoid explicit calls to `start-process' (alternatives known to me are 
> even worse) and to delegate as much as possible to `browse-url'.

My new version instructs to use standard "mid:" by just running Thunderbird.


> Since you suggest thunderlink: links instead of built-in mid:

I didn't realize that Thunderbird allows to open "mid:". I've simplified
the method.

I'm now using =cb_thunderlink= just to answer the following question, that
currently is on the wiki page:

  you need to copy the value of the Message-ID
  header, it should be possible with some add-on.

i.e. cb_thunderlink allows to build a full org link (link + description).

As it's still not clear to me how to configure browse-url, I'm still relying
on start-process.

See a new version of the patch.

Bruno

>From 89cef9d7acd85828ddfbb1375fac1e805bd03cea Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Tue, 31 Jan 2023 20:33:22 +0100
Subject: [PATCH] org-faq: links with thunderbird: Add cb_thunderlink

---
 org-faq.org | 36 
 1 file changed, 36 insertions(+)

diff --git a/org-faq.org b/org-faq.org
index 0410d368..4c2d0c8f 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -2051,6 +2051,42 @@ so the following recipe is obsolete:
 Notice that this link uses Message-ID to reference a particular
 message as well.
 
+*** Using the =cb_thunderlink= add-on
+The add-on =cb_thunderlink= for Thunderbird allows to generate direct
+links from emails inside Thunderbird. You can then teach org to repon
+these links.
+
+  1. In Thunderbird, install the =cb_thunderlink= add-on.
+
+  2. In the options page of the =cb_thunderlink= add-on, add a new link
+ type, name it =org= with the following value:
+
+  #+begin_example
+  [[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]
+  #+end_example
+
+  3. In your emacs init file, add the following lines:
+  #+begin_src elisp
+  (defvar thunderbird-app nil
+"The absolute path to your thunderbird application.")
+
+  (defun thunderbird-message-with-id (message-id)
+"Open the given email. MESSAGE-ID is the message id."
+(start-process "thunderbird" " *thunderbird*"
+   thunderbird-app
+   (concat "mid:" message-id)))
+
+  (org-link-set-parameters "mid" :follow 'thunderbird-open-message-with-id)
+  #+end_src
+
+
+In Thunderbird, to copy a link to an email into the clipboard, open
+the contextual menu, click the =cb_thunderlink= entry and choose the
+entry named =org=. Then paste the link in your org file, and, click it
+to re-open the email.
+
+
+
 * Plain Lists
   :PROPERTIES:
   :CUSTOM_ID: Plain-Lists
-- 
2.39.1

Re: Properly handle defaults in org-set-property

[Janek F]

1. Put the cursor on a heading that does not have an id
2. Invoke (org-set-property "ID" (org-read-property-value "ID" nil 
"default-value")) via keybind or Alt-:
3. default-value is not within the list of suggestions

~ Janek


--- Original Message ---
Ihor Radchenko  schrieb am Donnerstag, 2. Februar 2023 um 
12:14:


> Janek F xer...@pm.me writes:
> 
> > That is exactly what I use, as you can see in my dotfiles:
> > https://code.ftt.gmbh/janek/dotfiles/src/branch/main/.config/doom/config.el#L293
> > 
> > But it leads to the exact aforementioned problem...
> 
> 
> May you please elaborate? What exactly did you do? What did you expect
> to happen? What actually happened? (See
> https://orgmode.org/manual/Feedback.html#Feedback)
> 
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> 
> Support Org development at https://liberapay.com/org-mode,
> 
> or support my work at https://liberapay.com/yantar92

Re: org-clock-sum-today performance

[Tijs Mallaerts]

Hello Ihor,

This is the profiler report:

[profiler-profile "28.1" cpu #s(hash-table size 65 test equal rehash-size
1.5 rehash-threshold 0.8125 data ([nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil] 11 ["#"
auto-revert-buffers--buffer-list-filter apply auto-revert-buffers apply
timer-event-handler nil nil nil nil nil nil nil nil nil nil] 12 ["#" apply
timer-event-handler nil nil nil nil nil nil nil nil nil nil nil nil nil] 7
["#" execute-extended-command--shorter
"#" apply timer-event-handler nil nil nil nil
nil nil nil nil nil nil nil] 19 ["#"
completion--some completion--nth-completion completion-try-completion
execute-extended-command--shorter "#" apply
timer-event-handler nil nil nil nil nil nil nil nil] 20
[completion-pcm--find-all-completions completion-pcm-try-completion
"#" completion--some completion--nth-completion
completion-try-completion execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil nil nil] 36
[completion-pcm--merge-try completion-pcm-try-completion "#" completion--some completion--nth-completion
completion-try-completion execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil nil nil] 4
["#" "#" apply
timer-event-handler nil nil nil nil nil nil nil nil nil nil nil nil] 1
[read--expression byte-code command-execute nil nil nil nil nil nil nil nil
nil nil nil nil nil] 4 [byte-code command-execute nil nil nil nil nil nil
nil nil nil nil nil nil nil nil] 39 ["#" apply
timer-event-handler read--expression byte-code command-execute nil nil nil
nil nil nil nil nil nil nil] 1 [auto-revert-handler auto-revert-buffer
"#" auto-revert-buffers--buffer-list-filter apply
auto-revert-buffers apply timer-event-handler read--expression byte-code
command-execute nil nil nil nil nil] 7 [internal-timer-start-idle
read--expression byte-code command-execute nil nil nil nil nil nil nil nil
nil nil nil nil] 3 [org-element-at-point org-clock-sum org-clock-sum-today
eval-expression funcall-interactively command-execute nil nil nil nil nil
nil nil nil nil nil] 55 [org-element--current-element org-element--parse-to
org-element-at-point org-clock-sum org-clock-sum-today eval-expression
funcall-interactively command-execute nil nil nil nil nil nil nil nil] 376
[org-element--parse-to org-element-at-point org-clock-sum
org-clock-sum-today eval-expression funcall-interactively command-execute
nil nil nil nil nil nil nil nil nil] 196 [org-parse-time-string
org-element-timestamp-parser org-element-clock-parser
org-element--current-element org-element--parse-to org-element-at-point
org-clock-sum org-clock-sum-today eval-expression funcall-interactively
command-execute nil nil nil nil nil] 92 [org-element-clock-parser
org-element--current-element org-element--parse-to org-element-at-point
org-clock-sum org-clock-sum-today eval-expression funcall-interactively
command-execute nil nil nil nil nil nil nil] 246
[org-element-timestamp-parser org-element-clock-parser
org-element--current-element org-element--parse-to org-element-at-point
org-clock-sum org-clock-sum-today eval-expression funcall-interactively
command-execute nil nil nil nil nil nil] 108
[org-get-limited-outline-regexp org-element--current-element
org-element--parse-to org-element-at-point org-clock-sum
org-clock-sum-today eval-expression funcall-interactively command-execute
nil nil nil nil nil nil nil] 4 [org-element-section-parser
org-element--current-element org-element--parse-to org-element-at-point
org-clock-sum org-clock-sum-today eval-expression funcall-interactively
command-execute nil nil nil nil nil nil nil] 32 [org-clock-sum-today
eval-expression funcall-interactively command-execute nil nil nil nil nil
nil nil nil nil nil nil nil] 4 [derived-mode-p
org-get-limited-outline-regexp org-element--current-element
org-element--parse-to org-element-at-point org-clock-sum
org-clock-sum-today eval-expression funcall-interactively command-execute
nil nil nil nil nil nil] 4 [org-element--cache-put org-element--parse-to
org-element-at-point org-clock-sum org-clock-sum-today eval-expression
funcall-interactively command-execute nil nil nil nil nil nil nil nil] 7
[org-time-string-to-seconds org-clock-sum org-clock-sum-today
eval-expression funcall-interactively command-execute nil nil nil nil nil
nil nil nil nil nil] 8 [org-time-string-to-time org-time-string-to-seconds
org-clock-sum org-clock-sum-today eval-expression funcall-interactively
command-execute nil nil nil nil nil nil nil nil nil] 4
[org-element-headline-parser org-element--parse-to org-element-at-point
org-clock-sum org-clock-sum-today eval-expression funcall-interactively
command-execute nil nil nil nil nil nil nil nil] 4 ["#" "#" all-completions
complete-with-action "#" all-completions
ivy--reset-state ivy-read ivy-completing-read read-extended-command-1
read-extended-command byte-code command-execute nil nil nil] 10
[complete-with-action "#" all-completions
ivy--reset-state ivy-read ivy-completing-read read-extended-command-1

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

[Max Nikulin]

On 02/02/2023 21:17, Ihor Radchenko wrote:

Max Nikulin writes:


Would it be reasonable to make org-protocol raise Emacs frame on
failure?


Raising frame may help if window manager allows to do it. In some cases
the only possibility for a window is to request attention. Creating new
frame may be more reliable. Window manager may still take measures
against focus stealing. I have heard that such feature exist, but I am
unsure concerning severity of such policy.


That's usually up to user.


I would not be so sure for windows. Even on Linux Org should be ready 
for any user configuration of window manager.



However I was writing a more annoying issue. Firefox may quietly swallow
attempt to launch external protocol handler. Even no message is spitted
to console like in the case of unknown protocol or throttling due to
multiple attempts during short interval of time. Emacs is completely
unaware of capture attempt in such case.


Can Firefox extensions use DBUS?


Browser extensions are isolated as much as possible. It is assumed that 
they communicate with web sites. They may communicate with a native 
messaging application however. It must be installed and configured in 
addition to the extension. This native host application may use D-BUS, 
but it may invoke emacsclient directly. E.g. I use 
https://github.com/maxnikulin/linkremark extension with 
https://github.com/maxnikulin/burl native messaging helper.


I have not checked state of affairs recently, but when I tried native 
messaging applications were unavailable for browsers shipped as snap or 
flatpack packages (due to additional level of isolation). At least some 
related Firefox bugs have not closed yet.


So in practice it is possible to get it working in both cases: external 
protocol handlers and native messaging helper. I would call any approach 
"rock solid" currently.

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Max Nikulin]

On 02/02/2023 01:16, Bruno Barbier wrote:

Max Nikulin writes:


On 01/02/2023 02:56, Bruno Barbier wrote:
Is it intentional that you and the linked page avoid cb_thunderlink page
on the official add-on site?
https://addons.thunderbird.net/en-us/thunderbird/addon/cb_thunderlink/


No. But visiting the author site being mandatory to install it, I
thought it was simpler to point directly there.


The author suggests to install from github assets instead of official 
add-on catalog for some reason. Perhaps it is just survived since times 
when cb_thunderlink was not published yet.



+#+begin_src elisp
+(defvar cbthunderlink-app nil
+  "The full path where you've installed your cb_thunderlink application.")
+
+(defun cbthunderlink-open (message-id)
+  "Open the given email. MESSAGE-ID is the message id."
+  (start-process "cb_thunderlink" " *cb_thunderlink*"

--^


Yes. This is a buffer that is uninteresting to the user, see:


Thank you for clarification, I forgot about it.


in both cases it promises to register thunderlink:// and
cbthunderlink:// handlers. From my point of view it may be a reason to
take advantage of `browse-url' package. It should allow to avoid
explicit code to start process and to delegate the task to this package
and to handle mid: links by `goto-address-mode' in non-org buffers.

...

I'm not using `browse-url' (except for web pages) and I wasn't aware of
`goto-address-mode'.


My idea was to push '("\\`mid:" . custom/browse-url-mid) to 
`browse-url-handlers' having (untested)


(defun custom/browse-url-mid (url  _ignored)
  (browse-url
   (replace-regexp-in-string "\\`mid:" "thunderlink:/message-id=" url)))

I am unsure concerning double slash after protocol since host name 
expected after double slash. At least KDE may try to resolve hostname 
and to distort URI. I hope, Message-ID never contains characters that 
may require percent encoding when used in query parameter value.


`browse-url-xdg-open' had a lot of revisions before current 
`call-process' settled inside. It is the reason why I will prefer to 
avoid explicit calls to `start-process' (alternatives known to me are 
even worse) and to delegate as much as possible to `browse-url'.



By the way, if cb_thunderlink is more convenient than built-in way to
handle mid: links in thunderbird then support of mid: URI protocol is a
valid feature request for cb_thunderlink.


I'm not sure to understand. The `cb_thunderlink' add-on allow to build
the link in one click from inside Thunderbird; that the part that I find
really useful. And if Thunderbird is able to open an email from its
"mid:" URL, the prefered method should probably be to install only the
add-on inside Thunderbird, and use Thunderbird to reopen the "mid:" link.


Since you suggest thunderlink: links instead of built-in mid: (already 
described in FAQ), I assume that the former approach has some advantage 
over the latter. Nobody forbids to have several handlers for some 
protocol and to let user decide which one their prefer, built-in or 
cb_thunderlink. If cb_thunderlink configures mid: handler then it will 
become available for configuration at the level of desktop environment.

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

[Ihor Radchenko]

Max Nikulin  writes:

>> Would it be reasonable to make org-protocol raise Emacs frame on
>> failure?
>
> Raising frame may help if window manager allows to do it. In some cases 
> the only possibility for a window is to request attention. Creating new 
> frame may be more reliable. Window manager may still take measures 
> against focus stealing. I have heard that such feature exist, but I am 
> unsure concerning severity of such policy.

That's usually up to user.

> However I was writing a more annoying issue. Firefox may quietly swallow 
> attempt to launch external protocol handler. Even no message is spitted 
> to console like in the case of unknown protocol or throttling due to 
> multiple attempts during short interval of time. Emacs is completely 
> unaware of capture attempt in such case.

Can Firefox extensions use DBUS?

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

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

[Max Nikulin]

On 01/02/2023 20:38, Ihor Radchenko wrote:

Max Nikulin writes:


I think, we assume different definitions of "rock solid". Does it able
to detect that desktop configuration of org-protocol is broken and to
notify the user about failure? I do not use :immediate-finish templates,
but some people do. There is a risk to quietly lost captures. I do not
see other ways to detect errors besides a native messaging helper
application.


Would it be reasonable to make org-protocol raise Emacs frame on
failure?


Raising frame may help if window manager allows to do it. In some cases 
the only possibility for a window is to request attention. Creating new 
frame may be more reliable. Window manager may still take measures 
against focus stealing. I have heard that such feature exist, but I am 
unsure concerning severity of such policy.


However I was writing a more annoying issue. Firefox may quietly swallow 
attempt to launch external protocol handler. Even no message is spitted 
to console like in the case of unknown protocol or throttling due to 
multiple attempts during short interval of time. Emacs is completely 
unaware of capture attempt in such case.

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Max Nikulin  writes:

>> Because `encode-time' accepts POSIX TZ as argument. So, may as well.
>> Note that Etc/GMT-8 is also accepted as POSIX TZ.
>
> "May" does not assume "should".

It will be easier to implement POSIX TZ compared to limiting it to TZDB.
We have no way to know if a given string is a valid TZDB entry to not.

> The disappointing issue with POSIX syntax is the case of decision of 
> authorities to change time zone offset. It is neither regular DST rule 
> nor constant offset. The result is incorrect mapping between UTC and 
> local time.

We cannot do much about it, AFAIU. Maximum is trying to do feature
request in glibc, but I assume that they know about this issue.

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 02/02/2023 15:34, Ihor Radchenko wrote:

Max Nikulin writes:

Is there a strong reason to support POSIX TZ? Time zones with fixed
offsets are available as e.g. Etc/GMT-8 (unfortunately inverted sign as
well).


Because `encode-time' accepts POSIX TZ as argument. So, may as well.
Note that Etc/GMT-8 is also accepted as POSIX TZ.


"May" does not assume "should". I am leaving final decision to the 
person who will implement it though. I hope, there is no problem with 
such syntax on windows.


The disappointing issue with POSIX syntax is the case of decision of 
authorities to change time zone offset. It is neither regular DST rule 
nor constant offset. The result is incorrect mapping between UTC and 
local time.

Re: Properly handle defaults in org-set-property

[Ihor Radchenko]

Janek F  writes:

> That is exactly what I use, as you can see in my dotfiles:
> https://code.ftt.gmbh/janek/dotfiles/src/branch/main/.config/doom/config.el#L293
>
> But it leads to the exact aforementioned problem...

May you please elaborate? What exactly did you do? What did you expect
to happen? What actually happened? (See
https://orgmode.org/manual/Feedback.html#Feedback)


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

Re: [ANN] Looking for new maintainers for ox-latex.el (LaTeX export library)

[Ihor Radchenko]

"Fraga, Eric"  writes:

> I am happy to help with both ox-latex and ox-beamer with two caveats: my
> time at certain times of the year is very limited (as you know as there
> is still an outstanding item for ox-beamer that I have not been able to
> address since October or longer) and my elisp-fu is sometimes not up to
> scratch.  However, I do have useful LaTeX & beamer expertise which can
> be useful.

Thanks!
CCing Bastien.

Note that we also got one more volunteer who replied off-list.

> I do monitor the mailing list religiously. :-)

Oh, yeah. 3000+ messages... 朗

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

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Ihor Radchenko]

Ihor Radchenko  writes:

> (your version)
>
> ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Duración" "TODO"
>  "Duración total" "Tiempo archivo" "Generado el")
>
> or
>
> (Esteban's version)
>
> ("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Tiempo" "TODO"
>  "Tiempo total" "Tiempo de archivo" "Resumen de tiempos en")
>
> Note that "time" in English version refers to clocked time, which is
> probably closer in its meaning to "duration" or "time spent".
>
> Pedro, Esteban, any comments?

No further response has been given. I arbitrarily went with Pedro's
version.

Applied, on Pedro's behalf, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8ae8a8462

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

Re: [ANN] Looking for new maintainers for ox-latex.el (LaTeX export library)

[Fraga, Eric]

Ihor,

I am happy to help with both ox-latex and ox-beamer with two caveats: my
time at certain times of the year is very limited (as you know as there
is still an outstanding item for ox-beamer that I have not been able to
address since October or longer) and my elisp-fu is sometimes not up to
scratch.  However, I do have useful LaTeX & beamer expertise which can
be useful.

I do monitor the mailing list religiously. :-)

eric
-- 
: Eric S Fraga, with org release_9.6.1-199-g7ad779 in Emacs 30.0.50

Re: Subtree export of empty entry generates spurious letter

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Hello.  Reporting in case it is just a symptom that might
> resurface in a realistic context.
>
> With release_9.6-204-g2f7052.
>
> I have file consisting only of
>
>#+options: toc:nil author:nil date:nil
>* foo
>* bar
>
> I put the point on the 'foo' line and do 'C-c C-e C-s l o'.  The pdf
> generated shows (without the dashes):
>
>---
>  foo
>o
>

I am unable to reproduce on the latest main.

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

[PATCH v5] org.el: Warning for unsupported markers in `org-set-emphasis-alist'

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I think, verbatim option should not be removed from `defcustom' :type 
>> just now. For some users it might cause fallback to raw lisp value in 
>> easy customization UI. Perhaps another warning should be added to the 
>> `org-set-emphasis-alist' validator and the option should be labeled as 
>> unused in the :type definition.
>
> Makes sense.
> What about the attached patch?
> The idea is to tag the constant as deprecated.

I further improved the patch adding variable watcher. This should catch
everything. See the attached.

Let me know if there are any objections.

>From 78c61c6cc6fe95ab4d661c86ee8b3902a499cd0e Mon Sep 17 00:00:00 2001
Message-Id: <78c61c6cc6fe95ab4d661c86ee8b3902a499cd0e.1675335125.git.yanta...@posteo.net>
From: Max Nikulin 
Date: Mon, 22 Nov 2021 23:56:15 +0700
Subject: [PATCH v5] org.el: Warn about unsupported markers in
 `org-set-emphasis-alist'

* lisp/org.el (org-emphasis-alist): Change custom variable type
definition.  Remove unused third list entry from the default value.

(org-emphasis-alist--check-value): New function used to warn the user
when unsupported value is set.  The function is used via
`add-variable-watcher'.

Attempts to introduce new markers have been discussed enough times to
add some code that should prevent wasting of time.

Link: https://orgmode.org/list/878rxoa6lk.fsf@localhost
---
 lisp/org.el | 56 ++---
 1 file changed, 45 insertions(+), 11 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1947c63a8..bc879e5d7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3635,8 +3635,27 @@ (defvar org-verbatim-re nil
 
 (defvar org-emphasis-regexp-components) ; defined just below
 (defvar org-emphasis-alist) ; defined just below
+(defun org-emphasis-alist--check-value (symbol value  operation _)
+  "Verify the VALUE of `org-emphasis-alist' SYMBOL.
+Issue a warning when the value is not supported.
+Optional argument OPERATION is intended for `add-variable-watcher'
+usage, which see."
+  (when (memq operation '(set let))
+(let ((unsupported
+	   (delq nil
+	 (mapcar
+  (lambda (entry)
+(let ((marker (car entry)))
+  (unless (member marker '("*" "/" "_" "=" "~" "+")) marker)))
+  value
+  (when unsupported
+(warn "Unsupported markup characters '%s' detected in `%s'"
+	  (mapconcat #'identity unsupported " ")
+	  (symbol-name symbol))
 (defun org-set-emph-re (var val)
-  "Set variable and compute the emphasis regular expression."
+  "Set VAR to VAL and compute the emphasis regular expression.
+The function is intended for :set argument of `defcustom' for
+`org-emphasis-alist'."
   (set-default-toplevel-value var val)
   (when (and (boundp 'org-emphasis-alist)
 	 (boundp 'org-emphasis-regexp-components)
@@ -3674,12 +3693,13 @@ (defvar org-emphasis-regexp-components
 
 You need to reload Org or to restart Emacs after setting this.")
 
+(add-variable-watcher 'org-emphasis-alist #'org-emphasis-alist--check-value)
 (defcustom org-emphasis-alist
   '(("*" bold)
 ("/" italic)
 ("_" underline)
-("=" org-verbatim verbatim)
-("~" org-code verbatim)
+("=" org-verbatim)
+("~" org-code)
 ("+" (:strike-through t)))
   "Alist of characters and faces to emphasize text.
 Text starting and ending with a special character will be emphasized,
@@ -3687,18 +3707,32 @@ (defcustom org-emphasis-alist
 marker characters and the face to be used by font-lock for highlighting
 in Org buffers.
 
+Do not change the characters and do not add new ones to use custom
+markers for existing styles or to introduce new styles.  Org syntax is
+not meant to be configurable and such modifications will not work with
+export.
+
 You need to reload Org or to restart Emacs after customizing this."
   :group 'org-appearance
   :set 'org-set-emph-re
-  :version "24.4"
-  :package-version '(Org . "8.0")
+  :package-version '(Org . "9.7")
   :type '(repeat
-	  (list
-	   (string :tag "Marker character")
-	   (choice
-	(face :tag "Font-lock-face")
-	(plist :tag "Face property list"))
-	   (option (const verbatim)
+  (group
+   (choice
+:tag "Marker"
+(const :tag "*Bold*" "*")
+(const :tag "/Italic/" "/")
+(const :tag "_Underline_" "_")
+(const :tag "+Strike-through+" "+")
+(const :tag "=Verbatim=" "=")
+(const :tag "~Code~" "~")
+;; To warn users that it does not work.
+(string :tag "Unsupported ignored character"))
+   (choice
+:tag "Font"
+(face :tag "Face")
+(plist :tag "Property list"))
+   (option (const :tag "Deprecated ignored constant" verbatim)
 
 (defvar org-protecting-blocks '("src" "example" "export")
   "Blocks that contain text that is quoted, i.e. not processed as Org syntax.
-- 
2.39.1



-- 
Ihor 

[PATCH] org-agenda-filter-by-category: fix 'no category' error

[Liu Hui]

Hello,

To reproduce the bug:

1. emacs -Q --eval "(require 'org-habit)"
2. Open the following org file:

---begin--
* TODO foo
SCHEDULED: <2023-02-01 Wed .+2d/4d>
:PROPERTIES:
:STYLE:habit
:CATEGORY: foo
:END:

* TODO bar
SCHEDULED: <2023-02-01 Wed>
- end --

3. M-x org-agenda, then press < a to create an agenda buffer
4. Go to the line containing foo, press <

Expected result: the agenda buffer shows only foo

Actual result:
org-agenda-filter-by-category: No category at point
From 2ac07aeb64d0b12708b54ec8ef26265c64af630e Mon Sep 17 00:00:00 2001
From: Liu Hui 
Date: Wed, 1 Feb 2023 13:35:49 +0800
Subject: [PATCH] org-agenda: Fix `org-agenda-filter-by-category'

* lisp/org-agenda.el (org-agenda-filter-by-category): Use
`org-agenda-get-category' to get the category at current line.
---
 lisp/org-agenda.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 4396efe81..1d1f2271b 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -8210,7 +8210,7 @@ (defun org-agenda-filter-by-category (strip)
   (if (and org-agenda-filtered-by-category
 	   org-agenda-category-filter)
   (org-agenda-filter-show-all-cat)
-(let ((cat (org-no-properties (org-get-at-eol 'org-category 1
+(let ((cat (org-no-properties (org-agenda-get-category
   (cond
((and cat strip)
 (org-agenda-filter-apply
-- 
2.25.1

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Ihor Radchenko  writes:

> Note that an alternative is 

>  [2022-11-12 10:30-11:00]
>  [2022-11-12 10:30-11]
>  [2022-11-12 10:30-11:00-11]

> which is much less confusing.

Hmmm... is it? I read a lot different timestamps these days and
currently I'm very careful reading them, especially while considering
syntax details. Therefore I'm reading slowly and only few timestamps
at once.

But real life sometimes get hectic and stressful. And then I might
only throw a glance at timestamps, hoping to get the important details
- surely I will remember all the important details. :) In these cases I
would much prefer a syntax that is a bit less terse like

>  [2022-11-12 10:30 @+02]

So I would vote for Timothys variant.

Considering Timothys other proposal:

>> I like the way that combining these features works, but I do wonder if 
>> perhaps
>> warning when these two bits of information don’t match should be the default
>> behaviour, and the `!' used to specify which of them should be prioritised?

I do not like the semantics.

>> ┌
>> │ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
>> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07

I read "@+07,!Asia/Singapore" as "use UTC offset +07 but be aware of
time zone Asia/Singapore, from which I got the offset in the first
place".

On the other hand, I read "@+07,Asia/Singapore" as "use UTC offset
+07, which I got from the Asia/Singapore time zone".

So for me a possible warning should go with the "!" variant. In the
case without "!", for me the syntax suggests a more informative
meaning for the time zone name part.

Therefore I would vote for Ihors variant for this part. :)

-- 
Until the next mail...,
Stefan.

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

[Heinz Tuechler]

to...@tuxteam.de wrote/hat geschrieben on/am 02.02.2023 09:33:

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

Max Nikulin wrote/hat geschrieben on/am 02.02.2023 04:22:

On 02/02/2023 04:57, Heinz Tuechler wrote:

My impression is that many of non experts like me don't
know in which time zone they are living.


For you own time zone: Open Development tools in a browser ([F12]),
switch to console, type

 new Intl.DateTimeFormat().resolvedOptions().timeZone



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


Vienna is special :)


Not sure, in
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Europe/Vienna is listed as a canonical TZ database name.



But no: there's no /usr/share/zoneinfo/Europe/Vienna. I think what you
are seeing is just a trick to improve "User Experience".


Searching for /usr/share/zoneinfo/Europe/Vienna
with startpage.com I see it e.g. in
https://packages.ubuntu.com/focal/all/tzdata/filelist or
https://www.apt-browse.org/browse/debian/wheezy/main/all/tzdata/2016d-0+deb7u1/file/usr/share/zoneinfo/Europe


Cheers

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

[Timothy]

Hi Ihor,

>>>  with CST being ambiguous (and also not supported by `encode-time’).
>>
>> I imagine here one could ignore unrecognised but non-conflicting timestamps.
>
> There is no reliable way to detect if a time zone abbreviation is
> ambiguous or not. `encode-time’ will not signal anything and simply
> treat unrecognised time zone as UTC (currently; the actual behaviour is
> undefined AFAIK).

Ah, that makes my idea a bit harder to work with then. Hmmm.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

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

[Ihor Radchenko]

Timothy  writes:

>>  with CST being ambiguous (and also not supported by `encode-time’).
>
> I imagine here one could ignore unrecognised but non-conflicting timestamps.

There is no reliable way to detect if a time zone abbreviation is
ambiguous or not. `encode-time' will not signal anything and simply
treat unrecognised time zone as UTC (currently; the actual behaviour is
undefined AFAIK).

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

Re: org-clock idle time in pgtk Emacs

[Ihor Radchenko]

Max Nikulin  writes:

>>> +(defvar org-pgtkidle-exists-p
>>> +  ;; Check that org-clock-pgtkidle-program-name exists.  But don't do that 
>>> on DOS/Windows,
>>> +  ;; since the command definitely does NOT exist there, and invoking
>>> +  ;; COMMAND.COM on MS-Windows is a bad idea -- it hangs.
>>> +  (and (null (memq system-type '(windows-nt ms-dos)))
>>> +   (eq 0 (call-process-shell-command
>>> +  (format "command -v %s" org-clock-pgtkidle-program-name)))
>>> +   ;; Check that x11idle can retrieve the idle time
>>> +   ;; FIXME: Why "..-shell-command" rather than just `call-process'?
>>> +   (eq 0 (call-process-shell-command 
>>> org-clock-pgtkidle-program-name
>> 
>> We may as well resolve this FIXME since we are at it.
>> Instead of the awkward combination of two `call-process-shell-command'
>> prompts, we can simply use `executable-find' + `call-process'.
>
> Is there a reasonable way to avoid code duplication? I agree that 
> `executable-find' may be better since `org-clock-pgtkidle-program-name' 
> might contain spaces or shell specials causing issues with current code.

I do not think that we should avoid code duplication here.
pgtk and x11 is principally different. The fact that the same code works
for them is rather a co-incidence. It is unlikely that a new
window-system is going to use the same code again. And de-duplicating
jut two functions is not worth it.

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

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

[Timothy]

Hi Ihor,

>> It also occurs to me that this proposed behaviour might be easier with a 
>> single
>> `@TZINFO’ form as I mentioned earlier, e.g.
>>
>> ┌
>> │ [2022-11-12 Sat 12:00]# warn when mismatch
>> │ [2022-11-12 Sat 12:00]  # use Asia/Singapore over +07
>
>  Consider the requests about time zone abbreviations. Without “always
>  warn”, we can do
>
>  [2022-11-12 Sat 12:00]
>
>  with CST being ambiguous (and also not supported by `encode-time’).

I imagine here one could ignore unrecognised but non-conflicting timestamps.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

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

[Ihor Radchenko]

Timothy  writes:

> This functions well, however I see a potential to be confusing at a glance 
> here.
> Consider the visual similarity of 10:30 to 11:00 in local time and 10:30 in
> UTC-11, and the combination of both.
>
> ┌
> │ [2022-11-12 10:30-11:00]
> │ [2022-11-12 10:30-1100]
> │ [2022-11-12 10:30-11:00-1100]
> └

Note that an alternative is 

 [2022-11-12 10:30-11:00]
 [2022-11-12 10:30-11]
 [2022-11-12 10:30-11:00-11]

which is much less confusing.

> I’d be inclined to put the UTC offset together with the time zone name if
> possible. Do you think something along the lines of `@-1100,America/Anchorage'
> could be viable? I’d think that would reduce the chance of confusion.
>
> ┌
> │ [2022-11-12 10:30-11:00]
> │ [2022-11-12 10:30 @-1100]
> │ [2022-11-12 10:30-11:00 @-1100]
> └

This might be an option.
A slight disadvantage is more verbose syntax for simple timestamps like

 [2022-11-12 10:30+02]
 [2022-11-12 10:30 @+02]

>>2022-11-12 12:00+07 @!Asia/Singapore
>>
>>Org will calculate the internal time for both +07 offset and
>>Asia/Singapore time zone. If they do not match, Org will issue a
>>warning. The offset will still be preferred if we have to proceed.
>>
>>This can be useful when planning future meetings and sending Org file
>>with a timestamp to someone else, potentially with obsolete tzdb.
>
> I like the way that combining these features works, but I do wonder if perhaps
> warning when these two bits of information don’t match should be the default
> behaviour, and the `!' used to specify which of them should be prioritised?

I am not sure if it is a good idea.

> It also occurs to me that this proposed behaviour might be easier with a 
> single
> `@TZINFO' form as I mentioned earlier, e.g.
>
> ┌
> │ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07

 Consider the requests about time zone abbreviations. Without "always
 warn", we can do

 [2022-11-12 12:00 @+08,CST]

 with CST being ambiguous (and also not supported by `encode-time').


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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Ihor Radchenko]

Samuel Wales  writes:

> perhaps some cities are not listed?  what is one supposed to do then?
> find a city with equivalent geography and tz policy?

Time zones have nothing to do with cities. The same city may have
multiple time zones in some cases. You just need to know that current
time zone in the area of interest. There is no universal automatic way.
The best we can do it providing completion mechanism, like for time zone
abbreviations.

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

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

[Ihor Radchenko]

Max Nikulin  writes:

> On 01/02/2023 23:45, Ihor Radchenko wrote:
>> 
>> Note how `encode-time' TIME argument has both DST flag and the time zone
>> name:
>> 
>> (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)
>> 
>> DST is necessary exactly in the ambiguous situations like I described,
>> when we must know if day saving time is in effect or not __in addition__
>> to time zone name.
>
> Warning: just be aware that sometimes DST is not enough to resolve 
> ambiguity. E.g. in the following example attempt to pass non-nil DST 
> signals an error:
>
> zdump -v Africa/Juba | grep 2021
> 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

Providing UTC offset will resolve the ambiguity in this scenario. So, we
are good. Unfortunately, there seems to be no way to detect such
ambiguities programmatically. Not using glibc, at least.

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Ihor Radchenko]

Heinz Tuechler  writes:

> Same for me, I usually see ISO offset. Further, I am used to exchange
> time designations (CET, EST, PDT,...) instead of [continent/city]
> timezone names.

While I see a push towards using time zone abbreviations, we should not
make them a part of the syntax.

If we take a look at 
https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations
it states:

Time zones are often represented by alphabetic abbreviations such as
"EST", "WST", and "CST", but these are not part of the international
time and date standard ISO 8601 and their use as sole designator for
a time zone is discouraged. Such designations can be ambiguous; for
example, "CST" can mean China Standard Time (UTC+8), Cuba Standard
Time (UTC−5), and (North American) Central Standard Time (UTC−6),
and it is also a widely used variant of ACST (Australian Central
Standard Time, UTC+9:30). Such designations predate both ISO 8601
and the internet era; in an earlier era, they were sufficiently
unambiguous for many practical uses within a national context (for
example, in railway timetables and business correspondence), but
their ambiguity explains their deprecation in the internet era, when
communications more often cannot rely on implicit geographic context
to supply part of the meaning.

The best we can do is supply a completion dialogue and using TZ POSIX
format that is able to understand "SOMERANDOMZONENAME+07" disregarding
the unknown zone and only using the offset.

> ...My impression is that many of non experts like me don't
> know in which time zone they are living. Is it trivial to find the
> [continent/city] timezone name to a specific place?

If you don't need to worry about time zones than honestly you probably
don't need time zones in your timestamps. And at least you know the UTC
offset, don't you? Time zone abbreviation will gain you nothing if you
know UTC offset because time zone abbreviations don't code information
about the daylight savings and the likes.

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

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

[Ihor Radchenko]

Jean Louis  writes:

> * Ihor Radchenko  [2023-02-01 15:23]:
>> [2022-11-12 14:00 @UTC+2]
>> [2022-11-12 14:00 @UTC-2:30]
>> 
>> are also fine within the proposed format.
>
> The above format is unclear to me. I look at timestamps every day, too
> many, often change them.
>
> I cannot understand what you mean.

See "std offset" format for TZ environment variable.
https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Max Nikulin  writes:

> On 01/02/2023 20:26, Ihor Radchenko wrote:
>> 
>> There is potential confusion coming from the different interpretations
>> of the time zone offsets used in ISO8601 and POSIX TZ specs:
>
> Ihor, I am sorry that I did not reply to your early question.
>
> Is there a strong reason to support POSIX TZ? Time zones with fixed 
> offsets are available as e.g. Etc/GMT-8 (unfortunately inverted sign as 
> well).

Because `encode-time' accepts POSIX TZ as argument. So, may as well.
Note that Etc/GMT-8 is also accepted as POSIX TZ.

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

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

[tomas]

On Thu, Feb 02, 2023 at 08:45:51AM +0100, Heinz Tuechler wrote:
> Max Nikulin wrote/hat geschrieben on/am 02.02.2023 04:22:
> > On 02/02/2023 04:57, Heinz Tuechler wrote:
> > > My impression is that many of non experts like me don't
> > > know in which time zone they are living.
> > 
> > For you own time zone: Open Development tools in a browser ([F12]),
> > switch to console, type
> > 
> >  new Intl.DateTimeFormat().resolvedOptions().timeZone
> > 
> 
> Thank you, Max.
> It seems to me that this shows the time zone I selected at set up of the
> computer, in my case Europe/Berlin. Using package lutz in R with correct
> coordinates I see Europe/Vienna, based on open street map.
> Days ago I did not even know that Berlin and Vienna are in different
> time zones.

Vienna is special :)

But no: there's no /usr/share/zoneinfo/Europe/Vienna. I think what you
are seeing is just a trick to improve "User Experience".

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [BUG] LaTeX aligned equations do not have right spacing [9.6.1 (release_9.6.1 @ /home/yhu/dev/prefix/org-mode/emacs/site-lisp/org/)]

[Ihor Radchenko]

Rick Hu  writes:

> Your bug report will be posted to the Org mailing list.

Canceled.

Re: [BUG] LaTeX aligned equations do not have right spacing [9.6.1 (release_9.6.1 @ /home/yhu/dev/prefix/org-mode/emacs/site-lisp/org/)]

[Ihor Radchenko]

Leo Butler  writes:

> Not a bug. See the attached.

Thanks for the investigation!

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

Re: [BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

>> May you please convert the diff into a patch with changelog entry and
>> commit message? See 
>> https://orgmode.org/worg/org-contribute.html#org045e318
>
> patch attached.

Thanks!

> 1. I have assigned my copyright for Emacs stuff to the FSF

Bastien, may you please confirm?

> 2. My initial version of the patch was against bugfix and now I have set 
> :package-version to "9.6"

Correct.
You can also remove :version tag while we are at it. It is redundant
when :package-version is provided (we are slowly getting rid of the
:version tags across Org).

>  according to the instructions on the org-contribute page. I do not 
> know if this is acceptable (it
>  feels a bit like breaking the rules), but I am happy to redo the 
> patch for main.

bugfix is fine. This is a trivial patch.

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