Clicking timestamps doesn't work until org-agenda is called manually

[Michael Maurer]

Subject line basically states the problem; when I start Emacs and try
to click a timestamp such as <2023-01-16 Mo.>, I get the message
"Symbol's value as variable is void: org-agenda-buffer-name". However,
once org-agenda is called, repeating the action results in the
org-agenda view.

Org html conversion with XyJax

[Partha Pratim Ghosh]

Dear All,

I want to convert my notes written in Org-mode with LaTeX to html so
that they can be seen as a web page using a browser.

Since the notes involve several Xy-pic diagrams, and there is already an
extension of MathJax for using Xy-pic, known as
[[https://github.com/sonoisa/XyJax-v3][XyJax]], the same link shows how
to configure the html to load the proper xypic.js

My query: is it possible to configure the usage of MathJax in Org mode
so that the above mentioned script can be used instead and the
conversion be done smoothly from Org mode conversion.

With my regards and all the very best wishes,

partha

Re: [PATCH] Change default value of org-clock-x11-idle-program-name

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> What we can do is check if xprintidle executable is available and use
>> it. Otherwise, fall back to x11idle to retain backwards compatibility on
>> systems that do no have xprintidle installed.
>
> See the attached patch.


Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1810c625d

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

Re: Clicking timestamps doesn't work until org-agenda is called manually

[Ihor Radchenko]

Michael Maurer  writes:

> Subject line basically states the problem; when I start Emacs and try
> to click a timestamp such as <2023-01-16 Mo.>, I get the message
> "Symbol's value as variable is void: org-agenda-buffer-name". However,
> once org-agenda is called, repeating the action results in the
> org-agenda view.

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


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

Re: [PATCH v2 1/2] lisp/org-clock.el: Make switching states on clock-in/-out easier

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I'm still waiting for final confirmation.  Having some issues getting
>> confirmation from the University.
>
> Thanks for the update. Let us know when the process is done.
>
> Note that universities usually don't have issues with FSF copyright,
> maybe unless you are working on a grant related to Emacs/Org
> development.

Hi,

It has been a while since your last update.
May I know if you managed to get the university approval?
Maybe you need some assistance?

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

First of all, thanks for the detailed suggestion!
I will need more time to look through the provided links and think about
the ideas.

I will provide one important consideration you missed in the below comment.

Sterling Hooten  writes:

> What format and syntax should Org use?
>
> A heretical suggestion: We should abandon the day of week abbreviation
> and use a new format.
> ...
> [2023-01-25 Wed 13:57]–[2023-01-26 Thu 13:57]
>
> it would be:
>
> [2023-01-25T16:57:42Z/2023-01-26T16:57:42Z].

Following ISO and other standards is indeed a reasonable idea. However,
the standards are not necessarily designed for human consumption.
In contrast, Org mode is designed to be read by humans as well, even
without Emacs - just as plain text.

Design for human consumption is one of the reasons we do provide the
redundant information like week day (I personally did find it extremely
useful on multiple occasions) and do use spaces, deviating from ISO. The
above ISO example is barely readable by humans. Another example from
wiki page of ISO 8601 is even worse: R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M

And we need to deviate from ISO 8601 anyway. At least, because it does
not define time zones, only absolute UTC offsets. So, the ability to
conform with the existing formats remains questionable.

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

Re: This is out of thread subject

[Ihor Radchenko]

Jean Louis  writes:

>> Well...
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1678994
>
> That is fine, it is useful to be asked by which application something
> will be opened. It is question about permission, which is given
> once. That does not prevent user opening any URL with external
> programs. Or content type.

Not once. The main problem raised in that bug report is that "always
allow" is unconditionally linked to current url, which is useless for
org-capture - the end result is Firefox asking permission almost every
single time.

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

[BUG] Org-Babel shell problems and crashes with images [9.6.1 (9.6.1-ga6c882 @ /home/joe/.emacs.d/straight/build/org/)]

[Josep Jesus Bigorra Algaba]

Good evening dear community!

This is my first time posting to the mailing list, so I hope I am doing
things right. I am quite new to Emacs and Org but in the short few
months using it, it's been enlightening and amazing.
I have experienced two very crazy bugs lately that are very difficult to
understand and nearly impossible to fix. I am on latest Emacs (from git)
and using the bundled org mode (from git), on openSUSE Tumbleweed,
running with XFCE + Xmonad.

1- Creating a line in an org document that contains more than 2 images
causes Emacs to entirely crash (tested on Emacs 28 all the way to 30),
e.g. [[./dist/example1.png]] [[./dist/example2.png]]
[[./dist/example3.png]]

I am pretty convinced that if you attempt this it will crash on you. I
didn't even have the showing inline images enabled, it doesn't make a
difference.
I have also noticed that having plain links (not surrounded by [[]])
can also lead to crashes sometimes, but difficult to reproduce.

2- Org babel tangle for shell scripts seems to exhibit strange behaviour 
in latest build,

and it adds a strange BOM character at beggining of the script. This
makes it that the script is not runnable anymore. I can
fix this by manually going to exported file and doing a
=set-buffer-file-coding-system RET utf-8= . That seems to remove that
BOM character.

My literate scripts use these options, thought sometimes shebang as
=#!/usr/bin/zsh= :

#+begin_example

#+title: Joe's spin on openSUSE Tumbleweed
#+property: header-args :tangle install :comments org :shebang 
#!/usr/bin/bash

#+auto_tangle: t

#+end_example

Thanks in advance!
I will provide all needed info that additionally is required.

Josep Bigorra
(jjbigo...@gmail.com)


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

of 2023-01-24
Package: Org mode version 9.6.1 (9.6.1-ga6c882 @ 
/home/joe/.emacs.d/straight/build/org/)


current state:
==
(setq
org-agenda-prefix-format '((dashboard-agenda . " %i %-12:c %s ") (agenda 
. " %i %-12:c%?-12t% s")

(todo . " %i %-12:c") (tags . " %i %-12:c") (search . " %i %-12:c"))
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

org-log-done 'time
org-persist-after-read-hook '(org-element--cache-persist-after-read)
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 #[771 ".\207" [] 4 "\n\n(fn NAME 
CONTENTS WIDTH)"]
org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-show-empty-lines
org-cycle-optimize-window-after-visibility-change 
org-cycle-display-inline-images)

org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-mode-hook '(org-auto-tangle-mode olivetti-mode variable-pitch-mode 
er/add-org-mode-expansions
#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook 
org-fold-show-all append local]

5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
#[0 "\301\211.\207" [imenu-create-index-function org-imenu-get-tree] 2] 
rainbow-delimiters-mode

