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

[Max Nikulin]

On 24/01/2023 09:44, Thomas S. Dye wrote:

Max Nikulin writes:


I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests 
offset from UTC.


Not for a casual programmer like me. The timestamp alone might easily be 
read as 11 hours ahead of local time. Nevertheless, Org is certainly 
free to interpret it as relative to UTC.


My primary concern is that I might be wrong assuming that format like 
[2023-01-22 Sun 08:29@+1100] with offset in respect to UTC is reciprocal 
identity  mapping to UTC.


Of course there are a lot of people unaware of UTC. Org users may be 
educated by the manual and by hints in UI pushing toward time fixed in 
respect to UTC when "global" timestamp should be added. (In the sense of 
e.g. Lunar eclipse or an on-line meeting, not to confuse with set of 
events appointed on specific date but starting at the same local time in 
each location).


I am afraid of confusion with repeater intervals, but syntax has not 
fixed yet.


So we had different types of ambiguity in mind. Base time for offset was 
unclear for you, I was writing about mapping to UTC. Your point should 
be taken into account during consideration of storage format.


I still believe that something like [2023-01-21 Sat 21:29:00Z] and 
[2023-01-22 Sun 08:29@+1100] may be used to store timestamps 
interchangeably.


Are there local references that may confuse users? I mean something 
like 9 hours

ahead of Moscow (Asia/Kamchatka) used in USSR.


I think 9 hours ahead of a timezone with a potentially variable offset 
from UTC has the potential to sow confusion, yes.


If someone has examples of local time offsets (unrelated to UTC) widely 
used in some area, please, post them.


MSK+3 style was not a real issue because daylight saving time was active 
during the same period in the whole country and iron curtain was 
efficiently isolating most of people form variety of DST rules in other 
areas.

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

[Jean Louis]

* Max Nikulin  [2023-01-23 14:49]:
> I agree that linking mail messages and Org notes is important. On the other
> hand my impression is that the "mid:" URI protocol is not adopted wide
> enough by mail user agents yet, so it is too early to enable it by default
> in Org.

All URLs defined by Emacs that are to be run by browse-url in Org
shall be allowed by org, to let the Emacs settings pass through.

And not to hard code it in Org.

To circumvent hard coding in Org, one can always use elisp: type of links:

(defun my-handler (mid)
 (message mid))

[[elisp:(my-handler "I am ok here")][my handler]]

Though it is not logical to hard code in Org how this or that URL
can't be open, as Org should allow present configuration of user to
run. Is that currentlyy working?

> Configuring of "mid:" links requires just a few lines in init.el and they
> are quite usual for custom links.

I have configured it, it does not work in Org

--
Jean

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

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

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[General discussions about Org-mode.]

Philipp Kiefer  writes:

> Org mode version 9.6.1, GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
>
> Please see the two screenshots here for illustration:
>
> https://imgur.com/a/7EuUi0J
>
> (I'm assuming it's not a good idea - or not even possible - to send e-mail 
> attachments to the list?)
>
> This is the relevant code from my init.el that seems to be causing this issue:
>
> (require 'org-habit nil t) ; relevant?
> (defun org-add-my-extra-fonts ()
>   "Add alert and overdue fonts."
>   (add-to-list 'org-font-lock-extra-keywords 
> '("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" (1 '(face org-habit-alert-face invisible 
> nil)) (2 'org-habit-alert-face t) (3 '(face
> org-habit-alert-face invisible nil))) t)
>   (add-to-list 'org-font-lock-extra-keywords 
> '("\\(§\\)\\([^\n\r\t]+\\)\\(§\\)" (1 '(face org-habit-overdue-face invisible 
> nil)) (2 'org-habit-overdue-face t) (3
> '(face org-habit-overdue-face invisible nil))) t)
>   (add-to-list 'org-font-lock-extra-keywords 
> '("\\(@\\)\\([^\n\r\t]+\\)\\(@\\)" (1 '(face org-habit-clear-face invisible 
> nil)) (2 'org-habit-clear-face t) (3 '(face
> org-habit-clear-face invisible nil))) t))
> (add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-fonts)
>
> Can you reproduce it?
>
> Thanks!

I am in a region where imgur is unavailable -- can you attach a minimal
org file where the issue manifests, and briefly describe what happens
and should happen?

Also, while looking into your init code, I noticed that
`org-font-lock-extra-keywords' seems to be public-facing (as there is no
double-dashes in the name), but has no docstring.  Either this variable
was intended to be private, or someone forgot to put a docstring to this
variable.

Thoughts?

Best,


RY

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin  writes:


On 23/01/2023 23:04, Thomas S. Dye wrote:
I understand above that it is easier understandable when 
reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I 
guess Max)

that user will understand that there is +11 hours ahead.

Yes, the offset here is ambiguous--is it offset from some 
timezone or from

UTC?


Are you aware of usage base time other than UTC nowadays? My 
impression is that
various libraries do not allow to get such formats easily. That 
is why e.g. web
sites tends to present time in the server timezone (often not 
explicitly

specified) or use JavaScript to convert it to browser timezone.

I believed that [2023-01-22 Sun 08:29@+1100] unambiguously 
suggests offset from

UTC.


Not for a casual programmer like me. The timestamp alone might 
easily be read as 11 hours ahead of local time. Nevertheless, Org 
is certainly free to interpret it as relative to UTC.


Are there local references that may confuse users? I mean 
something like 9 hours

ahead of Moscow (Asia/Kamchatka) used in USSR.


I think 9 hours ahead of a timezone with a potentially variable 
offset from UTC has the potential to sow confusion, yes.


All the best,
Tom

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

[PATCH] lisp/org-agenda.el: Fix void-function string-pad in Emacs <28.1

[Aaron L. Zeng]

* org-compat.el (org-string-pad): Add compatibility function
`org-string-pad' for `string-pad', introduced in Emacs 28.1.

* org-agenda.el (org-fix-agenda-info): Use `org-string-pad' rather
than `string-pad'.

Since this is more-or-less just copying string-pad's definition from
subr-x.el, I think this qualifies for TINYCHANGE.

TINYCHANGE
---
 lisp/org-agenda.el |  4 ++--
 lisp/org-compat.el | 21 +
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 2d194ad34..4f0522086 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3474,13 +3474,13 @@ This ensures the export commands can easily use it."
 (when (setq tmp (plist-get props 'date))
   (when (integerp tmp) (setq tmp (calendar-gregorian-from-absolute tmp)))
   (let ((calendar-date-display-form
- '(year "-" (string-pad month 2 ?0 'left) "-" (string-pad day 2 ?0 
'left
+ '(year "-" (org-string-pad month 2 ?0 'left) "-" (org-string-pad 
day 2 ?0 'left
(setq tmp (calendar-date-string tmp)))
   (setq props (plist-put props 'date tmp)))
 (when (setq tmp (plist-get props 'day))
   (when (integerp tmp) (setq tmp (calendar-gregorian-from-absolute tmp)))
   (let ((calendar-date-display-form
- '(year "-" (string-pad month 2 ?0 'left) "-" (string-pad day 2 ?0 
'left
+ '(year "-" (org-string-pad month 2 ?0 'left) "-" (org-string-pad 
day 2 ?0 'left
(setq tmp (calendar-date-string tmp)))
   (setq props (plist-put props 'day tmp))
   (setq props (plist-put props 'agenda-day tmp)))
diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 6c5085255..eb20d5baf 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -173,6 +173,27 @@ removed."
   (string-trim (replace-regexp-in-string blank " " string t t)
blank blank
 
+(if (fboundp 'string-pad)
+(defalias 'org-string-pad #'string-pad)
+  ;; From Emacs subr-x.el.
+  (defun org-string-pad (string length  padding start)
+"Pad STRING to LENGTH using PADDING.
+If PADDING is nil, the space character is used.  If not nil, it
+should be a character.
+
+If STRING is longer than the absolute value of LENGTH, no padding
+is done.
+
+If START is nil (or not present), the padding is done to the end
+of the string, and if non-nil, padding is done to the start of
+the string."
+(unless (natnump length)
+  (signal 'wrong-type-argument (list 'natnump length)))
+(let ((pad-length (- length (length string
+  (cond ((<= pad-length 0) string)
+(start (concat (make-string pad-length (or padding ?\s)) string))
+(t (concat string (make-string pad-length (or padding ?\s
+
 (if (fboundp 'format-prompt)
 (defalias 'org-format-prompt #'format-prompt)
   ;; From Emacs minibuffer.el, inlining
-- 
2.38.1

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

[Max Nikulin]

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

I understand above that it is easier understandable when reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess Max)
that user will understand that there is +11 hours ahead.

Yes, the offset here is ambiguous--is it offset from some timezone or 
from UTC?


Are you aware of usage base time other than UTC nowadays? My impression 
is that various libraries do not allow to get such formats easily. That 
is why e.g. web sites tends to present time in the server timezone 
(often not explicitly specified) or use JavaScript to convert it to 
browser timezone.


I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests 
offset from UTC.


Are there local references that may confuse users? I mean something like 
9 hours ahead of Moscow (Asia/Kamchatka) used in USSR.

[Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

Org mode version 9.6.1, GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)

Please see the two screenshots here for illustration:

https://imgur.com/a/7EuUi0J 

(I'm assuming it's not a good idea - or not even possible - to send 
e-mail attachments to the list?)


This is the relevant code from my init.el that seems to be causing this 
issue:


(require 'org-habit nil t) ; relevant?
(defun org-add-my-extra-fonts ()
  "Add alert and overdue fonts."
  (add-to-list 'org-font-lock-extra-keywords 
'("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" (1 '(face org-habit-alert-face 
invisible nil)) (2 'org-habit-alert-face t) (3 '(face 
org-habit-alert-face invisible nil))) t)
  (add-to-list 'org-font-lock-extra-keywords 
'("\\(§\\)\\([^\n\r\t]+\\)\\(§\\)" (1 '(face org-habit-overdue-face 
invisible nil)) (2 'org-habit-overdue-face t) (3 '(face 
org-habit-overdue-face invisible nil))) t)
  (add-to-list 'org-font-lock-extra-keywords 
'("\\(@\\)\\([^\n\r\t]+\\)\\(@\\)" (1 '(face org-habit-clear-face 
invisible nil)) (2 'org-habit-clear-face t) (3 '(face 
org-habit-clear-face invisible nil))) t))

(add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-fonts)

Can you reproduce it?

Thanks!

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

[Edgar Lux]

On Jan 23, 2023 at 12:06 PM, Ihor Radchenko  wrote:Edgar 
Lux  writes:
> So, what is the problem with LATEX_HEADER approach?

I thought that it would be preferable to have a native Org syntax.

> I do not like passing the options as-is in #+cite_export because not all
> the possible biblatex \usepackage options are affecting the
> bibliography. Options like sortcites, maxcitenames, autocite, etc are
> only affecting the citation style, not the bibliography. And options
> like bibencoding are totally irrelevant to both citation and
> bibliography styles.

That's fair, but it can just as well be used as a line to configure biblatex 
(since it is already being used anyway). Besides, there are many other options 
which do concern the style or are very needed 
(hyperref=true,backref=true,url=true,backend=biber,natbib=true). I'm not 
advocating for my suggestion, just showing my reasoning. As I said, I'm fine 
with the =#+latex_header:=.

> > 1. case
> >#+begin_src org
> >  #+cite_export: biblatex "how/much"
> >#+end_src
> >
> >the result is
> >#+begin_src latex
> >  \usepackage[bibstyle=how,citestyle=much]{biblatex}
> >#+end_src
>
> This is actually confusing.
> This code is by Nicolas, but does not seem to be consistent with the
> idea of "BIBLIOGRAPHY STYLE".
>
> I am CCing him in cause if there is something I am missing.

The docstring says:

;; "cite_export" keyword.  If you need to use different styles for 
bibliography
;; and citations, you can separate them with "bibstyle/citestyle" syntax.  
E.g.,
;;
;;   #+cite_export: biblatex authortitle/authortitle-ibid

> This is plain abusing.
> We might remove the "/" matching completely and throw an error if there
> are commas inside style name. Users must not rely on such undocumented
> behavior.

Let the user decide (?). If she gets to that point, she surely knows how to 
(ab)use it--in her favour.

> whether some of these are broken is up for discussion. The suggested patch
adds one conditional case, which searches for ="syle="=, takes away the
brackets and turns the above cases into:

[I do not see any patch attached]

WTF... again! (sorry)

diff --git a/lisp/oc-biblatex.el b/lisp/oc-biblatex.el
index a27f9e9bf..3e912f2d9 100644
--- a/lisp/oc-biblatex.el
+++ b/lisp/oc-biblatex.el
@@ -99,6 +99,10 @@ Return a string."
 (style-options
  (cond
   ((null style) nil)
+  ((string-match "style=" style)
+   (list (replace-regexp-in-string
+  "\\(style=[^/]*\\)/" "\\1,citestyle="
+  (org-unbracket-string "[" "]" style
   ((not (string-match "/" style)) (list (concat "style=" style)))
   (t
(list (concat "bibstyle=" (substring style nil (match-beginning 
0)))

> Why not storing email locally? Account limits are non-issue then ;)

The server does not allow me to download e-mails! (free as in... half a beer. I 
can get the full beer if I pay for it, though). Thanks for the suggestion.


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

Re: Feature request: "task table" (similar to clock table)

[Marcin Borkowski]

On 2023-01-03, at 19:29, Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
>> I see.  I think I'll go another route then - in fact, I already started,
>> see https://mbork.pl/2023-01-02_Computing_Org_mode_TODO_stats :-)
>
> That will also work.
>
> But why `plist-get' + `org-element-at-point-no-context'?
>
> You can instead use `org-element-property' + `org-element-at-point'.
> `org-element-property' will be resilient against internal AST
> representation changes and `org-element-at-point' will make use of
> caching.

FYI: here is my finished code:

https://mbork.pl/2023-01-09_TODO_stats_table
https://mbork.pl/2023-01-23_TODO_stats_table_with_parameters

Thanks,

-- 
Marcin Borkowski
http://mbork.pl

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

[Tim Cross]

I just wanted to provide some additional information which RMS may find
informative.

Under the hood, ob-sql.el is using the built-in Emacs sql.el library. It
is this library which provides the 'support' for various SQL database
engines. That support has been part of the sql library since it was
added to Emacs in about 1998.

The 'support' is essentially specialised comint based interfaces tweaked
to work with the various SQL database engine command line clients such
as psql for Postgres and sqlplus for Oracle. This involves codes to use
the comint buffer to send commands/regions to the SQL client and read
back the results and run interactive 'repl' like sessions with the
client.

No additional software is installed by either ob-sql.el or sql.el - it
is all just elisp. Any additional software, such as the database client,
must be installed separately by the user (clients on remote machines can
also be used via ssh).

There are no jar files or any other additional bits of software
installed.

There is also some additional support in the form of font-locking which
includes support for different SQL variants i.e. in addition to ANSI
SQL, you can also specify Postgres SQL, Oracle SQL, MS-SQL etc to get
font-locking which supports some of the keyword differences between the
different SQL engines.

Personally, I don't believe any of this contravenes FSF
guidelines. Neither sql.el or ob-sql.el are encouraging use of any
specific database engine. What these libraries do is in fact allow
those who do want to use free software and avenue for interacting with
these systems using free software rather than on-free (similar to Emacs'
WIndows and Mac support).

The software as a service issue is far more difficult to assess when it
comes to databases as the most common architecture with databases is to
have the database on a separate server which is often not local and
where frequently, the user has little or no control over the
software. This has become even more common in recent years due to the
growth in big data and the problem that most individuals and small
groups cannot afford the costs or handle the administrative complexity
associated with hosting databases with large data sets and storage
requirements.

Ihor Radchenko  writes:

> Richard Stallman  writes:
>
>>   > > Because we already support Orcale, SAP Hana, MSSql and Vertico for 
>> example.
>>
>> Would someone please tell me more concretely what kind of "support"
>> this is? Which GNU package supports them, and how?  
>
> [Jean Luis mentioned M-x sql-* commands in another message. They may
> also be worth discussing, but are not what I meant in the original
> message]
>
> ob-sql is Org mode's feature (part of Emacs) allowing users to execute
> SQL code inline inside Org files:
>
> #+header: :engine sqlite
> #+header: :database ~/.local/share/qutebrowser/history.sqlite
>
> #+begin_src sql
>   SELECT URL FROM History ORDER BY "URL" DESC LIMIT 5 
> #+end_src
>
> #+RESULTS:
> | qute://help/commands.html |
> | qute://help/commands.html |
> | qute://help/  |
> | qute://help   |
> | qute://   |
>
> Note the :engine argument. It determines which CLI backend is being
> called by Org mode to query the database.
>
> ;; Engines supported:
> ;; - mysql
> ;; - dbi
> ;; - mssql
> ;; - sqsh
> ;; - postgresql (postgres)
> ;; - oracle
> ;; - vertica
> ;; - saphana
>
> Some of these engines are free software and we have no issue supporting
> them. Some are not.
>
>> ... Also, what kind
>> of things are those?  Are they nonfree programs, or are they SaaSS?
>> Some of them I recognize as nonfree programs, but some names I don't
>> recognize at all.
>
> At least, mssql is non-free with no source code available. Same for
> oracle, vertica, and saphana.
>
> I am not sure about SaaSS - even postgresql (free software) may be used
> as a service provider by running it on server the user does not control.
> Probably, I do not fully understand how SaaSS is defined (I did read
> https://www.gnu.org/philosophy/who-does-that-server-really-serve.html)
>
> Earlier in the thread, https://github.com/dbcli/athenacli was proposed
> as another CLI to support. Athenacli itself is distributed under BSD-3 -
> free license. However, the CLI is just an interface to Amazon Athena -
> server-side database service.
>
> From my limited understanding, the main purpose of Amazon Athena is
> querying "big data" databases for further analysis, which does not
> constitute SaaSS (AFAIU) - users may not own the "big data" and may not
> have enough resources on their own computers to run the SQL queries that
> utilize machine learning models.
>
>> There are situations where it is acceptable for a GNU package to
>> support its use together with certain nonfree programs.  Mainly when
>> the nonfree program so well known that this support mainly encourage
>> people who already use that nonfree program to start using the GNU
>> package with it, and is unlikely to do the 

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

[Jean Louis]

* AW  [2023-01-23 16:58]:
> Am Montag, 23. Januar 2023, 11:40:24 CET schrieb Ihor Radchenko:
> > AW  writes:
> > >> We could support mid: is the corresponding url schema existed and
> > >> supported by various OSes.
> > > 
> > > Isn't this rather important? How many users of orgmode get TODOs via
> > > E-Mail
> > > and need an efficient way to come back from the TODO to its origin?
> > 
> > It is not up to Org. Try
> > 
> >  (browse-url "mid:3218434.44cspzl...@linux.fritz.box")
> > 
> > You will likely see nothing.
> 
> Well, M-x  (browse-url "mid:3218434.44cspzl...@linux.fritz.box") 
> produces [No match].

By default no match, but as already said, that depends of your
settings. 

It works on my side as I have settings for that. 

In Emacs it is up to user to set how to open it.

Same as with any Internet browser, when you try to use less used URLs,
then you will see browser is asking you by which application to open
it, if to remember that application and so on.

For example magnet: could be opened by Deluge or other torrent
applications, depending of user settings in browser.

There are too many applications and hard coding how to open message ID
would be limitation, not feature.

You may cutomize variable `browse-url-handlers' to get what you wish.

Its value is
(("gemini:" . elpher-go)
 ("gopher:" . elpher-handler-go)
 ("about:" . hyperscope-about)
 ("hyperscope:" . hyperscope-url)
 ("e2dk://" . amule-handler))




--
Jean

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

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

Re: [PATCH] Fix some emacs-30 byte-compile warnings

[Robert Pluim]

> On Mon, 23 Jan 2023 14:04:42 +, Ihor Radchenko  
> said:

Ihor> Robert Pluim  writes:
>> The emacs 30 byte-compiler warns about uses of `eq'
>> and similar with constant strings which might have unintended
>> semantics. Patch is against emacs master.

Ihor> Thanks, but it will break some tests:

Ihor> 3 unexpected results:
Ihor>FAILED  test-org-table/copy-field
Ihor>FAILED  test-org-table/references/mode-string-N
Ihor>FAILED  test-org-table/references/mode-string-none

Hmm, at least the first one is because the code in the 't' branch of
(if (and (eq elements "") (not keep-empty))

in org-table-make-reference now runs, and it results in

(eval '(identity))'

Of course fixing that causes other problems 

Iʼll get back to this maybe tomorrow.

Robert
-- 

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

[Thomas S. Dye]

Aloha Jean Louis,
Jean Louis  writes:


* Thomas S. Dye  [2023-01-22 20:36]:
> After all, for a person in Berlin [2023-01-22 Sun 
> 08:29@+1100] may

> tell more than [2023-01-22 Sun 08:29@Australia/Sydney].

I'm not sure to follow this.  IIUC, the timestamp with offset 
refers to
absolute time, whereas the timestamp with the Australia/Sydney 
timezone
refers to a region of space/time whose relation to absolute 
time is fixed

for any moment, but potentially variable over time.


I understand above that it is easier understandable when reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess 
Max)

that user will understand that there is +11 hours ahead.

Yes, the offset here is ambiguous--is it offset from some timezone 
or from UTC?



That is assumption by poster. I do not find it easier.

As when user sees 08:29 that user will think of time in Berlin, 
of

time which is not in UTC, and not time in UTC plus 11 hours.

What is easier is what is generally accepted in any type of 
software

worldwide, just represent it in local time zone.

Difference between offset time and time with time zone is that 
time

zone includes rules of daylight savings and other anomalies.


Right.  The difficulty with scheduling is that it has to take into 
account two time zones in some cases.


Here is a proposal for a terminology of events that honors 
Ramsey's distinction between events and occurrences and hopes to 
cover all of Org's use cases.


* Kinds of event
- No-host event :: An event that takes place at an absolute time. 
Participants must know their local timezone offset from UTC. 
Example [2023-01-23 06:00@UTC].
- Situated event :: An event that takes place at a time local to 
the event site.  Participants must know their local timezone 
offset from UTC and the event site timezone offset from UTC at 
the time of the event.  Example [2023-01-22 Sun 
08:29@Australia/Sydney].
- [Itinerant | Traveling | Mobile] event :: An event that takes 
place at a time local to the event site, which might change after 
the event has been scheduled.  Participants must know their local 
timezone offset from UTC and the event site timezone offset from 
UTC at the time of the event.  Examples might be a regular staff 
meeting that takes place at 9:00 AM wherever the boss happens to 
be, or a proposal to meet with a traveler when it is noon on 
Sunday for the traveler. Example [2023-01-23 06:00].  In this 
case timezone is set according to user timezone preference in 
scope.


The Org user should be able to toggle timestamp representation. 
In the case of a no-host event, user might toggle between UTC and 
local time.  In the case of situated or itinerant event, user 
might toggle among UTC, local time, and local time at the event 
site.


WDYT?

All the best,
Tom

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

[PATCH] Provide a uniform way to inform users about missing third-party packages

[Ihor Radchenko]

Hi,

In Org code, we have various places where we depend (optionally) on
third-party packages. The packages are typically loaded using `require'
and report the usual error about missing library if the third-party
package is not installed.

Such situation is _almost_ OK, except some scenarios when the feature
name we in `require' is not the same with the actual package name.
Inexperienced users may easily be confused by such errors.

In the attached patch, I am introducing a new macro that can be used
instead of `require' as the following:

(org-require-package 'skewer-repl "skewer-mode")

The macro calls `require' and if it fails, displays error/warning saying

"`this-command' failed to load required package \"package name\""

It will assist users about the actual third-party package name to be
installed.

WDYT?

While writing a patch, I also noticed
`org-cite-csl--barf-without-citeproc' doing similar job.
Should we just use the new macro instead?

Also, https://github.com/bard/mozrepl ob-js backend is no longer
supported. I am wondering if we should remove it.

>From 0140976d32f6fef3c2e2fa181f210dbd026008fe Mon Sep 17 00:00:00 2001
Message-Id: <0140976d32f6fef3c2e2fa181f210dbd026008fe.1674486794.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 23 Jan 2023 18:06:46 +0300
Subject: [PATCH] Provide a uniform way to inform users about missing
 third-party packages

* lisp/org-macs.el (org-require-package): New macro trying to load a
library and displaying custom error message or warning on failure.
The actual package (not library) name can be provided as optional
argument.

* lisp/ob-R.el (org-babel-R-initiate-session):
* lisp/ob-clojure.el (ob-clojure-eval-with-inf-clojure):
(ob-clojure-eval-with-cider):
(ob-clojure-eval-with-slime):
* lisp/ob-forth.el (org-babel-forth-session-execute):
* lisp/ob-gnuplot.el (org-babel-execute:gnuplot):
(org-babel-gnuplot-initiate-session):
* lisp/ob-haskell.el (org-babel-interpret-haskell):
(org-babel-haskell-initiate-session):
* lisp/ob-js.el (org-babel-execute:js):
(org-babel-js-initiate-session):
* lisp/ob-julia.el (org-babel-julia-initiate-session):
* lisp/ob-lisp.el (org-babel-execute:lisp):
* lisp/ob-ocaml.el (org-babel-prep-session:ocaml):
* lisp/ob-octave.el (org-babel-octave-initiate-session):
* lisp/ob-processing.el (org-babel-processing-view-sketch):
* lisp/ob-ruby.el (org-babel-execute:ruby):
(org-babel-ruby-initiate-session):
* lisp/ol-bbdb.el (org-bbdb-open):
(org-bbdb-complete-link):
(org-bbdb-anniv-export-ical):
* lisp/org-agenda.el:
* lisp/org-plot.el (org-plot/gnuplot):
* lisp/org.el:
* lisp/ox-ascii.el (org-ascii-table):
* lisp/ox-html.el (org-html-htmlize-generate-css):
* lisp/ox-org.el: Use the new macro.

* lisp/oc-csl.el: Add FIXME. oc-csl uses a custom function doing
similar job.

* lisp/ob-js.el (org-babel-js-initiate-session): Add FIXME noting that
the third-party package is outdated.
---
 lisp/ob-R.el  |  2 +-
 lisp/ob-clojure.el|  9 +++--
 lisp/ob-forth.el  |  2 +-
 lisp/ob-gnuplot.el|  4 ++--
 lisp/ob-haskell.el|  4 ++--
 lisp/ob-js.el | 10 ++
 lisp/ob-julia.el  |  3 ++-
 lisp/ob-lisp.el   |  6 +++---
 lisp/ob-ocaml.el  |  2 +-
 lisp/ob-octave.el |  6 --
 lisp/ob-processing.el |  2 +-
 lisp/ob-ruby.el   |  4 ++--
 lisp/oc-csl.el|  1 +
 lisp/ol-bbdb.el   |  8 
 lisp/org-agenda.el|  3 +--
 lisp/org-macs.el  |  9 +
 lisp/org-plot.el  |  2 +-
 lisp/org.el   |  2 +-
 lisp/ox-ascii.el  |  2 +-
 lisp/ox-html.el   |  3 +--
 lisp/ox-org.el|  3 +--
 21 files changed, 48 insertions(+), 39 deletions(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 4ee091118..2d22a4657 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -276,7 +276,7 @@ (defun org-babel-R-initiate-session (session params)
 	  (when (get-buffer session)
 	;; Session buffer exists, but with dead process
 	(set-buffer session))
-	  (require 'ess) (R)
+  (org-require-package 'ess "ESS") (R)
 	  (let ((R-proc (get-process (or ess-local-process-name
 	 ess-current-process-name
 	(while (process-get R-proc 'callbacks)
diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index d993e0cb7..5f589db00 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -186,8 +186,7 @@ (defvar comint-prompt-regexp)
 (defvar inf-clojure-comint-prompt-regexp)
 (defun ob-clojure-eval-with-inf-clojure (expanded params)
   "Evaluate EXPANDED code block with PARAMS using inf-clojure."
-  (condition-case nil (require 'inf-clojure)
-(user-error "inf-clojure not available"))
+  (org-require-package 'inf-clojure)
   ;; Maybe initiate the inf-clojure session
   (unless (and inf-clojure-buffer
 	   (buffer-live-p (get-buffer inf-clojure-buffer)))
@@ -228,8 +227,7 @@ (defun ob-clojure-eval-with-inf-clojure (expanded params)
 
 (defun ob-clojure-eval-with-cider (expanded params)
   "Evaluate EXPANDED code block with PARAMS using cider."
-  (condition-case 

Re: org-crypt fails if default key is expired while non-default key is to be used

[Karl Voit]

Hi Ihor,

* Ihor Radchenko  wrote:
> Karl Voit  writes:
>
>> When I invoked org-decrypt-entry, decrypting works like always. Then
>> I modified something in this heading which is tagged with :crypt:.
>> On saving that buffer, org-crypt issues an error message:
>>
>> | Error: (error "GPG error: \"Encrypt failed\", \"Unusable public key:
>> | A1234567; Exit\"")
>>
>> This A1234567 key is my default key and not the org-openpgp-key.
>>
>> org-encrypt-entry is causing this error at:
>>
>> |;; Text and key have to be identical, otherwise we
>> |;; re-crypt.
>> |(if (and (equal crypt-key key)
>> | (string= checksum (sha1 contents)))
>> |(get-text-property 0 'org-crypt-text contents)
>> |  (epg-encrypt-string epg-context contents crypt-key)))
>>
>> After fixing the expiry date of A1234567, org-crypt was working
>> properly, using the correct org-openpgp-key again.
>>
>> I do think this is wrong behavior: when the default key is expired
>> but a specific secondary key is used, encryption should be possible.
>
> All we do here is calling `epg-encrypt-string' with crypt key obtained
> using `org-crypt-key-for-heading', which see.
>
> May I know how exactly did you set `org-crypt-key'? Do you happen to
> have CRYPTKEY properties somewhere in your buffer?

Sure. My config is on
https://github.com/novoid/dot-emacs/blob/master/config.org and I've
set it with:

(setq org-crypt-key "ABC12345")  ;; I may have to mask this online as well ;-)

: grep -i CRYPTKEY *
... is empty when applied to my Org-mode files.

The only thing to fix my situation was to re-import a non-expired
version of my default OpenPGP sec key.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

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

[AW]

Am Montag, 23. Januar 2023, 14:59:12 CET schrieb AW:
> But I'll write an E-Mail to the
> developers of kmail.


https://bugs.kde.org/show_bug.cgi?id=464695

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

[AW]

Am Montag, 23. Januar 2023, 12:46:38 CET schrieb Max Nikulin:
> On 23/01/2023 01:47, AW wrote:
> >> We could support mid: is the corresponding url schema existed and
> >> supported by various OSes.
> > 
> > Isn't this rather important? How many users of orgmode get TODOs via
> > E-Mail
> > and need an efficient way to come back from the TODO to its origin?
> 
> I agree that linking mail messages and Org notes is important. On the
> other hand my impression is that the "mid:" URI protocol is not adopted
> wide enough by mail user agents yet, so it is too early to enable it by
> default in Org.
> 
> Configuring of "mid:" links requires just a few lines in init.el and
> they are quite usual for custom links.
> 
> Alexander, you have tried 2 mail application and it seems neither of
> them supports "mid:" links out of the box. Notmuch looks almost ready,
> it needs just a .desktop file and configuring `browse-url-handlers' on
> activation. Have you checked if kmail bug tracker has a feature request
> for "mid:" links? I am not sure that KDE bug trackers are indexed by
> search engines.

I have done that now without result. But I'll write an E-Mail to the 
developers of kmail. 
> 
>  From the blog post by Karl Voit I have an impression that developers of
> Evolution do not follow RFC since posted command example contains angle
> brackets (mid:<...@...>). Such format causes "not found" error in
> Thunderbird.
> 
> On 23/01/2023 17:40, Ihor Radchenko wrote:
> > I am not even sure if we need to make Org open mid: links via
> > `browse-url'. Maybe it should be something else? IDK.
> 
> Do you know an alternative? Org already uses this package to open some
> types of links. It allows to have the same handler for all Emacs
> packages. I do not think that Org-specific handler would be better.

As long as notmuch, notmuch.el and ol-notmuch are there we have a viable 
solution, thanks to this (undocumented) trick with notmuch:id:123abc, after 
getting the id by opening the mail with notmuch in emacs and »c I«. 

Thank you for your time and effort!

-- 
Regards,
Alexander

Re: [PATCH] Fix some emacs-30 byte-compile warnings

[Ihor Radchenko]

Robert Pluim  writes:

> The emacs 30 byte-compiler warns about uses of `eq'
> and similar with constant strings which might have unintended
> semantics. Patch is against emacs master.

Thanks, but it will break some tests:

3 unexpected results:
   FAILED  test-org-table/copy-field
   FAILED  test-org-table/references/mode-string-N
   FAILED  test-org-table/references/mode-string-none

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

[PATCH] Fix some emacs-30 byte-compile warnings

[Robert Pluim]

The emacs 30 byte-compiler warns about uses of `eq'
and similar with constant strings which might have unintended
semantics. Patch is against emacs master.

-- >8 --
* lisp/org/ob-octave.el (org-babel-octave-evaluate-session): Use
`delete' instead of `delq' when deleting a constant string.
* lisp/org/org-agenda.el (org-agenda-format-item): Use `string=' when
comparing to a constant string.
* lisp/org/org-element.el (org-element-cache-map): Use `equal' when
comparing to a constant list.
* lisp/org/org-table.el (org-table-make-reference): Use `string=' when
comparing to a constant string.
---
diff --git c/lisp/org/ob-octave.el i/lisp/org/ob-octave.el
index 9bf16b9849..e411961e92 100644
--- c/lisp/org/ob-octave.el
+++ i/lisp/org/ob-octave.el
@@ -243,7 +243,7 @@ org-babel-octave-evaluate-session
   (`output
(setq results
 (if matlabp
-(cdr (reverse (delq "" (mapcar #'org-strip-quotes
+(cdr (reverse (delete "" (mapcar #'org-strip-quotes
(mapcar #'org-trim raw)
   (cdr (member org-babel-octave-eoe-output
(reverse (mapcar #'org-strip-quotes
diff --git c/lisp/org/org-agenda.el i/lisp/org/org-agenda.el
index 2d194ad341..b0587d5d92 100644
--- c/lisp/org/org-agenda.el
+++ i/lisp/org/org-agenda.el
@@ -7326,7 +7326,7 @@ org-agenda-format-item
  (let ((s (org-format-outline-path 
(org-get-outline-path)
(1- 
(frame-width))
nil 
org-agenda-breadcrumbs-separator)))
-   (if (eq "" s) "" (concat s 
org-agenda-breadcrumbs-separator))
+   (if (string= "" s) "" (concat s 
org-agenda-breadcrumbs-separator))
(setq time (cond (s2 (concat
  (org-agenda-time-of-day-to-ampm-maybe s1)
  "-" (org-agenda-time-of-day-to-ampm-maybe s2)
diff --git c/lisp/org/org-element.el i/lisp/org/org-element.el
index 389acf8250..e427966f57 100644
--- c/lisp/org/org-element.el
+++ i/lisp/org/org-element.el
@@ -7558,7 +7558,7 @@ org-element-cache-map
  ;; beginning.
  (next-element-re (pcase granularity
 ((or `headline
- (guard (eq '(headline)
+ (guard (equal '(headline)
 restrict-elements)))
  (cons
   (org-with-limited-levels
@@ -7566,7 +7566,7 @@ org-element-cache-map
   'match-beg))
 (`headline+inlinetask
  (cons
-  (if (eq '(inlinetask) restrict-elements)
+  (if (equal '(inlinetask) 
restrict-elements)
   (org-inlinetask-outline-regexp)
 org-element-headline-re)
   'match-beg))
diff --git c/lisp/org/org-table.el i/lisp/org/org-table.el
index 5116b1127f..fbfdc253f9 100644
--- c/lisp/org/org-table.el
+++ i/lisp/org/org-table.el
@@ -2861,7 +2861,7 @@ org-table-make-reference
   (if lispp
  (if (eq lispp 'literal)
  elements
-   (if (and (eq elements "") (not keep-empty))
+   (if (and (string= elements "") (not keep-empty))
""
  (prin1-to-string
   (if numbers (string-to-number elements) elements

Robert
-- 

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

[AW]

Am Montag, 23. Januar 2023, 11:40:24 CET schrieb Ihor Radchenko:
> AW  writes:
> >> We could support mid: is the corresponding url schema existed and
> >> supported by various OSes.
> > 
> > Isn't this rather important? How many users of orgmode get TODOs via
> > E-Mail
> > and need an efficient way to come back from the TODO to its origin?
> 
> It is not up to Org. Try
> 
>  (browse-url "mid:3218434.44cspzl...@linux.fritz.box")
> 
> You will likely see nothing.

Well, M-x  (browse-url "mid:3218434.44cspzl...@linux.fritz.box") 
produces [No match].
> 
> So, while Org may provide some limited help with mid:, as Max suggested,
> there is no way to guarantee that mid: links will work for all users
> without users hand-customizing how to open emails.
> 
> I am not even sure if we need to make Org open mid: links via
> `browse-url'. Maybe it should be something else? IDK.

This is weird since ever. I've been talking to some collegues and everybody 
has his/her own special approach. Mostly producing a PDF from the E-Mail and 
saving this and its attachments somewhere. That's a thing that bothered me for 
decades. 

-- 
Regards,

Alexander

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

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> Here is the plan to resolve this issue:
>>
>> 1. We update the manual allowing src blocks to have empty language spec
>
> See the attached patch.

Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d98ca046cc7633dd9c06236d1221e97c876795f5
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=77a1cfb9a4c7e62e5c5bcf81fe2c74090caea37a

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

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

[Ihor Radchenko]

Richard Stallman  writes:

>   > > Because we already support Orcale, SAP Hana, MSSql and Vertico for 
> example.
>
> Would someone please tell me more concretely what kind of "support"
> this is? Which GNU package supports them, and how?  

[Jean Luis mentioned M-x sql-* commands in another message. They may
also be worth discussing, but are not what I meant in the original
message]

ob-sql is Org mode's feature (part of Emacs) allowing users to execute
SQL code inline inside Org files:

#+header: :engine sqlite
#+header: :database ~/.local/share/qutebrowser/history.sqlite
#+begin_src sql
  SELECT URL FROM History ORDER BY "URL" DESC LIMIT 5 
#+end_src

#+RESULTS:
| qute://help/commands.html |
| qute://help/commands.html |
| qute://help/  |
| qute://help   |
| qute://   |

Note the :engine argument. It determines which CLI backend is being
called by Org mode to query the database.

;; Engines supported:
;; - mysql
;; - dbi
;; - mssql
;; - sqsh
;; - postgresql (postgres)
;; - oracle
;; - vertica
;; - saphana

Some of these engines are free software and we have no issue supporting
them. Some are not.

> ... Also, what kind
> of things are those?  Are they nonfree programs, or are they SaaSS?
> Some of them I recognize as nonfree programs, but some names I don't
> recognize at all.

At least, mssql is non-free with no source code available. Same for
oracle, vertica, and saphana.

I am not sure about SaaSS - even postgresql (free software) may be used
as a service provider by running it on server the user does not control.
Probably, I do not fully understand how SaaSS is defined (I did read
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html)

Earlier in the thread, https://github.com/dbcli/athenacli was proposed
as another CLI to support. Athenacli itself is distributed under BSD-3 -
free license. However, the CLI is just an interface to Amazon Athena -
server-side database service.

>From my limited understanding, the main purpose of Amazon Athena is
querying "big data" databases for further analysis, which does not
constitute SaaSS (AFAIU) - users may not own the "big data" and may not
have enough resources on their own computers to run the SQL queries that
utilize machine learning models.

> There are situations where it is acceptable for a GNU package to
> support its use together with certain nonfree programs.  Mainly when
> the nonfree program so well known that this support mainly encourage
> people who already use that nonfree program to start using the GNU
> package with it, and is unlikely to do the converse.
>
> See the GNU Maintainers Guide for more details.

It is hard to define "well known". For me, oracle and mssql databases
are well-known (just by company name), while saphana and vertica are
not. But I do not work with SQL and thus lack expertise about what is
being used in reality. How to judge?

> However, use with a SaaSS system (service as a software substitute) is
> a different issue (though it has much in common).  I'd like to think
> about it and ask advisors for advice.  These details can help me start
> to think about it.

I feel very confused about possible guidelines for SaaSS.

SaaSS does not always require specific CLI tools to be used.
Consider common HTTP requests or GraphQL that might be employed to
communicate with SaaSS. Should we stop supporting HTTP requests just
because they can be used to communicate with SaaSS? Probably no.
What about something more specific like the ability to query remote
database provided by SaaSS service? One may just need login/password +
free sql implementation. What if it is not SELECT query, but INSERT
query sharing the data with SaaSS? What about the history of SELECT
queries being associated with the user and the sold to third-party? What
if external free CLI tool is needed? non-free CLI? There should probably
be a boundary somewhere, but it is not clear where it should lie.

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

[Max Nikulin]

On 23/01/2023 01:47, AW wrote:

We could support mid: is the corresponding url schema existed and
supported by various OSes.

Isn't this rather important? How many users of orgmode get TODOs via E-Mail
and need an efficient way to come back from the TODO to its origin?


I agree that linking mail messages and Org notes is important. On the 
other hand my impression is that the "mid:" URI protocol is not adopted 
wide enough by mail user agents yet, so it is too early to enable it by 
default in Org.


Configuring of "mid:" links requires just a few lines in init.el and 
they are quite usual for custom links.


Alexander, you have tried 2 mail application and it seems neither of 
them supports "mid:" links out of the box. Notmuch looks almost ready, 
it needs just a .desktop file and configuring `browse-url-handlers' on 
activation. Have you checked if kmail bug tracker has a feature request 
for "mid:" links? I am not sure that KDE bug trackers are indexed by 
search engines.


From the blog post by Karl Voit I have an impression that developers of 
Evolution do not follow RFC since posted command example contains angle 
brackets (mid:<...@...>). Such format causes "not found" error in 
Thunderbird.


On 23/01/2023 17:40, Ihor Radchenko wrote:

I am not even sure if we need to make Org open mid: links via
`browse-url'. Maybe it should be something else? IDK.


Do you know an alternative? Org already uses this package to open some 
types of links. It allows to have the same handler for all Emacs 
packages. I do not think that Org-specific handler would be better.

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

[Ihor Radchenko]

Matt  writes:

>   On Fri, 20 Jan 2023 04:27:18 -0500  Ihor Radchenko  wrote --- 
>  > I think `org-babel--shell-command-on-region' will be more appropriate.
>  > Because similar issues might appear when attempting to evaluate other
>  > code blocks on Windows, where `shell-file-name' is set to cmdproxy.exe.
>  > 
>  > It will also be useful to leave a comment in the code explaining why we
>  > need this newline.
>
> Works for me.  
>
> How should I update bugfix to match main?  Since we're considering
> this a bug, I figured I'd do this on bugfix.

bugfix is only for trivial and critical bugs.
Non-trivial yet non-critical should not be on bugfix.
They are for the next minor release.
See https://orgmode.org/worg/org-maintenance.html#branches

> I notice, however, that bugfix doesn't have the latest updates to 
> test-ob-shell.  When I rebase main onto bugfix I get a ton of conflicts.  If 
> I instead merge main into bugfix, that shows many merge commits with bugfix.  
> Since I don't see any "Merge with 'bugfix'" commits on bugfix currently, I 
> assume that's not the way to do it.

You must not merge main onto bugfix.
Such merge is called release :)

Can you fix the bug on bugfix? If yes, do it on bugfix and then merge
bugfix onto main. If no, just fix it on main - this appears to be an old
bug that existed for a long time, and we may as well postpone it to the
next minor release and not risk breaking bugfix branch with non-trivial
changes.

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

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

[Ihor Radchenko]

Jack Kamm  writes:

> Ihor Radchenko  writes:
>
>> Marked for future removal in ob-python.el.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=21741a469
>
> Thanks Ihor.
>
> Not sure if it's too early for this, but I've prepared a patch to remove
> the support for python-mode.el, attached.

main branch is for Org 9.7. So, removing it should happen before the
next Org 9.7 release on main anyway. I have no objections on this.

> Also, to help any python-mode users with the transition, I ported the
> code to support python-mode to an external package here:
>
> https://gitlab.com/jackkamm/ob-python-mode-mode
>
> As always, feedback is welcome, either on this patch or the external
> package.

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

> Subject: [PATCH] ob-python: Remove python-mode.el support
>
> * lisp/ob-python.el (org-babel-python-mode): Remove customization
> variable.

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.

> (org-babel-python-send-string): Renamed from
> org-babel-python--send-string, turning it into a public function to
> accommodate ob-python-mode-mode which advises this function. Also,
> remove some code for python-mode.el

Note that we usually `quote' Elisp symbols in the commit messages.

Otherwise, the patch looks good.

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

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

[Ihor Radchenko]

Edgar Lux  writes:

>> > #+cite_export: biblatex "bibstyle=numeric-comp,sorting=none, 
>> > hyperref=true,backref=true,url=true,backend=biber,natbib=true"
>>
>> The general design is
>> #+cite_export: NAME BIBLIOGRAPHY-STYLE CITATION-STYLE
>> ... removed content ...
>> I am not sure how your idea fits the above.
>
> The general design only allows two options (and their values) to be passed to 
> =biblatex= (in the =#+cite_export:= line): =bibstyle= and =citestyle=. 
> However, =biblatex= can take many more options. Currently (correct me if I am 
> wrong), the two alternatives to pass more options is to use a 
> =org-cite-biblatex-options= or a line like this
>
> #+begin_src org
>   ,#+LaTeX_HEADER: \usepackage[bibstyle=numeric-comp,sorting=none, 
> hyperref=true,backref=true,url=true,backend=biber,natbib=true]{biblatex}
> #+end_src

So, what is the problem with LATEX_HEADER approach?

I do not like passing the options as-is in #+cite_export because not all
the possible biblatex \usepackage options are affecting the
bibliography. Options like sortcites, maxcitenames, autocite, etc are
only affecting the citation style, not the bibliography. And options
like bibencoding are totally irrelevant to both citation and
bibliography styles.

>> However, only certain options are considered.
>> After applying your patch, things may be broken in this area.
>
> One of the attachments showed what I considered to be all possible cases: the 
> new string (containing =style==; it could be either =bibstyle==, 
> =citestyle==. It is similar to the case which allows for 
> ="bibstyle/citestyle"=, as documented on line 34 of =oc-biblatex.el=). 
> Currently (these could, hopefully, also be used for the documentation), if 
> somebody uses
>
> 1. case
>#+begin_src org
>  #+cite_export: biblatex "how/much"
>#+end_src
>
>the result is
>#+begin_src latex
>  \usepackage[bibstyle=how,citestyle=much]{biblatex}
>#+end_src

This is actually confusing.
This code is by Nicolas, but does not seem to be consistent with the
idea of "BIBLIOGRAPHY STYLE".

I am CCing him in cause if there is something I am missing.

> 3. case
>#+begin_src org
>  #+cite_export: biblatex "how,opt=true"
>#+end_src
>
>the result is
>#+begin_src latex
>  \usepackage[style=how,opt=true]{biblatex}
>#+end_src

> 4. case
>#+begin_src org
>  #+cite_export: biblatex "how/much,hack=true"
>#+end_src
>
>the result is
>#+begin_src latex
>  \usepackage[bibstyle=how,citestyle=much,hack=true]{biblatex}
>#+end_src

This is an implementation detail. We cannot promise such things working
reliably.

> 5. case
>#+begin_src org
>  #+cite_export: biblatex "citestyle=corner/much"
>#+end_src
>
>the result is
>#+begin_src latex
>  \usepackage[bibstyle=citestyle=corner,citestyle=much]{biblatex}
>#+end_src
>
> 6. case
>#+begin_src org
>  #+cite_export: biblatex "citestyle=corner/much,opt=true"
>#+end_src
> ...

This is plain abusing.
We might remove the "/" matching completely and throw an error if there
are commas inside style name. Users must not rely on such undocumented
behavior.

> whether some of these are broken is up for discussion. The suggested patch 
> adds one conditional case, which searches for ="syle="=, takes away the 
> brackets and turns the above cases into:

[I do not see any patch attached]

> Sure. I hope that the code above suffices :) . I compress, because I don't 
> have unlimited space in my account.

Why not storing email locally? Account limits are non-issue then ;)

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

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

[Ihor Radchenko]

Edgar Lux  writes:

> Just in case, I think that you meant #+bind: . However, it didn't work for me 
> (I'm blaming myself). I added this in line 16 of my 324-lines file
>
> #+bind: org-cite-biblatex-options "opt=true"
>
> but the =opt=true= value is not shown next to =\usepackage{biblatex}= when I 
> export. I do have =org-export-allow-bind-keywords= set to =t=

13.2 Export Settings
   If ‘org-export-allow-bind-keywords’ is non-‘nil’, Emacs variables can
become buffer-local during export by using the ‘BIND’ keyword.  Its
syntax is ‘#+BIND: variable value’.  This is particularly useful for
in-buffer settings that cannot be changed using keywords.


#+BIND is ignored by default for safety reasons.

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

[Ihor Radchenko]

AW  writes:

>> We could support mid: is the corresponding url schema existed and
>> supported by various OSes.
>
> Isn't this rather important? How many users of orgmode get TODOs via E-Mail 
> and need an efficient way to come back from the TODO to its origin?

It is not up to Org. Try

 (browse-url "mid:3218434.44cspzl...@linux.fritz.box") 

You will likely see nothing.

So, while Org may provide some limited help with mid:, as Max suggested,
there is no way to guarantee that mid: links will work for all users
without users hand-customizing how to open emails.

I am not even sure if we need to make Org open mid: links via
`browse-url'. Maybe it should be something else? IDK.

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

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> So, the test failure is real.
>
> The error buffer contents when the test fails is the following:
>
> warning: using the gnuplot graphics toolkit is discouraged
> ...
> [ Babel evaluation exited with code 0 ]
>
> Exit code is 0, so octave does finish.
>
> Hence, test assertion that
> (should-not (buffer-live-p (get-buffer "*Org-Babel Error Output*")))
> does not appear to be accurate.
>
> Leo, should we simply remove the assertion?

I decided to remove the assertion from the tests.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=59228e51345ab522d9db611c8e73caa078d86d2f

While there could be a value in making sure that ob-octave calls octave
without generating errors, it is not strictly what the test is checking
for.

Moreover, we currently have no reliable way to disambiguate mere
warnings from non-zero exit code.

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

Re: org-crypt fails if default key is expired while non-default key is to be used

[Ihor Radchenko]

Karl Voit  writes:

> When I invoked org-decrypt-entry, decrypting works like always. Then
> I modified something in this heading which is tagged with :crypt:.
> On saving that buffer, org-crypt issues an error message:
>
> | Error: (error "GPG error: \"Encrypt failed\", \"Unusable public key:
> | A1234567; Exit\"")
>
> This A1234567 key is my default key and not the org-openpgp-key.
>
> org-encrypt-entry is causing this error at:
>
> | ;; Text and key have to be identical, otherwise we
> | ;; re-crypt.
> | (if (and (equal crypt-key key)
> |  (string= checksum (sha1 contents)))
> | (get-text-property 0 'org-crypt-text contents)
> |   (epg-encrypt-string epg-context contents crypt-key)))
>
> After fixing the expiry date of A1234567, org-crypt was working
> properly, using the correct org-openpgp-key again.
>
> I do think this is wrong behavior: when the default key is expired
> but a specific secondary key is used, encryption should be possible.

All we do here is calling `epg-encrypt-string' with crypt key obtained
using `org-crypt-key-for-heading', which see.

May I know how exactly did you set `org-crypt-key'? Do you happen to
have CRYPTKEY properties somewhere in your buffer?

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