rainbow-mode)
org-babel-load-languages '((mermaid . t) (awk . t) (calc \.t) (C . t) 
(css . t) (emacs-lisp . t) (lisp . t)
(java . t) (js . t) (haskell . t) (perl . t) (python . t) (sass . t) 
(shell . t)

(sql . t) (R . t) (groovy . t) (org . t) (sqlite . t) (makefile \.t))
org-agenda-time-grid '((daily today require-timed) (800 1000 1200 1400 
1600 1800 2000) ".."

"")
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-latex-format-headline-function 
'org-latex-format-headline-default-function

org-confirm-shell-link-function 'yes-or-no-p
org-adapt-indentation nil
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-super-agenda-mode t
org-startup-indented t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-tangle-lang-exts '(("groovy" . "groovy") ("python" . "py") 
("perl" . "pl") ("haskell" . "hs")
("java" . "java") ("lisp" . "lisp") ("D" . "d") ("C++" . "cpp") ("awk" . 
"awk")

("emacs-lisp" . "el") ("elisp" . "el"))
org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

org-confirm-elisp-link-function 'yes-or-no-p
org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function

org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-odt-format-drawer-func

[BUG] Org-mode Side-by-Side Images [9.5.3 (release_9.5.3-3-gd54104)]

[Gustaf Waldemarson]

Hello!

This is a small issue that have vexed me a number of times when I've
been writing up a report or something where I want to export the results
into multiple formats (such as both LaTeX and HTML in the below
example).

At least for me, it is very common to want to display more than one
image side-by-side, but so far I haven't been able to find any solution
that really works in all regards. The example document below shows some
of the things I've tried and mentions some of the issues:


#+LATEX_CLASS: article
#+LATEX_CLASS_OPTIONS: [a4paper,11pt,twoside]
#+LATEX_HEADER: \usepackage{svg}
#+LATEX_HEADER: \usepackage{subcaption}
#+LATEX_HEADER: \usepackage{placeins}
#+LATEX_HEADER: \usepackage{float}
#+LATEX_HEADER: \usepackage{wrapfig}
#+LATEX_HEADER: \usepackage{graphicx}
#+LATEX_HEADER: \usepackage{xspace}
#+LATEX_HEADER: \captionsetup[subfigure]{labelformat=empty}

#+NAME: a
#+BEGIN_SRC dot :file /tmp/a.png :cmdline -Tpng -Gsize=9,15\! -Gdpi=10
  digraph {
  1 -> 2;
  2 -> 3;
  }
#+END_SRC

#+NAME: b
#+BEGIN_SRC dot :file /tmp/b.png :cmdline -Tpng -Gsize=9,15\! -Gdpi=10
  digraph {
  1 -> 3;
  2 -> 3;
  }
#+END_SRC

* LaTeX

  #+BEGIN_CENTER
  #+ATTR_LATEX: :height 0.4\textwidth :center
  #+RESULTS: a
  [[file:/tmp/a.png]]
  #+ATTR_LATEX: :height 0.4\textwidth :center
  #+RESULTS: b
  [[file:/tmp/b.png]]
  #+END_CENTER

* HTML

  (Works, but can't control height for both images.)

  #+ATTR_HTML: :align center :height 300
  [[/tmp/a.png]]
  [[/tmp/b.png]]


* HTML + LaTeX

  Works in both HTML and LaTeX but disables per-image attributes (:height,
  :center etc). Additionally, images in tabular environments tend to be a
bit
  fragile in LaTeX depending on which document style is being used. Also
adds
  undesired lines above/below the table.

  #+ATTR_HTML: :align center
  | [[/tmp/a.png]] | [[/tmp/b.png]] |


* LaTeX Only

  LaTeX example using the common 'subfigure' package.

  \begin{figure}
  \centering
   \begin{subfigure}[c]{0.5\textwidth}
  \centering
  \includegraphics[width=0.9\textwidth]{/tmp/a.png}
  \caption{a.png}
   \end{subfigure}
   \begin{subfigure}[c]{0.3\textwidth}
  \centering
  \includegraphics[width=0.9\textwidth]{/tmp/b.png}
  \caption{b.png}
   \end{subfigure}
 \caption{Subfigures}%
   \end{figure}


  This question was originally asked almost 5 years ago on
  [[
https://emacs.stackexchange.com/questions/38745/orgmode-image-export-side-by-side-to-both-latex-and-html][Emacs
  Stack Exchange]], but so far only have a very limited solution in my
  opinion. Ideally, I'm looking for some kind of org-mode environment
  that could export to most backends (at least HTML and LaTeX) without
  duplicating the image exports for each of them individually.

  Does something like that already exist in org-mode? Alternatively,
  what is the recommended and most portable approach to placing images
  side-by-side?

  Best Regards,
  Gustaf


Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
 of 2022-05-04
Package: Org mode version 9.5.3 (release_9.5.3-3-gd54104 @
/home/guswal01/.local/share/emacs/29.0.50/lisp/org/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-directory "/home/guswal01/.config/emacs/org/"
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-log-into-drawer t
 org-latex-images-centered nil
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
 org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
 org-modules '(org-tempo ol-w3m ol-bbdb ol-bibtex ol-docview ol-gnus
ol-info ol-irc ol-mhe
   ol-rmail ol-eww)
 org-mode-hook '(org-tempo-setup
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append
local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 #[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2]
 my-org-hook turn-on-org-cdlatex)
 org-babel-load-languages '((emacs-lisp . t) (dot . t) (ditaa . t) (python
. t)
(gnuplot . t) (shell . t) (org . t) (plantuml .
t) (latex . t))
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-latex-format-headline-function
'org-latex-format-headline-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-adapt-indentation 'headline-data
 org-ht

Firefox permission dialog and org-protocol

[Max Nikulin]

On 26/01/2023 01:01, Ihor Radchenko wrote:

https://bugzilla.mozilla.org/show_bug.cgi?id=1678994


Bug 1678994 "website permission to open special links in external 
applications not configurable"


Ihor, do you know any details concerning the affected add-on? It seems 
in LinkRemark I managed to avoid the issue somehow. Perhaps due to 
 (Access your data for all websites) permission is required in 
the released version. Or I have specific handler for org-protocol, not 
"always ask" in Firefox configuration.

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

[Sterling Hooten]

Thanks for the quick feedback!

> On 2023-01-27, at 08:09, Ihor Radchenko  wrote:
> 
> Following ISO and other standards is indeed a reasonable idea. However,
> the standards are not necessarily designed for human consumption.
> In contrast, Org mode is designed to be read by humans as well, even
> without Emacs - just as plain text.
> 
> Design for human consumption is one of the reasons we do provide the
> redundant information like week day (I personally did find it extremely
> useful on multiple occasions) and do use spaces, deviating from ISO. The
> above ISO example is barely readable by humans. Another example from
> wiki page of ISO 8601 is even worse: R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M

Certainly agree that the ISO format can be difficult for humans to read, both 
from 
the lack of spaces and terse syntax.

This isn’t (much) of a problem from a display format perspective because we can 
parse 
the encoded format and present the user with a human readable version. So the 
readability 
issue is more about the encoded format. But unlike the display format, which 
could follow 
whatever grammar or locale preference of the user, the encoded format must be 
unambiguously parseable. If it’s possible to make the ISO format more human 
readable 
while still preserving parseability this could be viable.

I’m less arguing against the option for encoding things in a variation of the 
ISO standard, 
but urging that Org support using an encoding of the ISO format in its raw 
state.

> And we need to deviate from ISO 8601 anyway. At least, because it does
> not define time zones, only absolute UTC offsets. So, the ability to
> conform with the existing formats remains questionable.

This is correct for the 2019 version of the ISO 8601.

From my understanding the newest ISO draft is incorporating an existing syntax 
used 
in java.time.ZonedDateTime [JAVAZDT] to allow for time zones. So we could still 
aim for 
compliance with published standards.

The Internet Extended Date/Time Format  (IXDTF) is a forthcoming standard which 
defines an extension syntax for timestamps as specified in [RFC3339]  which 
itself is 
compatible with the [JAVAZDT] syntax.

The IXDTF is of particular interest in this situation because the format 
provides a 
general way to attach any additional information to a timestamp. The authors 
have done 
a great job of lucidly explaining some of the nuances of timestamps.

https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

> I will need more time to look through the provided links and think about
> the ideas.

Look forward to your comments!

Re: Org html conversion with XyJax

[Ihor Radchenko]

Partha Pratim Ghosh  writes:

> I want to convert my notes written in Org-mode with LaTeX to html so
> that they can be seen as a web page using a browser.
>
> Since the notes involve several Xy-pic diagrams, and there is already an
> extension of MathJax for using Xy-pic, known as
> [[https://github.com/sonoisa/XyJax-v3][XyJax]], the same link shows how
> to configure the html to load the proper xypic.js
>
> My query: is it possible to configure the usage of MathJax in Org mode
> so that the above mentioned script can be used instead and the
> conversion be done smoothly from Org mode conversion.

See org-html-mathjax-template and
https://docs.mathjax.org/en/latest/input/tex/extensions.html

Also, you may utilize HTML_HEAD and HTML_HEAD_EXTRA keywords to add
arbitrary config to html header.

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

Sterling Hooten  writes:

>> Design for human consumption is one of the reasons we do provide the
>> redundant information like week day (I personally did find it extremely
>> useful on multiple occasions) and do use spaces, deviating from ISO. The
>> above ISO example is barely readable by humans. Another example from
>> wiki page of ISO 8601 is even worse: R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M
>
> Certainly agree that the ISO format can be difficult for humans to read, both 
> from 
> the lack of spaces and terse syntax.
>
> This isn’t (much) of a problem from a display format perspective because we 
> can parse 
> the encoded format and present the user with a human readable version. So the 
> readability 
> issue is more about the encoded format. But unlike the display format, which 
> could follow 
> whatever grammar or locale preference of the user, the encoded format must be 
> unambiguously parseable. If it’s possible to make the ISO format more human 
> readable 
> while still preserving parseability this could be viable.

You miss that Org should be readable outside Emacs and also outside text
editor that understands Org specifically. Ideally, one should be able to
read Org files in raw form, using notepad or simple cat command. There
is no such thing as "encoding" vs. "display". The encoded format should
be readable by default as well.

Think of Org tables - would take a great care adding all the redundant
spaces to align things nicely despite an alternative possible approach
purely using fontification. Same for heading tags where the alignment is
done by extra spaces.

> I’m less arguing against the option for encoding things in a variation of the 
> ISO standard, 
> but urging that Org support using an encoding of the ISO format in its raw 
> state.

I do not mind supporting raw ISO as an option. But not as the default 
representation.

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

Re: [PATCH] Fix one remaining emacs-30 byte-compile warning

[Ihor Radchenko]

Arash Esbati  writes:

> I have signed the FSF paper for GNU Emacs.  I'm not familiar with Org
> development, but maybe you want to put me under, if at all:
>
>   Here is the list of people who signed the papers with the Free Software
>   Foundation and can now freely submit code to Org files that are included
>   within GNU Emacs:

Sure, but we need to confirm with FSF records first.
Bastien, may you take a look?

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

Re: [O] [PATCH] ob-eval: display error fix

[Ihor Radchenko]

Andreas Gerler  writes:

> +(defcustom org-babel-eval-error-display-notify nil
> +  "Display org-babel-eval-errors always or only if exit code is not 0."

This docstring is confusing. What will happen if the value is nil?
non-nil? I cannot answer these questions by reading the docstring.

Also, what is "org-babel-eval-errors"? Symbol?

Finally, I do not think that "nil" is a good default here. It is better
to display warnings by default and let people disable them only
consciously, when needed. Ideally, we may allow the value to be a list
of backends where to display/not display the warnings.

> +  :group 'org-babel
> +  :version "29.1"

Please use :package-version instead.

And add the new customization to etc/ORG-NEWS.

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Max Nikulin  [2023-01-26 19:21]:
> On 25/01/2023 00:49, Jean Louis wrote:
> > When goto-mode works with mid: by me setting up browse-url-handlers,
> > then I have expected Org to work as well.
> 
> Do you mean `goto-address-mode'? Have you had a look into its
> implementation?

I have already previously mentioned about it. 

In my opinion, features such as opening specific function on URI
scheme shall be unified in Emacs.

Org should now hard code new way of opening URL schemes, but use Emacs
settings.

And I am aware that it is late for such decision, historical decision
was individual based, when Org was not part of Emacs, and it will
break compatibility but then you could introduce option for people to
start changing slowly and integrating better with whole system.

-- 
Jean

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

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

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

[Jean Louis]

* Sterling Hooten  [2023-01-27 09:06]:
>   Offset
> Constant duration difference between times of two time scales
> (ISO). i.e., a quantity to combine with a time scale to produce
> a wall time. e.g., Nepal uses a +5:45 offset from the UTC time
> scale.

I would be careful calling it constant as time offset is changing
depending of daylight saving time. It is not constant.

Time offset time stamp may be derived from time zone time. I am sure
about this.

Time zone time stamp cannot be unambiguously derived from time
offset. I am mostly sure about this.

> What kinds of representations would a calendar system capable of
> handling timezones require?
> 
> • Instant (fixed)
>   • This is referring to an unambiguous moment in time
>   • e.g., 2007-02-03T05:00:00.000Z
> • Offset (fixed)
>   • This captures the idea of "when did it happen for the person who
> made the observation"
>   • e.g., 2007-02-03T04:00:00.000+01:00

Offset is not that fixed, maybe from viewpoint of storage as maybe it
is considered fixed in it's representation, but you have to keep in
mind that time offset by it's definition is changing itself, suddenly,
depending of daylight saving and time zone.

I am trying to find well described reference to read, try here:

Time Zones vs. Offsets – What's the Difference? Which Is Best?:
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

,
| Putting It All Together
| 
| Given a time zone and a UTC time, you can know the offset—and
| therefore the local time. Given a local time and an offset, you can
| know UTC time, but you do not know which time zone you’re in (because
| multiple timezones have the same offset). Given UTC and an offset, you
| can know the local time. Given a time zone and an offset, you don’t
| know much. That’s why a calendar systems work with time zones,
| offsets, and UTC; we need the offset to go from local time to UTC, and
| we need the time zone to go from UTC to local time.
`

> • Instant with explicit offset and zone (fixed)
>   • e.g., 2007-01-01T02:00:00.000+01:00[America/Chicago]
> • Zoned local date time (floating)
>   • Tricky, requires decisions about how to interpret timestamps after
> political changes.
>   • e.g., 2007-01-01T01:00:00.000[America/Chicago]

For calendars it is good to follow recommendation Internet Calendaring
and Schedulingn Core Object Specification (iCalendar)

iCalendar - Date and time format:
https://en.wikipedia.org/wiki/ICalendar#Date_and_time_format

In other words it is good to follow what other successful applications
are already doing. 

For example, if you open Evolution calendar in Gnome:

evolution -c calendar

and make task, and save that task as iCalendar, then you can see what
time stamp format is used there for exchange purposes.

Representation for user using Org file is different from
representation for sharing purposes, as user already (mostly) have
specified local time zone on this computer, while sharing object such
as iCalendar file must take that information of local time zone and
store it unambiguously.

> I claim that before dealing with the nuances of calendar appointments,
> repeating events, agenda displays etc, that Org must first support
> fixed/absolute time instead of just floating time. 

Parameters needed to make it fixed are already in computer, only
disconnected. 

changing this time stamp for Org:
<2023-01-27 Fri 10:18>
to something "fixed" would break Org compatibility for past Org files.

While new unambigious time stamp formats may be introduced, the way to
go is with past time stamps is to understand the time stamp for
representation and calculation purposes by using OR logical function:

timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-zone

as by using those, for now still disconnected parameters, one can get
the fixed time for representation purposes (Org export or sharing) or
calculation purposes (on local computer and by using some shared Org
objects).

> Without some basis time scale the conversions from time zones and
> offsets to some incremental time point is impossible. Resolving this
> prerequisite will also simplify the timezone discussion because we
> won't be mixing calendar issues with time issues.

I guess that OR consideration above may remedy it and keep past
compatibility while expanding more specific time stamp as option.

> What would a roadmap be?
> 
> • Design and implement an absolute and offset timestamp system
>   • Decide on a time scale
>   • Decide on a format and syntax
>   • Implement instant timestamps
>   • Implement offeset timestamps
> • Design and implement the time zone aware calendar system This is a
>   separate project.

Sounds complex to me and over board for program that tries to define
data type by using simple text written ambiguously by many people.

> What format and syntax should Org use?
> 
> A heretical suggestion: We should abandon the day of week abbreviation
> and use a new fo

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

[Ihor Radchenko]

Bastien Guerry  writes:

>> Bastien, could you please confirm the copyright status of Andreas
>> Gerler?
>
> It was missing in the FSF copyright.list file, but it has been fixed
> and Andreas can be added as a regular contributor.

Daniel, there is thus no obstacle installing the patch. And no need to
add TINYCHANGE cookie.

Note, however, that the commit message lacks changelog entry. We may
either ask Andreas to add it or you can do it manually, install the
patch, and take note about the amendment in the email thread (see my
other email replies).

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

Re: ob-sql dbconnection engine

[Ihor Radchenko]

Andreas Gerler  writes:

> as I am still learning more elisp it took me some try and error but I can use 
> the sql-product now within dbconnection.
> Using :engine still works as well.
> Still wondering if there is a more elegant way for the if clause.

Thanks for the patch!
Could you please explain in more details what the patch does?

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

Bastien Guerry  writes:

> It was missing in the FSF copyright.list file, but it has been fixed
> and Andreas can be added as a regular contributor.

Done.
https://git.sr.ht/~bzg/worg/commit/3dbeb2db

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

[POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Ihor Radchenko]

Timothy  writes:

> I’ve recently come across an interesting looking library available on ELPA,
> . I’m thinking in future this could allow us 
> to
> both use newer features and also support older versions of Emacs, e.g.
>
> Org 10.X is developed for Emacs 28.1 and newer, but supports Emacs 24.3 and
> newer with compat.el.
>
> Just tossing this out as an idea :)

I have recently been contacted by the current compat.el maintainer
asking if we are willing to adapt compat.el in Org.

Pros:

1. We will have less headache maintaining org-compat.el.
2. We will get an ability to use functions and macros from newer Emacs
   versions almost for free.
   
Cons:

1. If compat.el happens to lack support of some function, we will need
   to contribute to compat.el directly and synchronize Org releases with
   compat.el releases.

WDYT?

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

[ANN] Looking for new maintainers for ox-html.el

[Ihor Radchenko]

Hello,

I have been informed that our current ox-html maintainer will no longer
able to perform his duties in full extent.

We thus need volunteers to help maintaining Org HTML export library -
lisp/ox-html.el

We need people fluent with Elisp with FSF copyright assignment (or
willing to sign it).



You do not need to be an expert of the functionality in the file or to
actively improve the file. Just take care of bug reports and feature
requests against this file by participating in the discussion on the
list.

You are not strictly required to follow the mailing list closely and
watch for the relevant emails. When necessary, the relevant messages
will be directly forwarded to your email.

[ see more details at https://orgmode.org/worg/org-maintenance.html ]

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

Re: [POLL] Use compat.el in Org?

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> I have recently been contacted by the current compat.el maintainer
> asking if we are willing to adapt compat.el in Org.

Very nice!

> WDYT?

As long as we keep our promise in terms of backward compatibility with
older Emacs versions, I'm all for it.

-- 
 Bastien

Re: [ANN] Looking for new maintainers for ox-html.el

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> I have been informed that our current ox-html maintainer will no longer
> able to perform his duties in full extent.
>
> We thus need volunteers to help maintaining Org HTML export library -
> lisp/ox-html.el

I depend on ox-html for my personal website. I would be glad to help.

> We need people fluent with Elisp with FSF copyright assignment (or
> willing to sign it).

I have copyright set up assignment and I’m mostly fluent with FSF.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

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

[Jean Louis]

* Sterling Hooten  [2023-01-27 15:50]:
> This isn’t (much) of a problem from a display format perspective
> because we can parse the encoded format and present the user with a
> human readable version.

Org files shall still be readable as plain text IMHO.

As Org textual structure has been adopted by other text editors, and
various applications, it is not feasible to expect that other
editors and applications would be re-writing the displayed text to
show to user their local time.

Only user's local time is friendly to user.

Other options may be added, though focus should be on helping human
and making things easy.

-- 
Jean

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

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 27/01/2023 13:41, Jean Louis wrote:

* Max Nikulin [2023-01-26 19:21]:

On 25/01/2023 00:49, Jean Louis wrote:

When goto-mode works with mid: by me setting up browse-url-handlers,
then I have expected Org to work as well.


Do you mean `goto-address-mode'? Have you had a look into its
implementation?


I have already previously mentioned about it.


I was unsure if goto-mode is a typo or some 3rd party package. Have you 
written that you are aware which way it is implemented?


List of recognized protocols is not a user option, it is hard-coded and 
unrelated to the browse-url-handlers:


defvar thing-at-point-uri-schemes

the list is rather long.

On 25/01/2023 00:49, Jean Louis wrote:

Try to think from position of a developer.


From position of developer, developers shall ideally think of users,
and users think of the assistance of computer to users. 


Users appreciate developers who make their life easier.


Developer must consider other features that may be affected by demanded 
changes. False positives are acceptable for thingatpt and 
goto-address-mode. For Org mode balance is different. Too greedy regexp 
to recognize links may have detrimental effect on export and publish, 
not to mention that links may need special treatment. In addition Ihor 
mentioned fuzzy links.


On 27/01/2023 13:41, Jean Louis wrote:

In my opinion, features such as opening specific function on URI
scheme shall be unified in Emacs.


Generally agree, but browse-url should be ready to reuse its 
configuration in Org. I am afraid, it means less flexible browse-url.



Org should now hard code new way of opening URL schemes, but use Emacs
settings.


Try to derive list of supported schemes from `browse-url-handlers'.


And I am aware that it is late for such decision,


You may try to talk to `browse-url' developers if they are ready to make 
their package less flexible for the sake of Org mode.


And finally notice that goto-address-mode is unable to properly handle

(test https://orgmode.org)

it considers closing parenthesis as a part of the link. In addition 
there are disclaimers:


Customizations to this variable made after goto-addr is loaded
will have no effect.

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

[Andreas Gerler]

Hi!

I can prepare a new commit this weekend.

so long...

Andreas

> On Jan 27, 2023, at 2:18 PM, Ihor Radchenko  wrote:
> 
> Bastien Guerry  writes:
> 
>> It was missing in the FSF copyright.list file, but it has been fixed
>> and Andreas can be added as a regular contributor.
> 
> Done.
> https://git.sr.ht/~bzg/worg/commit/3dbeb2db
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Bruno Barbier]

Bruno Barbier  writes:

> Max Nikulin  writes:

>> If Message-ID still can be decoded from cb_thinderlink URIs than it 
>> should be possible adapt orco to handle such links as well.

I'm using plain Message-IDs to identify my emails, and, when choosing an
email client, that's really the first feature that I'm checking.

In Thunderbird, in the cb_thunderlink config (v 1.6.0), I'm using a link format
that is compatible with the old thunderlink extension:

 [[email:$msgid$][$author_name$: $subject$ ($date_iso$)]]

 
To open a message whose "Message-ID" is 'message-id', org just
requests my operating system to open a link like:

 (concat "thunderlink://messageid=" message-id)


It looks like thunderbird allows to search for Message-ID (see
headerMessageId):

   
https://webextension-api.thunderbird.net/en/stable/messages.html#messages-query
   
and there is no warning about using it. I'm guessing that cb_thunderlink
is using this.

Hope this may help,

Bruno

Re: [BUG] Org-Babel shell problems and crashes with images [9.6.1 (9.6.1-ga6c882 @ /home/joe/.emacs.d/straight/build/org/)]

[Matt]

  On Wed, 25 Jan 2023 14:34:19 -0500  Josep Jesus Bigorra Algaba  wrote --- 

 > This is my first time posting to the mailing list

Welcome and thanks for taking the time to send us a message!  I love hearing 
how much you've enjoyed your experience with Org.  We love it, too!

 > 2- Org babel tangle for shell scripts seems to exhibit strange behaviour 
 > in latest build,
 > and it adds a strange BOM character at beggining of the script. This
 > makes it that the script is not runnable anymore. I can
 > fix this by manually going to exported file and doing a
 > =set-buffer-file-coding-system RET utf-8= . That seems to remove that
 > BOM character.
 > 
 > My literate scripts use these options, thought sometimes shebang as
 > =#!/usr/bin/zsh= :
 > 
 > #+begin_example
 > 
 > #+title: Joe's spin on openSUSE Tumbleweed
 > #+property: header-args :tangle install :comments org :shebang 
 > #!/usr/bin/bash
 > #+auto_tangle: t
 > 
 > #+end_example

I'm the ob-shell maintainer, so I'm most interested in your second point, the 
one related to shell things.

1. Your first point mentions that you've reproduced the bug in Emacs 28 through 
30.  Is the same true for this second, shell/tangle related issue?

2. Does the problem happen with both bash and zsh or just zsh? 

3. Can you please give steps to reproduce the problem?

I'm wondering if something like this is enough to reproduce it or if you're 
doing something different.  (Note that I'm using #!/usr/bin/env zsh instead of 
#!/usr/bin/zsh because of how my system is set up.)

#+property: header-args :tangle install :comments org :shebang #!/usr/bin/env 
zsh

#+begin_src emacs-lisp :export no :tangle no
(org-babel-do-load-languages
'org-babel-load-languages
'((shell . t)))  
#+end_src

#+begin_src sh
  readlink /proc/$$/exe
#+end_src

4. Also, are you running into the issue when starting Emacs using `emacs -Q'? 

Re: [BUG] Org-Babel shell problems and crashes with images [9.6.1 (9.6.1-ga6c882 @ /home/joe/.emacs.d/straight/build/org/)]

[Bruno Barbier]

Josep Jesus Bigorra Algaba  writes:

> 1- Creating a line in an org document that contains more than 2 images
> causes Emacs to entirely crash (tested on Emacs 28 all the way to 30),
> e.g. [[./dist/example1.png]] [[./dist/example2.png]]
> [[./dist/example3.png]]
>
> I am pretty convinced that if you attempt this it will crash on you. I
> didn't even have the showing inline images enabled, it doesn't make a
> difference.
> I have also noticed that having plain links (not surrounded by [[]])
> can also lead to crashes sometimes, but difficult to reproduce.
>

FWIW, I couldn't reproduce it (3,4, 5 times the same png image on one line, 
displayed or not).

   Org mode version 9.6.1 (release_9.6.1-16-ge37e9b)
   
   GNU Emacs 29.0.60 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
   version 1.17.6) of 2023-01-24

But, as you managed to crash emacs, you should probably report an
emacs bug about this (M-x report-emacs-bug).

Bruno

Re: Org html conversion with XyJax

[Rudolf Adamkovič]

Partha Pratim Ghosh  writes:

> #-*- mode: org -*-

FYI: You do not need this line if the file has an '.org' extension.

> #+TITLE: test
> #+AUTHOR: Partha

> #+latex_header:\usepackage{Documents/tex/essentials/symbols}

Note that this header applies to LaTeX and will not work with MathJax.

You can make Org to use actual LaTeX in HTML by adding

#+OPTIONS: tex:dvisvgm

to your document.

> Can I use \LaTeX ? Let us try: $f: A\rightarrow B$ is a function

MathJax ignores \LaTeX but renders the function correctly.

(I tried with plain 'emacs -Q' on Emacs 30.)

> $\xymatrix{ {A} \ar@{o->}[r] & {B} }$

MathJax does not recognize this, hence the "Misplaced &" error.

You have two options here: either (1) install the MathJax extension you
mentioned or (2) make Org to use LaTeX for HTML.

If you decide to go the MathJax/JavaScript route, please note that you need to
use Emacs 29 or later, where Org uses MathJax 3 and not 2.

> \Arr{f}{A}{B}

MathJax does not recognize this either.

> 2. The file exports perfectly to pdf:

That happens because Org always uses LaTeX for PDF documents.  If you want it to
use LaTeX for HTML too, see the OPTIONS above.

Rudy
-- 
"Chop your own wood and it will warm you twice."
-- Henry Ford; Francis Kinloch, 1819; Henry David Thoreau, 1854

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [POLL] Use compat.el in Org?

[Tim Cross]

Bastien Guerry  writes:

> Hi Ihor,
>
> Ihor Radchenko  writes:
>
>> I have recently been contacted by the current compat.el maintainer
>> asking if we are willing to adapt compat.el in Org.
>
> Very nice!
>
>> WDYT?
>
> As long as we keep our promise in terms of backward compatibility with
> older Emacs versions, I'm all for it.

I would agree. I would also add that even with the use of this package,
I don't think we should use it to increase the number of versions we
support as support is not as simple as dropping in a compatibility
library. These libraries come with a cost. Often, compatibility code
does not perform as well and/or is much more complicated and more likely
to have bugs. The more a version of emacs needs to rely on this library
to run org-mode, the higher the likelihood performance will be degraded
or unexpected new bugs are found.

So, use the library, but keep the existing policy of officially
supporting only the previous two major releases. If org does work with
even older versions, that is great, but not supported.

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

[Tim Cross]

Ihor Radchenko  writes:

> First of all, thanks for the detailed suggestion!
> I will need more time to look through the provided links and think about
> the ideas.
>
> I will provide one important consideration you missed in the below comment.
>
> Sterling Hooten  writes:
>
>> What format and syntax should Org use?
>>
>> A heretical suggestion: We should abandon the day of week abbreviation
>> and use a new format.
>> ...
>> [2023-01-25 Wed 13:57]–[2023-01-26 Thu 13:57]
>>
>> it would be:
>>
>> [2023-01-25T16:57:42Z/2023-01-26T16:57:42Z].
>
> Following ISO and other standards is indeed a reasonable idea. However,
> the standards are not necessarily designed for human consumption.
> In contrast, Org mode is designed to be read by humans as well, even
> without Emacs - just as plain text.
>
> Design for human consumption is one of the reasons we do provide the
> redundant information like week day (I personally did find it extremely
> useful on multiple occasions) and do use spaces, deviating from ISO. The
> above ISO example is barely readable by humans. Another example from
> wiki page of ISO 8601 is even worse: R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M
>
> And we need to deviate from ISO 8601 anyway. At least, because it does
> not define time zones, only absolute UTC offsets. So, the ability to
> conform with the existing formats remains questionable.


I strongly agree with Ihor here. We want our timestamps to be easily
read and understood by users. I have also found the redundant day of the
week information very useful.

While we could argue that with overlays or similar, you could get the
best of both worlds i.e. a storage format which is easy for functions to
parse and a display format which is easy for humans to parse, but that
would also work only when you view your org files within org mode. One
of the benefits of org mode is its plain text nature and that you can
read most org mode files 'raw' and they are quite easy to understand. 

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

[Tim Cross]

Jean Louis  writes:

> * Sterling Hooten  [2023-01-27 09:06]:
>>   Offset
>> Constant duration difference between times of two time scales
>> (ISO). i.e., a quantity to combine with a time scale to produce
>> a wall time. e.g., Nepal uses a +5:45 offset from the UTC time
>> scale.
>
> I would be careful calling it constant as time offset is changing
> depending of daylight saving time. It is not constant.
>
> Time offset time stamp may be derived from time zone time. I am sure
> about this.
>
> Time zone time stamp cannot be unambiguously derived from time
> offset. I am mostly sure about this.
>
>> What kinds of representations would a calendar system capable of
>> handling timezones require?
>> 
>> • Instant (fixed)
>>   • This is referring to an unambiguous moment in time
>>   • e.g., 2007-02-03T05:00:00.000Z
>> • Offset (fixed)
>>   • This captures the idea of "when did it happen for the person who
>> made the observation"
>>   • e.g., 2007-02-03T04:00:00.000+01:00
>
> Offset is not that fixed, maybe from viewpoint of storage as maybe it
> is considered fixed in it's representation, but you have to keep in
> mind that time offset by it's definition is changing itself, suddenly,
> depending of daylight saving and time zone.
>

I think your misinterpreting the intent here. If you specify a timestamp
with offset, it is fixed. It does not change with daylight savings or
any other change in rules for a time zone. It does not even specify a
time zone. While it is true that a specific location may have time zone
changes or that the offset from UTC might change as a result of daylight
savings, an offset specified in a times stamp does not change and is
fixed.  This is one of the limitaiton with using offset.

I also think it is a mistake (which I've seen others suggest in this
thread) to equate an offset as being an abbreviation for a time
zone. For example, some have suggested things like +1 being the same
as AEST and both being abbreviations for Australia/Sydney outside of
daylight savings periods. I think that is incorrect. +1000 is a fixed
offset from UTC and while it may be the same offset used in a time zone
abbreviation like AEST or in a full time zone specification like
Australia/Sydney, it is not a time zone specification, only an offset
for a specific point in time.

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Tim Cross]

"Thomas S. Dye"  writes:

> No, I don't think you've missed anything significant.  Thanks very much for 
> your patience
> during a discussion that was interesting for me.  I learned quite a bit from 
> you and the
> other contributors to the thread and look forward now to learning how Org 
> mode evolves to
> handle events and occurrences.
>
> Let me know if you have questions.
>

Agreed. I also think this latest discussion is extremely valuable as
coming up with some clear terminology which can be used to reference
different use cases for timestamps is very likely going to make
documentation and exmaples/tutorials much cleaner and could help define
a more intuitive interface which helps users select the right option in
the right circumstance.

Re: [POLL] Use compat.el in Org?

[Daniel Mendler]

On 1/27/23 21:38, Tim Cross wrote:
>> As long as we keep our promise in terms of backward compatibility with
>> older Emacs versions, I'm all for it.
> 
> I would agree. I would also add that even with the use of this package,
> I don't think we should use it to increase the number of versions we
> support as support is not as simple as dropping in a compatibility
> library. 

True. The Compat package cannot fix bugs below the Elisp level or
provide APIs which cannot be backported, e.g., big integer support. If
Org relies on behavior of the Emacs display engine or the C core of a
certain Emacs version, Compat cannot help.

The advantage would be that the maintenance burden of org-compat would
be reduced. Many packages can share the backported functions by
depending on Compat, which will increase robustness and reduce the risk
of unexpected bugs. The community only has to maintain a single set of
backported functions in a single package, instead of scattering
compatibility code across many packages.

> These libraries come with a cost. Often, compatibility code
> does not perform as well and/or is much more complicated and more likely
> to have bugs. The more a version of emacs needs to rely on this library
> to run org-mode, the higher the likelihood performance will be degraded
> or unexpected new bugs are found.

To give some context about the stability aspect - many backported
compatibility functions are copied verbatim from newer Emacs versions.
Every compatibility function provided by Compat is covered by tests,
which are executed via CI on all supported Emacs versions (>= 24.4). I
make sure that no functions are backported which perform much worse such
that they would introduce performance bugs.

Daniel

Re: [POLL] Use compat.el in Org?

[Samuel Wales]

what daniel said sgtm

On 1/27/23, Daniel Mendler  wrote:
> On 1/27/23 21:38, Tim Cross wrote:
>>> As long as we keep our promise in terms of backward compatibility with
>>> older Emacs versions, I'm all for it.
>>
>> I would agree. I would also add that even with the use of this package,
>> I don't think we should use it to increase the number of versions we
>> support as support is not as simple as dropping in a compatibility
>> library.
>
> True. The Compat package cannot fix bugs below the Elisp level or
> provide APIs which cannot be backported, e.g., big integer support. If
> Org relies on behavior of the Emacs display engine or the C core of a
> certain Emacs version, Compat cannot help.
>
> The advantage would be that the maintenance burden of org-compat would
> be reduced. Many packages can share the backported functions by
> depending on Compat, which will increase robustness and reduce the risk
> of unexpected bugs. The community only has to maintain a single set of
> backported functions in a single package, instead of scattering
> compatibility code across many packages.
>
>> These libraries come with a cost. Often, compatibility code
>> does not perform as well and/or is much more complicated and more likely
>> to have bugs. The more a version of emacs needs to rely on this library
>> to run org-mode, the higher the likelihood performance will be degraded
>> or unexpected new bugs are found.
>
> To give some context about the stability aspect - many backported
> compatibility functions are copied verbatim from newer Emacs versions.
> Every compatibility function provided by Compat is covered by tests,
> which are executed via CI on all supported Emacs versions (>= 24.4). I
> make sure that no functions are backported which perform much worse such
> that they would introduce performance bugs.
>
> Daniel
>
>


-- 
The Kafka Pandemic

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

Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

[Jack Kamm]

Ihor Radchenko  writes:

> Let's follow the usual approach and first deprecate it. It should become
> a constant with 'python value in org-compat.el. Deprecating is not make
> sure that other packages that might be testing the variable value do not
> get broken.
>
> Note that we usually `quote' Elisp symbols in the commit messages.

Thank you for the review. I've incorporated your feedback and pushed
the patch as commit aa48c80fe17eaaaf83c11c9ac2f2fd864f2f3ad9

> I find the need to use advise awkward. Is it necessary?

I agree it is awkward, and also fragile to future changes in ob-python.

But unless I've missed something, I think some advice is needed to get
the old behavior. Still, it would be more robust to just advise the
main function org-babel-execute:python, instead of advising the 2
helper functions.

But, this would require a little extra work, and while I might do it
later, it's a lower priority for me right now (it's unclear whether
there are currently active python-mode users of ob-python). For the
moment, I just updated the Readme to say the current implementation is
a temporary workaround, and it will work for Org 9.7, but may not work
in future versions as ob-python evolves.

Arguably, it would be best to avoid overriding python src blocks
altogether, and instead have completely separate python-mode src
blocks. But I would leave such a design decision to whoever decides to
maintain babel+python-mode integration in future.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 28/01/2023 01:15, Bruno Barbier wrote:



If Message-ID still can be decoded from cb_thinderlink URIs than it
should be possible adapt orco to handle such links as well.


I'm using plain Message-IDs to identify my emails, and, when choosing an
email client, that's really the first feature that I'm checking.

In Thunderbird, in the cb_thunderlink config (v 1.6.0), I'm using a link format
that is compatible with the old thunderlink extension:

  [[email:$msgid$][$author_name$: $subject$ ($date_iso$)]]


Notice that you can use mid:$msgid$ instead of email:$msgid$.

thunderbird 'mid:tqr8et$mrc$1...@ciao.gmane.io'

opens the message in a new tab or a new window. Sometimes separate tab 
is inconvenient, but context menu has "show message in containing 
folder" item. ESR releases 91 and 102 support it out of the box. Whether 
thunderbird.desktop contains "x-scheme-handler/mid;" in the MimeType 
parameter (and so desktop-wide integration out of the box) depends on 
particular Linux distribution. For emacs it means that (browse-url 
"mid:tqr8et$mrc$1...@ciao.gmane.io") should just work.



To open a message whose "Message-ID" is 'message-id', org just
requests my operating system to open a link like:

  (concat "thunderlink://messageid=" message-id)


This approach can be used with "mid:" scheme for links in Org files as well.


It looks like thunderbird allows to search for Message-ID (see
headerMessageId):


https://webextension-api.thunderbird.net/en/stable/messages.html#messages-query

and there is no warning about using it. I'm guessing that cb_thunderlink

is using this.


There was a lag between thunderbird-78 and some later version when there 
was no easy access to Message-ID header in add-on API. Likely it is a 
reason why cb_thunderlink has a warning that such links might be broken 
in future. I have not checked if standard API or custom low level code 
is currently used in cb_thuderlink for lookup by Message-ID.


In orco standard messages.query() is used to search for Message-IDs 
extracted from links, e.g. 
https://list.orgmode.org/t7q766$m5k$1...@ciao.gmane.io It is convenient to 
see message subject and date without leaving thunderbird. The main point 
of orco is opposite mapping. It makes possible to open in emacs the 
location in file that has link to current mail message.

Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > 1. For this purpose, what kind of thing is "the Oracle Database"?
  > > a. A library to link with?
  > > b. A program to run in a subprocess?
  > > c. A server running SaaSS?

  > None of the above!

I found that reply tantalizing but not helpful.
Fortunately, others have given helpful replies,
from which I could see there is no ethical problem in
using sql.el to run the Oracle data base software.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Would it then make sense to note the reasons why we support one or
  > another non-free software in a separate file like etc/NON-FREE-SUPPORT?

I think it is a good idea to document the reasoning for these
decision.  But I think it does not necessarily have to be centralized
in one file for all of Emacs.  Another alternative, also natural,
would be to describe these decisions with the code that implements the
support.

  > Also, what about Emacs supporting MS DOS and old versions of Windows? Do
  > they still qualify as popular software?

There is no need to include version numbers when we judge whether a
program is well known.  People are far more likely to think about a
program name than about its various version numbers.

If a program was once well known, but its use is dwindling, it's not
something we have to worry about informing people about.  More people
will have heard of it in the past, than will want to switch to it now.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > However, I gues the point remains, sql.el and ob-sql.el support a number
  > of non-free RDMS

Can someone post a verified list of which of them are non-free?
Someone posted a list of a few, which I cannot find now in my saved
inboxes, but I think it included oracle, mysql, vertica? and a fourth
one else (what was it?).

Does sql.el handle any other nonfree ones aside from those?

   > and I think this is fine given that

That is something we should double-check in accord with the stated
policy.  But first we need to know which ones to check.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Max Nikulin]

Sterling, thank you very much for the list of references. I was not 
aware of EDTF activity or the proposal for JavaScript.


I do not mind to have better precision for timestamps. Minutes are too 
coarse. However I would consider with low priority.


I would prefer to postpone some discussions now. At the current moment 
just be aware than one more person may have another opinion. Redundant 
fields are useful for humans, in addition, they allow to detect 
inconsistency. Date and time format with spaces are more friendly to 
humans as well. "T" hampers readability. So I feel some kind of internal 
conflict trying to achieve following standards, backward compatibility, 
and human readability simultaneously. I am unsure what is the proper 
solution.


The following is what I consider as more serious issues:

On 27/01/2023 13:06, Sterling Hooten wrote:

   Duration (object)
 as a quantity characterizing a time interval. These can be
 written in different formats.


Interval, duration, elapsed time are tricky. I do not have preferences 
whose definitions we should follow. Just an example: (info "(libc) Time 
Basics") https://www.gnu.org/software/libc/manual/html_node/Time-Basics.html


Notice that 1 day does not necessary means 24 hours. Depending on 
starting day (e.g. before DST) other relations may be used, either 23 or 
25 hours (usually). It is still 1 day. The way to specify interval 
should be chosen depending on application.


Another case is January, 31 + 1 month. It actually may mean last day of 
January, so expected result may be February, 28 or 29. This case 
February, 28 + 1 month (the same interval) is March, 31.



   Local system time
 Local system time is determined by applying the system's time
 zone offset and year offset values to UTC. The Time of day
 system value displays the local system time. Local system time
 and system time are used interchangeably.


"System time" is often used in the sense of hardware clock and 
originated from the times when DOS or Windows required local time.



   Time Zone
 A place/region.


Do you consider e.g. Etc/GMT-8 or UTC itself as a time zone?


   Floating time
 A wall time value without time zone or offset information. E.g.,
 2023-01-24 or 6:45pm.


A potential source of confusion with timestamp in seconds since epoch as 
a floating point number, see `float-time'. (info "(elisp) Time of Day") 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-of-Day.html#index-float_002dtime



Org must first support
fixed/absolute time instead of just floating time.


Am I wright "in addition" is applicable here in the place of "instead"?


• Design and implement the time zone aware calendar system This is a
   separate project.


Will not such decision ruin "every Wednesday at 3:00 PM" at the moment 
of DST transition? I would vote that IANA DB should be used for 
calculations despite I have not seen a library with perfect API. Though 
libc with some tricks may allow to do most of tasks. (Even in presence 
of limitations such as unavailable identifier of system time zone.) This 
is the main point of my disagreement. If real time zones are not 
implemented from the beginning then the will be never supported, so the 
whole bunch of code will be requiring throwing away while keeping 
support of some formats to read old files.



   • We are able to defer to experts and 35 years of knowledge rather
 than debate among ourselves


Experts may generate enough pain such as requirement to not support IANA 
timezone DB as it was in EcmaScript 5 (Chrome followed it, but in 
Firefox conversion between local time worked correctly).

Re: Org html conversion with XyJax

[tomas]

On Fri, Jan 27, 2023 at 09:41:59PM +0100, Rudolf Adamkovič wrote:
> Partha Pratim Ghosh  writes:
> 
> > #-*- mode: org -*-
> 
> FYI: You do not need this line if the file has an '.org' extension.

*and* if your auto-mode-alist happens to be the right one. And if
someone else hasn't given other name to the file. And...

FWIW, I put that in always: I don't like metadata embedded in a
file name (it reminds me fatally of MS-DOS ;-)

[...]

Thanks for your other suggestions!

[Not the OP, but learning]

Cheers
-- 
t


signature.asc
Description: PGP signature