Re: [PATCH] Don't fill displayed equations

[Tom Gillespie]

Some thoughts.

> Maybe you are right and Tom was actually assuming \begin{equation*}, not
> #+begin_export latex.

Correct. My bad on that one.

> Just as Timothy, I believe that \begin{equation*} is unnecessary verbose
> when \[ works *mostly* in a similar way.

\begin{equation*} is absolutely required if you want to be able to include
newlines because \[ and \begin are not similar at all as far as parsing
is concerned.

>From the spec: https://orgmode.org/worg/dev/org-syntax.html#LaTeX_Environments
> CONTENTS can contain anything but the “\end{NAME}” string.
The spec is not completely accurate since latex environments can't
contain a new heading, but the point is that latex environments are
elements, whereas \[ \] is an object.

> If I understand correctly, making \[ \] available outside paragraph
> would mean that it becomes a new element (currently \[\] is a
> latex-fragment object).

Correct. Promoting \[ to an element would mean every \ in an org file
becomes a stop word. Also, Since full fledged latex environments
already exist to serve this purpose I find it hard to justify, especially
given that Org tries to give clear indication of when a block structure
is starting and ending.

> Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$,
> and \begin{env} ... \end{env} and constructs in Org to be consistent
> with LaTeX?

For \begin and \end yes. For the others no. In general it would be to
make it possible to express things using latex-like syntax that would
otherwise require Org to come up with some new and different syntax.
These are values that may be translated to latex, but they exist inside
a larger syntax that is decidedly not latex, and thus they only have
meaningful translation to latex if they exist as well formed Org.

As a side note, the $ syntax is slated to be deprecated and removed.
https://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments
> It would introduce incompatibilities with previous Org versions, but
> support for $...$ (and for symmetry, $$...$$) constructs ought to be removed.

> Indeed, it will be a breaking change.

I'm actually fairly certain that such a change should never be made
due to the recent changes in org link syntax. Specifically given how
\[ is used for escapes in links. https://orgmode.org/manual/Link-Format.html
This means that the only place you could reliably use \[ is at the start of a
new line preceded only by whitespace. However, if this were to happen then
pretty much every org document that uses \[ \] is at risk for being broken
because something that was once a single paragraph will now be multiple
paragraphs.

If you need multiline use \begin \end, that is what they are there for, and they
fit better with org's general extensible approach to blocks. I would dearly love
to be able to have a single shorthand for src blocks that worked inline and
standalone, but the complexity that it would induce is just not worth it. Same
thing for \[ \]. It seems simple until you get down to account for all the edge
that it would induce in the grammar.

Consider the case where you have something like

\[ something something

more content
more content [[www.example.com/\]oops][evil link]] \]

I've seen enough cases that are similar to this in the existing implementation
that have inconsistent behavior that I can safely say that this one would too.
Not to mention that I can think of at least 3 different cases that will all have
slightly different behavior that is inexplicable to users at best and
infuriating
at worst.

\[ a

b \]

\[
a
b
\]

a \[ b

c \] d

etc. There are plenty more variants that would all be subtly different depending
on the exact way such a thing were implemented.

In short. Just not worth it.

Re: Feature request: in org html export, option to disable id & class properties.

[Tim Cross]

Zachary Kanfer  writes:

> Sure, I'm generally interested in making this useful. Weird that it claims to 
> be part of org, but isn't.
>
> I do think it would be useful to have a minimalist html exporter in org, 
> whether slimhtml or some other one. The built-in html
> exporter is rather opinionated.
>

I tend to agree. Although this would be difficult to achieve now because
of the impact it would have on end users, I think the best architecture
for org would be for ALL exporters to be basic 'no thrills' exporters
and more advanced, opinionated or specialised exporters provided as
external ELPA or NONGNUE ELPA add ons which are not part of the core
architecture. Org maintenance could then just focus on core
functionality and an API which make implementing extensions/add-ons
easier.

I also agree with Bastien that adding a second HTML exporter as part of
the core is likely to lead to confusion and additional maintenance.
Probably what is needed is a new HTML exporter which is capable of doing
what slimhtml does as the default, but includes the additional
functionality already in the exporter which many people are using.

Getting this right is definitely a non-trivial problem. 

Re: Feature request: in org html export, option to disable id & class properties.

[Zachary Kanfer]

Sure, I'm generally interested in making this useful. Weird that it claims
to be part of org, but isn't.

I do think it would be useful to have a minimalist html exporter in org,
whether slimhtml or some other one. The built-in html exporter is rather
opinionated.

On Sun, Oct 3, 2021, 11:57 AM Amin Bandali  wrote:

> Hi Zachary,
>
> Zachary Kanfer writes:
>
> > That is an interesting exporter. Is it actually part of orgmode? I don't
> > see it in the org repository. I don't want to rely on downloading
> something
> > from an archived repository that won't get bugfixes.
>
> Indeed, ox-slimhtml is not part of Org at the moment, but I'm hoping
> it can be.  I'm trying to revive discussion about it on this list,
> if you'd be interested in following and/or chiming in.
>
> --
> https://bndl.org
>

Re: Org mode web site

[Timothy]

Hi Thomas,

> I’m seeing what looks like a spurious headline:   Elaboration + demo image
> ignore

Thanks, that is indeed spurious. “ignore” is the tag :ignore: but it seems like
the ox-extra that makes :ignore: work isn’t being loaded any more.

All the best,
Timothy

Re: Grabbing the link to a message on the archive

[Jorge P . de Morais Neto]

Hi

Em [2021-10-03 dom 21:20:12-0300], Jorge P. de Morais Neto escreveu:

> In this snippet you call ~cond~ with three arguments, but it takes only
> two.

I meant ~cons~, not ~cond~.

-- 
- Many people hate injustice but few check the facts.  This provokes
  misinformation.  Ask me about 
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

Re: Grabbing the link to a message on the archive

[Jorge P . de Morais Neto]

Hi Timothy,

Em [2021-09-30 qui 13:18:44+0800], Timothy escreveu:

> If you use mu4e, the following may be of some interest:
> ┌
> │ (defun +mu4e-ml-message-link (msg)
> │   (cond
> │((string= "emacs-orgmode.gnu.org" (mu4e-message-field msg :mailing-list))
> │ (message "Link %s copied to clipboard" (gui-select-text (format 
> "https://list.orgmode.org/%s; (mu4e-message-field msg :message-id)
> │(t (user-error "Mailing list %s not supported" (mu4e-message-field msg 
> :mailing-list)
> │ (add-to-list 'mu4e-view-actions (cons "link to message ML" 
> #'+mu4e-ml-message-link t))
> └

In this snippet you call ~cond~ with three arguments, but it takes only
two.

Regards

-- 
- Many people hate injustice but few check the facts.  This provokes
  misinformation.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.

Org mode web site

[Thomas S. Dye]

Aloha all,

I'm seeing what looks like a spurious headline:   Elaboration + 
demo image   ignore


All the best,
Tom

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

Re: Citation in footnote not expanded/exported to LaTeX (using Org-ref-cite)

[Nicolas Goaziou]

Hello,

Elias Bounatirou  writes:

> Just to clarify the BUG:
> Citations in a footnote in the following environment are not exported to
> LaTeX: when the footnote follows two or more citations, of which one has a
> suffix, i.e. for instance in
>
> Body text with a citation: [cite:@low2001; @mcneill2011 with a
> suffix][fn:3].

I cannot reproduce the problem. With the following document:

--8<---cut here---start->8---
#+bibliography: foo.bibtex
#+cite_export: biblatex authoryear

Body text with a citation: [cite:@foo; @bar with a suffix][fn:1].

* Footnotes

[fn:1] Test 
--8<---cut here---end--->8---

I get,

--8<---cut here---start->8---
Body text with a citation: \autocites{foo}[][with a suffix]{bar}\footnote{Test}.
--8<---cut here---end--->8---

If I write

--8<---cut here---start->8---
Body text with a citation: [cite:@foo; @bar; with a suffix][fn:1].
--8<---cut here---end--->8---

instead, I get

--8<---cut here---start->8---
Body text with a citation: \autocites(with a 
suffix){foo}[][]{bar}\footnote{Test}.
--8<---cut here---end--->8---

Both seem correct.

Regards,
-- 
Nicolas Goaziou

Re: Spurious spaces with oc-biblatex

[Nicolas Goaziou]

Hello,

Denis Maier  writes:

> Elias and I have run into an potential bug in oc-biblatex:
>
> ==
> #+cite_export: biblatex authoryear
>
> [cite:@doe] => ok
>
> ([cite:@doe]) => this generates a space between the opening
> parentheses and the citation.
> ==
>
> Result:
>
> 
> \autocite{doe}
>
> ( \autocite{doe}) => this generates a space between the opening
> parentheses and the citation.
> =

Fixed.

Thank you.

Regards,
-- 
Nicolas Goaziou

Re: "Unknown processor biblatex"

[autofrettage]

> Note the thread I posted a day or two ago /.../

Thanks I will, and I will also try to remember to search the mail
archives the next time around.

Yours
Rasmus

Re: "Unknown processor biblatex"

[Bruce D'Arcus]

On Sun, Oct 3, 2021 at 4:57 PM autofrettage  wrote:
>
> Hi all,
>
> I have really seen forward to the release of org mode 9.5 with
> its new and shiny support for citations. The initial frenzy of
> experimentation has lead to mixed results.
>
> Right now I am trying to use the biblatex processor, but I only
> get "Unknown processor biblatex". How is that even possible, when
> that should be one of the processors provided by org mode 9.5?
>
> Are there more packages, like citeproc.el, on which org-cite
> depends, and I have to install manually? Is there some mandatory
> set-up I have failed to notice?
>
> I have tried to read
> https://blog.tecosaur.com/tmio/2021-07-31-citations.html
> and the manual page for the citations, but I am at my wits' end
> now.
>
> Any pointer would be appreciated.

You have to load oc-biblatex, say using use-package, and also set
org-cite-export-processors, like:

(setq org-cite-export-processors
'((latex biblatex)
(t csl)))

Note the thread I posted a day or two ago requesting feedback on what
to add to the manual. We know it needs work.

Bruce

"Unknown processor biblatex"

[autofrettage]

Hi all,

I have really seen forward to the release of org mode 9.5 with
its new and shiny support for citations. The initial frenzy of
experimentation has lead to mixed results.

Right now I am trying to use the biblatex processor, but I only
get "Unknown processor biblatex". How is that even possible, when
that should be one of the processors provided by org mode 9.5?

Are there more packages, like citeproc.el, on which org-cite
depends, and I have to install manually? Is there some mandatory
set-up I have failed to notice?

I have tried to read
https://blog.tecosaur.com/tmio/2021-07-31-citations.html
and the manual page for the citations, but I am at my wits' end
now.

Any pointer would be appreciated.

Yours
Rasmus

Debbugs Usage

[Daniel Fleischer]

Hi, is debbugs org-mode being used?

-- 

Daniel Fleischer

Best way to include METAPOST in ConTeXt exporter

[Jason Ross]

Hello,

I'd like to include METAPOST figures in the ConTeXt exporter backend I'm
developing. However, I don't know of an idiomatic way to add captions and
references for the figures.

Currently, I export METAPOST with `#+BEGIN_EXPORT metapost` / `#+END_EXPORT`
tags. However, this feature seems to be intended for completely "raw"
outputs
with no markup or tagging in the resulting export. I'm interested in
supporting
at least `#+NAME` and `#+CAPTION` keywords for METAPOST figures so that they
can be referred to in the Org file and also in the exported pdf.

What are some better ways of doing something like this? Source blocks? How
would
a user expect to use a feature like this?

Thanks,

Jason

[PATCH] org-manual.org: List the languages supported by smart quotes feature

[Juan Manuel Macías]

Hi,

I think a footnote with a list of (currently) supported languages could
be helpful for users who want to apply this feature.

Best regards,

Juan Manuel

>From 26f799a5a53b35f7f3e6e3df10689855832dbebd Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sun, 3 Oct 2021 19:11:48 +0200
Subject: [PATCH] org-manual.org: List the languages supported by smart quotes
 feature

* doc/org-manual.org (Export Settings): A footnote is added.
---
 doc/org-manual.org | 159 +++--
 1 file changed, 82 insertions(+), 77 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b25da7889..195ed1d46 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11637,9 +11637,9 @@ following arguments.
 
   #+vindex: org-export-with-smart-quotes
   Toggle smart quotes (~org-export-with-smart-quotes~).  Depending on
-  the language used, when activated, Org treats pairs of double quotes
-  as primary quotes, pairs of single quotes as secondary quotes, and
-  single quote marks as apostrophes.
+  the language used[fn:124], when activated, Org treats pairs of
+  double quotes as primary quotes, pairs of single quotes as secondary
+  quotes, and single quote marks as apostrophes.
 
 - ~*~ ::
 
@@ -11869,7 +11869,7 @@ keyword:
 #+cindex: excluding entries from table of contents
 #+cindex: table of contents, exclude entries
 Org includes both numbered and unnumbered headlines in the table of
-contents[fn:124].  If you need to exclude an unnumbered headline,
+contents[fn:125].  If you need to exclude an unnumbered headline,
 along with all its children, set the =UNNUMBERED= property to =notoc=
 value.
 
@@ -11988,7 +11988,7 @@ be omitted to use the obvious defaults.
 | =#+INCLUDE: "~/.emacs" :lines "10-"=  | Include lines from 10 to EOF   |
 
 Inclusions may specify a file-link to extract an object matched by
-~org-link-search~[fn:125] (see [[*Search Options in File Links]]).  The
+~org-link-search~[fn:126] (see [[*Search Options in File Links]]).  The
 ranges for =:lines= keyword are relative to the requested element.
 Therefore,
 
@@ -12028,7 +12028,7 @@ following syntax:
 : #+MACRO: name   replacement text; $1, $2 are arguments
 
 #+texinfo: @noindent
-which can be referenced using ={{{name(arg1, arg2)}}}=[fn:126].  For
+which can be referenced using ={{{name(arg1, arg2)}}}=[fn:127].  For
 example
 
 #+begin_example
@@ -12147,7 +12147,7 @@ are not exported.
 Finally, a =COMMENT= keyword at the beginning of an entry, but after
 any other keyword or priority cookie, comments out the entire subtree.
 In this case, the subtree is not exported and no code block within it
-is executed either[fn:127].  The command below helps changing the
+is executed either[fn:128].  The command below helps changing the
 comment status of a headline.
 
 - {{{kbd(C-c ;)}}} (~org-toggle-comment~) ::
@@ -12419,7 +12419,7 @@ should in principle be exportable as a Beamer presentation.
 
 - Org exports a Beamer frame's objects as block environments.  Org can
   enforce wrapping in special block types when =BEAMER_ENV= property
-  is set[fn:128].  For valid values see
+  is set[fn:129].  For valid values see
   ~org-beamer-environments-default~.  To add more values, see
   ~org-beamer-environments-extra~.
   #+vindex: org-beamer-environments-default
@@ -13007,7 +13007,7 @@ as-is.
 #+vindex: org-html-mathjax-options~
 LaTeX math snippets (see [[*LaTeX fragments]]) can be displayed in two
 different ways on HTML pages.  The default is to use the [[https://www.mathjax.org][MathJax]],
-which should work out of the box with Org[fn:129][fn:130].  Some MathJax
+which should work out of the box with Org[fn:130][fn:131].  Some MathJax
 display options can be configured via ~org-html-mathjax-options~, or
 in the buffer.  For example, with the following settings,
 
@@ -13019,7 +13019,7 @@ in the buffer.  For example, with the following settings,
 #+texinfo: @noindent
 equation labels are displayed on the left margin and equations are
 five em from the left margin.  In addition, it loads the two MathJax
-extensions =cancel.js= and =noErrors.js=[fn:131].
+extensions =cancel.js= and =noErrors.js=[fn:132].
 
 #+vindex: org-html-mathjax-template
 See the docstring of ~org-html-mathjax-options~ for all supported
@@ -13082,7 +13082,7 @@ line.
 #+vindex: org-export-html-todo-kwd-class-prefix
 #+vindex: org-export-html-tag-class-prefix
 You can modify the CSS style definitions for the exported file.  The
-HTML exporter assigns the following special CSS classes[fn:132] to
+HTML exporter assigns the following special CSS classes[fn:133] to
 appropriate parts of the document---your style specifications may
 change these, in addition to any of the standard classes like for
 headlines, tables, etc.
@@ -13319,7 +13319,7 @@ LaTeX export back-end finds the compiler version to use from
 Org file.  See the docstring for the
 ~org-latex-default-packages-alist~ for loading packages with certain
 compilers.  Also see 

Re: ox-slimhtml

[Bastien]

Hi Amin,

Amin Bandali  writes:

> Bastien, would you and Nicolas be open to adding ox-slimhtml more or
> less in its current form to Org core, if Laszlo, myself, and/or others
> look after it and help maintain it?

No, because it would be confusing to have two HTML export backends in
Org's core.

BTW, https://github.com/balddotcat/ox-slimhtml says "slimhtml is now
part of Org, included in GNU Emacs, future bug reports or
contributions should be sent to Org directly" ... which is wrong, and
I can't fill a bug report because the repo is archived.

Elo, are you still working on it?

>From what I've read in previous discussions, I believe I'm in line
with Nicolas and Tim on this: we can probably enhance ox-html.el by
following some design goals that ox-slimhtml.el have set, and leave
other decisions aside, because ox-html has to stay as generic as
possible.

In any case, I'd rather have Elo work with Tim on enhancing ox-html
than to allow another package in Org's core.

If ox-slimhtml is still maintained, it can for sure live in GNU or
NonGNU ELPA.

WDYT?

-- 
 Bastien

Re: [BUG] 502/slow response from new repo [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

Hi,

Amin Bandali  writes:

> Indeed.  For future cases, if the issue remains after, say, 30mins,
> please come by the #savannah channel on the Libera.Chat IRC network,
> or open a support request in 'administration'[1] project on Savannah
> to alert the Savannah hackers of the issue; we'll be happy to help.
>
> [1]: https://savannah.nongnu.org/projects/administration

Also you can try to reach out savannah-hackers-pub...@gnu.org or
savannah-us...@gnu.org.

-- 
 Bastien

Re: 9.5: coping with loss of ditaa.jar

[Colin Baxter]

> Arne Babenhauserheide  writes:

> Max Nikulin  writes:

>> On 03/10/2021 11:25, Jarmo Hurri wrote:
>>> I use ditaa with org on a regular basis. Now that ditaa.jar is
>>> out of org 9.5, I need to cope with the situtation.  I see two
>>> options, and neither was successful today. This is sort of what
>>> I was afraid of when I voted for keeping ditaa bundled with org.
>>> 1. I am running Fedora 34, where ditaa is available as a
>>> package. However, just pointing org-ditaa-jar-path to the
>>> correct location /usr/share/java/ditaa.jar is not sufficient,
>>> because doing so leads to errors when trying to execute a ditaa
>>> babel block:
>> 
>> I am not a ditaa user currently, but generally it should be the
>> preferred option. I have not looked into ob-ditaa.el however to
>> realize if it has enough defcustom options.

> A short-term quickfix could be to copy the jar from an older
> orgmode and point to that.

Indeed. That works for me.

Best wishes,

Colin Baxter


signature.asc
Description: PGP signature

Re: Cannot clone org-mode's git repository

[Colin Baxter]

> Colin Baxter  writes:

> Hello, I get a strange error when I try to clone org-mode:

> redknight@jetstar:~/git$ git clone
> https://git.savannah.gnu.org/git/emacs/org-mode.git Cloning into
> 'org-mode'...  fatal: unable to access
> 'https://git.savannah.gnu.org/git/emacs/org-mode.git/': server
> certificate verification failed. CAfile:
> /etc/ssl/certs/ca-certificates.crt CRLfile: none

> There seems to be nothing wrong with my git. I can pull other
> emacs. auctex, etc. with no problems.

I tried again a couple of hours later and succeeded in cloning
org-mode. I have no idea what the error was and how it occurred. It
might have had something to do with the fact I was attempting to clone
in a remote host to which I had ssh'd, but that's just a guess.

Thanks to everyone who took the time to offer suggestions, which I have
made notes in case it happens again.

Sorry Timothy, a copy of this post emailed to you will probably get
trashed by google. Google seems to regard yandex.com as the source of all
evil and will not accept email from that host - or more accurately from
my email a/c at that host.

Thanks again.

Best wishes,

Colin Baxter.

Re: 9.5: coping with loss of ditaa.jar

[Dr. Arne Babenhauserheide]

Max Nikulin  writes:

> On 03/10/2021 11:25, Jarmo Hurri wrote:
>> I use ditaa with org on a regular basis. Now that ditaa.jar is out
>> of
>> org 9.5, I need to cope with the situtation.
>> I see two options, and neither was successful today. This is sort of
>> what I was afraid of when I voted for keeping ditaa bundled with org.
>> 1. I am running Fedora 34, where ditaa is available as a
>> package. However, just pointing org-ditaa-jar-path to the correct
>> location /usr/share/java/ditaa.jar is not sufficient, because doing
>> so leads to errors when trying to execute a ditaa babel block:
>
> I am not a ditaa user currently, but generally it should be the
> preferred option. I have not looked into ob-ditaa.el however to
> realize if it has enough defcustom options.

A short-term quickfix could be to copy the jar from an older orgmode and
point to that.

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


signature.asc
Description: PGP signature

Re: Cannot clone org-mode's git repository

[Thomas S. Dye]

Aloha,

Amin Bandali  writes:


Hello,

Colin Baxter writes:


Hello,

I get a strange error when I try to clone org-mode:

redknight@jetstar:~/git$ git clone 
https://git.savannah.gnu.org/git/emacs/org-mode.git

Cloning into 'org-mode'...
fatal: unable to access 
'https://git.savannah.gnu.org/git/emacs/org-mode.git/': server 
certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt CRLfile: none


This looks like part of the fallout of the recent expiry of one 
of

Let's Encrypt's root certificates.  See:
https://savannah.nongnu.org/support/?110546
https://letsencrypt.org/2021/10/01/cert-chaining-help.html

What GNU/Linux distro are you using?  Try updating your packages 
--

particularly ca-certificates and packages like openssl, gnutls,
libssl, etc. -- and see if it helps.  If not, you can read more 
on
the topic in recent articles around the web, and apply one of 
the

suggested workarounds.


Updating ca-certificates worked for me on Ubuntu.

All the best,
Tom

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

[PATCH] org-manual.org: Update links to MathJax docs

[Max Nikulin]

On 03/10/2021 19:19, Max Nikulin wrote:


https://orgmode.org/manual/Math-formatting-in-HTML-export.html


(131)

Please note that exported formulas are part of an HTML document, and
that signs such as ‘<’, ‘>’, or ‘&’ have special meanings. See MathJax
TeX and LaTeX support.


The link is broken however.

http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters 


Usually, it is sufficient simply to put spaces around these symbols to
cause the browser to avoid them, so

... when $x < y$ we have ...


Though I am a bit surprised that Org did not replace characters to  
and  during export. Perhaps, it is possible to define a filter.


Let's fix at least the link. Old one gives 404 error.

P.S. Curiously outside of math snippets "<>" are properly exported to 
""


>From be815b1476b5119db6c83363e1c7b2034b692ca6 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Sun, 3 Oct 2021 23:12:11 +0700
Subject: [PATCH] org-manual.org: Update links to MathJax docs

* doc/org-manual.org (Footnotes): Fix links to particular sections in
MathJax manual.

Scheme is not changed to https: since the site prefers http:

curl -I https://docs.mathjax.org/
HTTP/2 302
date: Sun, 03 Oct 2021 16:04:15 GMT
location: http://docs.mathjax.org/en/latest/
---
 doc/org-manual.org | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b25da7889..52306caa6 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -22121,9 +22121,9 @@ semantic relevance.
 
 [fn:130] Please note that exported formulas are part of an HTML
 document, and that signs such as =<=, =>=, or =&= have special
-meanings.  See [[http://docs.mathjax.org/en/latest/tex.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX support]].
+meanings.  See [[http://docs.mathjax.org/en/latest/input/tex/html.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX in HTML documents]].
 
-[fn:131] See [[http://docs.mathjax.org/en/latest/tex.html#tex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn
+[fn:131] See [[http://docs.mathjax.org/en/latest/input/tex/extensions.html#tex-and-latex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn
 about extensions.
 
 [fn:132] If the classes on TODO keywords and tags lead to conflicts,
-- 
2.25.1

Re: ox-slimhtml

[Timothy]

Hi Amin,

> What do you (other folks also) think?

A while ago Nicolas forwarded me an email between him and Laszlo on this. Here
are my thoughts at the time addresses to Laszlo (which haven’t changed much 
since):

Nicolas  writes:
> IIUC, merge is only viable if “ox-slimhtml” is a drop-in replacement for
> “ox-html”. Otherwise, users will miss out many features. Of course, we
> could ship two competing HTML export back-ends, but I don’t think that’s
> a good idea either.
>
> So, it is meant for inclusion in Org proper, or as a GNU ELPA package?
> I don’t know. Maybe Timothy has a clearer view about it.

I believe I see your motivation in creating ox-slimhtml, as the current
ox-html includes much more than could be considered strictly necessary.

However, like Nicolas I am hesitant to put this straight into Org along
side ox-html. My personal view is that ideally ox-html would be equipped
with the relevant knobs and levers (metaphorically speaking) such that
one could obtain the same result as ox-slimhtml, the current result, or
something in-between. I’ve felt for some time that ox-html could benefit
from a bit more in-built flexibility without going down the path of
hooks, filters, and advice. This would certainly be more effort, so I
completely understand if this isn’t something you’d like to undertake.
In that case, I feel that this may be best suited as an ELPA package —
closely in reach for those who are looking for a slimmer ox-html.

All the best,
Timothy

Re: Feature request: in org html export, option to disable id & class properties.

[Amin Bandali]

Hi Zachary,

Zachary Kanfer writes:

> That is an interesting exporter. Is it actually part of orgmode? I don't
> see it in the org repository. I don't want to rely on downloading something
> from an archived repository that won't get bugfixes.

Indeed, ox-slimhtml is not part of Org at the moment, but I'm hoping
it can be.  I'm trying to revive discussion about it on this list,
if you'd be interested in following and/or chiming in.

-- 
https://bndl.org

Re: Unable to follow gnus links

[Tom Ed White]

Ihor Radchenko  writes:

> Tom Ed White  writes:
>
>> Following gnus links in org fails with the message:
>>
>> funcall: Wrong number of arguments: ((t) (path _) "Follow the Gnus
>> message or folder link specified by PATH." (if (string-match
>> "\\`\\([^#]+\\)\\(#\\(.*\\)\\)?" path) nil (error "Error in Gnus link
>> %S" path)) (let ((group (match-string-no-properties 1 path)) (article
>> (match-string-no-properties 3 path))) (org-gnus-follow-link group
>> article))), 1
>
> This should not happen.  Do you open the link using org-link-open?  Can
> you share backtrace after M-x debug-on-entry org-gnus-open?
>
> Best,
> Ihor

I was able to fix the problem for the time being by changing the
arguments to:

(defun org-gnus-open (path  _)

The keystroke I use is C-c C-o, which runs org-open-at-point which is in
org.el.

Regards,
Tom Ed White

Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1)
  org-gnus-open("nnmaildir+Old 
Fiddlebike:Inbox#caj6zs8+tp6gvgckvqa-e1-5cdkfqsnkg8gm69o8emu1zyq5...@mail.gmail.com")
  funcall(org-gnus-open "nnmaildir+Old 
Fiddlebike:Inbox#caj6zs8+tp6gvgckvqa-e1-5cdkfqsnkg8gm69o8emu1zyq5...@mail.gmail.com")
  (cond ((equal type "file") (if (string-match "[*?{]" (file-name-nondirectory 
path)) (dired path) (let* ((option (org-element-property :search-option link)) 
(app (org-element-property :application link)) (dedicated-function 
(org-link-get-parameter (if app ... type) :follow))) (if dedicated-function 
(funcall dedicated-function (concat path (and option ...))) (apply 
#'org-open-file path (cond (arg) (... ...) (... ...)) (cond (... nil) (... ...) 
(t ...))) ((functionp (org-link-get-parameter type :follow)) (funcall 
(org-link-get-parameter type :follow) path)) ((member type '("coderef" 
"custom-id" "fuzzy" "radio")) (if (run-hook-with-args-until-success 
'org-open-link-functions path) nil (if (not arg) (org-mark-ring-push) 
(switch-to-buffer-other-window (org-link--buffer-for-internals))) (let 
((destination (save-excursion (save-restriction ... ... ... (if (and (<= 
(point-min) destination) (>= (point-max) destination)) nil (widen)) (goto-char 
destination (t (browse-url-at-point)))
  (let ((type (org-element-property :type link)) (path (org-element-property 
:path link))) (cond ((equal type "file") (if (string-match "[*?{]" 
(file-name-nondirectory path)) (dired path) (let* ((option 
(org-element-property :search-option link)) (app (org-element-property 
:application link)) (dedicated-function (org-link-get-parameter ... :follow))) 
(if dedicated-function (funcall dedicated-function (concat path ...)) (apply 
#'org-open-file path (cond ... ... ...) (cond ... ... ...)) ((functionp 
(org-link-get-parameter type :follow)) (funcall (org-link-get-parameter type 
:follow) path)) ((member type '("coderef" "custom-id" "fuzzy" "radio")) (if 
(run-hook-with-args-until-success 'org-open-link-functions path) nil (if (not 
arg) (org-mark-ring-push) (switch-to-buffer-other-window 
(org-link--buffer-for-internals))) (let ((destination (save-excursion ...))) 
(if (and (<= ... destination) (>= ... destination)) nil (widen)) (goto-char 
destination (t (browse-url-at-point
  org-link-open((link (:type "gnus" :path "nnmaildir+Old 
Fiddlebike:Inbox#CAJ6ZS8+TP6gVGckVQA..." :format bracket :raw-link 
"gnus:nnmaildir+Old Fiddlebike:Inbox#CAJ6ZS8+TP6gVG..." :application nil 
:search-option nil :begin 19723 :end 19880 :contents-begin 19829 :contents-end 
19878 :post-blank 0 :parent (headline (:raw-value "Debug gnus org links
[[gnus:nnmaildir+Old Fiddl..." :begin 19691 :end 19882 :pre-blank 0 
:contents-begin nil :contents-end nil :level 2 :priority nil :tags nil 
:todo-keyword #("TODO" 0 4 (face org-todo org-category "personal" fontified t)) 
:todo-type todo :post-blank 1 :footnote-section-p nil :archivedp nil 
:commentedp nil :post-affiliated 19691 :title "Debug gnus org links
[[gnus:nnmaildir+Old Fiddl..." nil)
  org-open-at-point(nil)
  funcall-interactively(org-open-at-point nil)
  call-interactively(org-open-at-point nil nil)
  command-execute(org-open-at-point)

Re: ox-slimhtml

[Amin Bandali]

Hi Bastien, Laszlo, Nicolas,

Bastien Guerry writes:

> Hi Laszlo,
>
> Bastien  writes:
>
>> I encourage everyone to try exporting Org documents to HTML using your
>> library and see how it compares with ox-html.el for a daily usage.
>
> nobody seemed to be that interested in helping :/

Apologies for completely dropping the ball on this.  It's been beyond
hectic around me the past few months, and I essentially had zero time
to work on this and several other projects I've been interested in.

Bastien, would you and Nicolas be open to adding ox-slimhtml more or
less in its current form to Org core, if Laszlo, myself, and/or others
look after it and help maintain it?  I still believe that ox-slimhtml
can stand on its own -- compared to other export backends, it's quite
small in size, and has no external dependencies -- coexisting with
ox-html and a useful alternative to ox-html for exporting Org files
into more lightweight html files, as well as for when finer control
over the exported html is desired.

What do you (other folks also) think?

> I hope you were able to continue working on this, don't hesitate to
> send an update.
>
> In the meantime, I'm dismissing this thread from the "calls for help"
> on https://updates.orgmode.org
>
>

Would you mind if I (or yourself) restore that status on Woof?

thanks,
amin

-- 
https://bndl.org

[PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Hi all,

I'm attaching a patch with a proposal to unify in a single constant
(named `org-latex-language-alist')
`org-latex-polyglossia-language-alist' and
`org-latex-babel-language-alist', along with some necessary (minor)
modifications in `org-latex-guess-polyglossia-language' and
`org-latex-guess-babel-language'

The new list, which is not exhaustive, is built taking as a reference
the documentation of Babel and Polyglossia in their latest versions
within TeX live 2021. It also assumes the latest improvements in the
babel package (on the current state of the art regarding the babel and
polyglossia packages, see this previous thread:
https://list.orgmode.org/87wnmv4s87@posteo.net/). I have also
corrected some minor inconsistencies in the previous two lists.

This new alist supports three types of members:

- Members with two elements: CODE BABEL/POLYGLOSSIA-OPTION.

i.e.: ("ar" "arabic")

- Members with three elements: CODE BABEL/POLYGLOSSIA-OPTION ASTERISK
(the presence of the asterisk indicates that this language is not loaded
in Babel using the old method of ldf files but using ini files. If Babel
is loaded in an Org document with these languages, the \"AUTO \"
argument is just removed, to avoid compilation errors. The new babel
method with ini files  is not supported, for backward
compatibility with 'old' ldf method).

i.e. ("bo" "tibetan" "*")

- Members with four elements (for variants of languages): CODE
BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT

i.e. ("es" "spanishmx" "spanish" "mexican")

==> babel:

\usepackage[mexican]{babel}

==> polyglossia:

\usepackage{polyglossia}
\setmainlanguage[variant=mexican]{spanish}

I also attach an Org document for testing.

Best regards,

Juan Manuel

>From 389a4e43756a7c195c2c1f751b7dc9c03447526d Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sun, 3 Oct 2021 16:55:31 +0200
Subject: [PATCH] ox-latex.el: Unify in one list babel and polyglossia language
 alists

* lisp/ox-latex.el (org-latex-language-alist): Unify in a single list `org-latex-polyglossia-language-alist' and `org-latex-babel-language-alist'
---
 lisp/ox-latex.el | 167 +++
 1 file changed, 68 insertions(+), 99 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3e3967033..de03470fa 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -160,144 +160,109 @@
 
 ;;; Internal Variables
 
-(defconst org-latex-babel-language-alist
-  '(("af" . "afrikaans")
-("bg" . "bulgarian")
-("ca" . "catalan")
-("cs" . "czech")
-("cy" . "welsh")
-("da" . "danish")
-("de" . "germanb")
-("de-at" . "naustrian")
-("de-de" . "ngerman")
-("el" . "greek")
-("en" . "english")
-("en-au" . "australian")
-("en-ca" . "canadian")
-("en-gb" . "british")
-("en-ie" . "irish")
-("en-nz" . "newzealand")
-("en-us" . "american")
-("es" . "spanish")
-("et" . "estonian")
-("eu" . "basque")
-("fi" . "finnish")
-("fr" . "french")
-("fr-ca" . "canadien")
-("gl" . "galician")
-("hr" . "croatian")
-("hu" . "hungarian")
-("id" . "indonesian")
-("is" . "icelandic")
-("it" . "italian")
-("la" . "latin")
-("ms" . "malay")
-("nl" . "dutch")
-("nb" . "norsk")
-("nn" . "nynorsk")
-("no" . "norsk")
-("pl" . "polish")
-("pt" . "portuguese")
-("pt-br" . "brazilian")
-("ro" . "romanian")
-("ru" . "russian")
-("sa" . "sanskrit")
-("sb" . "uppersorbian")
-("sk" . "slovak")
-("sl" . "slovene")
-("sq" . "albanian")
-("sr" . "serbian")
-("sv" . "swedish")
-("ta" . "tamil")
-("tr" . "turkish")
-("uk" . "ukrainian"))
-  "Alist between language code and corresponding Babel option.")
-
-(defconst org-latex-polyglossia-language-alist
-  '(("am" "amharic")
+(defconst org-latex-language-alist
+  '(("am" "amharic" "*")
 ("ar" "arabic")
-("ast" "asturian")
+("ast" "asturian" "*")
 ("bg" "bulgarian")
-("bn" "bengali")
-("bo" "tibetan")
+("bn" "bengali" "*")
+("bo" "tibetan" "*")
 ("br" "breton")
 ("ca" "catalan")
-("cop" "coptic")
+("cop" "coptic" "*")
 ("cs" "czech")
 ("cy" "welsh")
 ("da" "danish")
-("de" "german" "german")
-("de-at" "german" "austrian")
-("de-de" "german" "german")
-("dsb" "lsorbian")
-("dv" "divehi")
+("de" "ngerman" "german" "german")
+("de-at" "naustrian" "german" "austrian")
+("dsb" "lsorbian" "*")
+("dv" "divehi" "*")
 ("el" "greek")
-("en" "english" "usmax")
-("en-au" "english" "australian")
-("en-gb" "english" "uk")
-("en-nz" "english" "newzealand")
-("en-us" "english" "usmax")
+("el-polyton" "polutonikogreek" "greek" "polytonic")
+("en" "american" "english" "usmax")
+("en-au" "australian" "english" "australian")
+("en-gb" "british" "english" "uk")
+("en-nz" "newzealand" "english" "newzealand")
+("en-us" "american" "english" 

Re: [ANN] EmacsConf 2021 Call for Proposals

[Amin Bandali]

Hi Sam,

[ apologies for the super slow reply; I've been unable to keep up with
  the volume of messages on the list for a few months and am only now
  catching up; and didn't see your message sooner since I wasn't
  explicitly Cc'd on it ]

[ before I get into my reply, I'll quick mention that even though the
  CFP is now officially closed, if you'd like to and are able to send
  a proposal within the next few days, I can try to squeeze it in
  along with the other talks ]

Samuel Banya writes:

> Hey there,
>
> I always look forward to the videos that are done for the Emacs conferences 
> each year.
>
> I was wondering, is anyone doing a presentation on using Org Mode for 
> day-to-day work and personal work?

Sure.  I haven't had a close look at this year's proposals yet, but in
the last few EmacsConfs we've had a large number of Org talks covering
various kinds of use-cases and addressing various needs in one's
personal or professional life, and more such talks are welcome. :)

> I often use Emacs for my daily work as a technical support engineer,
> and write notes with source code blocks of different commands I've ran
> in the background since I often have to ssh into client based CentOS
> machines to troubleshoot some issues regarding the application I help
> support.
>
> I'm just an Emacs hobbyist at heart, but have a pretty tweaked out config as 
> well. 
>
> The main thing I wanted to highlight is how to utilize a todo list for work, 
> and life based tasks, as well as org capture templates.
>
> The only other thing is that I could maybe make a work-based todo list but 
> would have to create some fake ticket data due to it being work related, etc.
>
> Please let me know if that would be relevant as a video topic.

Sure, this sounds like something that could very much fit along with
the other Org-related talks this year.

I know it's quite the short notice (my apologies again for not seeing
this earlier) and this year's schedule is looking to be packed, but if
you're still interested and able to send a proposal for your talk, we
may be able to squeeze it if you could do so as soon as possible in
the coming days, following the instructions on the
https://emacsconf.org/2021/submit/ page.

> Thanks,
>
> Sam

Thanks,
amin

-- 
https://bndl.org

[BUG] [PATCH] org-archive.el: Fix checkdoc warnings [9.5 (9.5-g477f05 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

See Attached.

>From e995d2ed668edd9f29e9a8aeaf39bb0eb039e856 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 16:07:15 -0400
Subject: [PATCH] org-archive.el: Fix checkdoc warnings

* org-archive.el: Fix checkdoc warnings.
---
 lisp/org-archive.el | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 0943869a8..db8c02049 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -148,7 +148,7 @@ archive location, but not yet deleted from the original file.")
 
 ;;;###autoload
 (defun org-add-archive-files (files)
-  "Splice the archive files into the list of files.
+  "Splice the archive files into the list of FILES.
 This implies visiting all these files and finding out what the
 archive file is."
   (org-uniquify
@@ -580,8 +580,9 @@ don't move trees, but mark them with the ARCHIVE tag."
 ;;;###autoload
 (defun org-toggle-archive-tag ( find-done)
   "Toggle the archive tag for the current headline.
-With prefix ARG, check all children of current headline and offer tagging
-the children that do not contain any open TODO items."
+When called interactively with \\[universal-argument], or FIND-DONE is
+non-nil, check current headline's children and offer tagging for
+children which do not contain any open TODO items."
   (interactive "P")
   (if (and (org-region-active-p) org-loop-over-headlines-in-active-region)
   (let ((cl (if (eq org-loop-over-headlines-in-active-region 'start-level)
-- 
2.33.0

face for org-capture template

[Jean-Christophe Helary]

I just found how to change the face based on the major mode thanks to 
buffer-face-mode and I'd like to know if there is a similar mechanism to apply 
a given face to the template buffer.

What I have is:

;; polices fixes pour modes
;; https://www.emacswiki.org/emacs/FacesPerBuffer#toc3
(defun my-buffer-face-mode-fixed ()
  "Sets a fixed width (monospace) font in current buffer"
  (interactive)
  (setq buffer-face-mode-face '(:family "PT Mono" :height 115))
  (buffer-face-mode))

(add-hook 'org-capture-mode-hook ’my-buffer-face-mode-fixed)

But that applies the fixed font to the capture target and not to the template 
buffer...

I'm sure the answer is somewhere right under my nose...

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Manually/programmatically adding a state transition message

[Ihor Radchenko]

Trevoke  writes:

> If I understand correctly, this will prevent the addition of a note; I have
> already found a way to do this. Please let me know if I am mistaken.
> What I am looking for is a way to programmatically, without user input,
> change the state and add an automatic note.

No.  Setting this variable programatically is an equivalent of "0"
prefix arg.  Just try it yourself (replacing CANCELLED with whatever
todo keyword that normally triggers interactive note for you):

(let ((org-inhibit-logging 'note)) (org-todo "CANCELLED"))

> If I understand correctly, org-mode implements the addition of the note
> through the function `org-add-log-note` and `org-store-log-note`, and I was
> really hoping I wouldn't have to sift through these two functions to figure
> out and possibly reimplement all the logic of how it finds the place where
> to add the note so I can insert the string there myself.

Yes. Unfortunately, this note system is not very configurable. Though
your specific case is (somewhat awkwardly) covered. In org-add-log-note,
there is the following line:

(if (memq org-log-note-how '(time state))

The org-log-note-how is set in org-add-log-setup according to its args.

org-todo calls org-add-log-setup depending on the value of
org-inhibit-logging.

Thus, my suggestion.

And yes, it is cumbersome. We should re-implement the note system some
day in future.

Best,
Ihor

Re: [BUG] 502/slow response from new repo [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

[Amin Bandali]

Bastien writes:

> No Wayman  writes:
>
>> That was after multiple attempts which resulted in 502 errors.
>
> Yes, I've noticed the https://git.savannah.gnu.org website had some
> issues today.  It seems to be stable now.

Indeed.  For future cases, if the issue remains after, say, 30mins,
please come by the #savannah channel on the Libera.Chat IRC network,
or open a support request in 'administration'[1] project on Savannah
to alert the Savannah hackers of the issue; we'll be happy to help.

[1]: https://savannah.nongnu.org/projects/administration

-- 
https://bndl.org

Re: org-element.el change in emacs.git

[Amin Bandali]

Hi Adam, all,

Adam Porter writes:

[...]
>
> By the way, I'm curious, not having always followed the internal details
> of Org's development over the years: why are changes like that made to
> emacs.git and merged back into Org, instead of being made in Org and
> then merged back into Emacs with the next sync?  It seems like it could
> be a burden, requiring someone like you to track them and merge them,
> but there's probably a good reason for this workflow.
>

Speaking from personal experience/observations, as far as I know the
Emacs developers don't have strict rules about having uni-directional
changes.  And this is not unique to Org; I've seen similar changes in
both directions in other projects developed outside emacs.git that are
periodically merged into emacs.git.  Eliminating the need for keeping
track of such changes is one potential argument for developing Org --
and those other similar packages -- inside emacs.git itself. :)

-- 
https://bndl.org

[PATCH] org-attach-use-inheritance inherits from sibling

[Ihor Radchenko]

Johan Tolö  writes:

> If "* Top heading" is the first heading in the buffer with nothing 
> above it, not even a whitespace/newline, then '(org-entry-get nil 
> "id" t)' with point in "* Second heading" will return the id of 
> "Top heading". If there is anything before "Top heading" then 
> 'nil' will be returned.
>
> This happens when I run 'emacs -Q' from within the "lisp" 
> directory of a newly cloned "org-mode" main branch.

Ouch. Thanks for reporting!

Confirmed

The fix is attached.

Dear all,

I had to fix one of the tests, that apparently was only working because
the bug existed. Please double check.

Best,
Ihor

>From 199e64cf8264025cc78f79c3bdb278920685281f Mon Sep 17 00:00:00 2001
Message-Id: <199e64cf8264025cc78f79c3bdb278920685281f.1633271912.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Sun, 3 Oct 2021 22:10:31 +0800
Subject: [PATCH] org.el: Do not unconditionally inherit from headline right at
 BOB

* lisp/org.el (org-entry-get-with-inheritance): Consider scenario when
there is a headline starting at BOB and we are getting an inherited
property at non-child headline below.  Previous implementation would
erroneously inherit the property value from the first headline in
buffer.

* testing/lisp/test-org.el (test-org/entry-get): Add test and fix an
existing test that worked because this bug existed.

Fixes https://list.orgmode.org/87zgrqqlcs@toloe.se/T/#mfcab9bd710d837a0cd9d4cf331655ee39b8ad3ca
---
 lisp/org.el  | 14 --
 testing/lisp/test-org.el |  6 +-
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index bc0ea24be..bcb38f07f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13163,7 +13163,7 @@ (defun org-entry-get-with-inheritance (property  literal-nil)
 However, if LITERAL-NIL is set, return the string value \"nil\" instead."
   (move-marker org-entry-property-inherited-from nil)
   (org-with-wide-buffer
-   (let (value)
+   (let (value at-bob-no-heading)
  (catch 'exit
(while t
 	 (let ((v (org--property-local-values property literal-nil)))
@@ -13177,7 +13177,17 @@ (defun org-entry-get-with-inheritance (property  literal-nil)
 	 (org-back-to-heading-or-point-min t)
 	 (move-marker org-entry-property-inherited-from (point))
 	 (throw 'exit nil))
-	((org-up-heading-or-point-min))
+((or (org-up-heading-safe)
+ (and (not (bobp))
+  (goto-char (point-min))
+  nil)
+ ;; `org-up-heading-safe' returned nil.  We are at low
+ ;; level heading or bob.  If there is headline
+ ;; there, do not try to fetch its properties.
+ (and (bobp)
+  (not at-bob-no-heading)
+  (not (org-at-heading-p))
+  (setq at-bob-no-heading t
 	(t
 	 (let ((global (org--property-global-or-keyword-value property literal-nil)))
 	   (cond ((not global))
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 18d41a0d2..7b1ce8cd0 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -5831,6 +5831,10 @@ (ert-deftest test-org/entry-get ()
(org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:END:\n** H2"
  (let ((org-use-property-inheritance nil))
(org-entry-get (point-max) "A" 'selective
+  (should-not
+   (org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:END:\n* H2"
+ (let ((org-use-property-inheritance t))
+   (org-entry-get (point-max) "A" t
   (should
(equal
 "1 2"
@@ -5853,7 +5857,7 @@ (ert-deftest test-org/entry-get ()
(equal
 "1 2"
 (org-test-with-temp-text
-	"* H1\n:PROPERTIES:\n:A: 1\n:END:\n* H2.1\n* H2.2\n:PROPERTIES:\n:A+: 2\n:END:"
+	"* H1\n:PROPERTIES:\n:A: 1\n:END:\n** H2.1\n** H2.2\n:PROPERTIES:\n:A+: 2\n:END:"
   (org-entry-get (point-max) "A" t
   (should
(equal "1"
-- 
2.32.0

Re: Cannot clone org-mode's git repository

[Amin Bandali]

Hello,

Colin Baxter writes:

> Hello,
>
> I get a strange error when I try to clone org-mode:
>
> redknight@jetstar:~/git$ git clone 
> https://git.savannah.gnu.org/git/emacs/org-mode.git
> Cloning into 'org-mode'...
> fatal: unable to access 
> 'https://git.savannah.gnu.org/git/emacs/org-mode.git/': server certificate 
> verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

This looks like part of the fallout of the recent expiry of one of
Let's Encrypt's root certificates.  See:
https://savannah.nongnu.org/support/?110546
https://letsencrypt.org/2021/10/01/cert-chaining-help.html

What GNU/Linux distro are you using?  Try updating your packages --
particularly ca-certificates and packages like openssl, gnutls,
libssl, etc. -- and see if it helps.  If not, you can read more on
the topic in recent articles around the web, and apply one of the
suggested workarounds.

> There seems to be nothing wrong with my git. I can pull other
> emacs. auctex, etc. with no problems.

Strange; are you saying that you can clone/fetch from other git
repositories from git.savannah.gnu.org, and only not org-mode.git?

> Best wishes,
>
> Colin Baxter.

Cheers,
-a

P.S. for future potential problems relating to Savannah, please open a
support request at https://savannah.nongnu.org/projects/administration
or if you use IRC come by the #savannah channel on the Libera.Chat and
chat with us about potential problems.

-- 
https://bndl.org

Re: Manually/programmatically adding a state transition message

[Trevoke]

On Sat, Oct 2, 2021 at 5:18 AM Ihor Radchenko  wrote:

> It may be fragile, but you can try let-binding
>
> (org-inhibit-logging 'note)
>
> around elisp org-todo call
>
> Hi Ihor,

If I understand correctly, this will prevent the addition of a note; I have
already found a way to do this. Please let me know if I am mistaken.
What I am looking for is a way to programmatically, without user input,
change the state and add an automatic note.

If I understand correctly, org-mode implements the addition of the note
through the function `org-add-log-note` and `org-store-log-note`, and I was
really hoping I wouldn't have to sift through these two functions to figure
out and possibly reimplement all the logic of how it finds the place where
to add the note so I can insert the string there myself.

Sincerely,
-Aldric

Re: org-attach-use-inheritance inherits from sibling

[Johan Tolö]

Ihor Radchenko  writes:
I cannot reproduce on current main. Are you still seeing this 
problem?


Yes I believe I am. Also, it does not seem to be an org-attach 
issue but rather an issue with how org gets properties with 
inheritance.


If "* Top heading" is the first heading in the buffer with nothing 
above it, not even a whitespace/newline, then '(org-entry-get nil 
"id" t)' with point in "* Second heading" will return the id of 
"Top heading". If there is anything before "Top heading" then 
'nil' will be returned.


This happens when I run 'emacs -Q' from within the "lisp" 
directory of a newly cloned "org-mode" main branch.


This example illustrates the problem:

 beginning of buffer 
* Top heading
:PROPERTIES:
:ID:   acf18561-7a84-4703-96c6-1aceccd46b33
:END:

* Second heading
 
#+begin_src emacs-lisp

 (load "org.el")
 (load "org-id.el")
 (org-entry-get nil "id" t)
#+end_src

#+RESULTS:
: acf18561-7a84-4703-96c6-1aceccd46b33

 end of buffer 


--
Johan Tolö

Re: [org-cite] How to cite page number(s) in APA Style?

[Bruce D'Arcus]

On Sun, Oct 3, 2021 at 9:18 AM Rudolf Adamkovič  wrote:
>
> "Bruce D'Arcus"  writes:
>
> > ATM, your only option is to do "(p. 42)."
>
> Bummer.

You could put in a feature request though ;-)

Aside: the other way to handle this, which has been discussed in the
pandoc community, is to allow infixes, along with the current prefixes
and suffixes.

But that would make an already pretty complex model more complex.

> > It would be possible (easy?) to add a "locators" style to
> > citeproc-el/oc-csl as in oc-biblatex, in which case you would
> > do:
> >
> > According to [cite/text:@someone-2021], foo-bar
> > [cite/locators:@someone-2021].
>
> [cite/locators:@someone-2021 42] rather, right?

Yes, that's right!

Bruce

[BUG] Citations: exporting with csl crashes [9.5 (9.5-g0a86ad @ /home/quintus/.emacs.d/elpa/org-9.5/)]

[Marvin Gülker]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

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


Hi there,

I've been trying to use the new citation facilities in the just-released
9.5 version of org for a simple test document with my preferred CSL
style (the one usually used in German law discipline in one way or
another), but did not have luck with it so far. That being said,
exporting with the default "bare" citation processor appears to be fine.
With the "csl" processor, I receive this error when I export to LaTeX
with `org-latex-export-as-latex':

Debugger entered--Lisp error: (wrong-type-argument sequencep splice)
  citeproc-rt--cquote-pstns-1(splice 15)
  citeproc-rt--cquote-pstns-1((nil (nil (nil (((font-style . "italic")) 
(((rendered-var . author) (rendered-names)) ((...) (nil "Goldsmith")) "/" 
((...) (nil "Wu") ", ") splice (nil ", " (((rendered-var . locator)) #("83" 
0 2 (:parent (citation-reference (:key "goldsmith-wu2008netctrl" :begin 162 
:end 192 :post-blank 0 :suffix ... :parent ...))) 1)
  citeproc-rt--cquote-pstns((nil (nil (nil (((font-style . "italic")) 
(((rendered-var . author) (rendered-names)) ((...) (nil "Goldsmith")) "/" 
((...) (nil "Wu") ", ") splice (nil ", " (((rendered-var . locator)) #("83" 
0 2 (:parent (citation-reference (:key "goldsmith-wu2008netctrl" :begin 162 
:end 192 :post-blank 0 :suffix ... :parent ...
  citeproc-rt-punct-in-quote((nil (nil (nil (((font-style . "italic")) 
(((rendered-var . author) (rendered-names)) ((...) (nil "Goldsmith")) "/" 
((...) (nil "Wu") ", ") splice (nil ", " (((rendered-var . locator)) #("83" 
0 2 (:parent (citation-reference (:key "goldsmith-wu2008netctrl" :begin 162 
:end 192 :post-blank 0 :suffix ... :parent ...
  citeproc-rt-finalize((nil (nil (nil (((font-style . "italic")) 
(((rendered-var . author) (rendered-names)) ((...) (nil "Goldsmith")) "/" 
((...) (nil "Wu") ", ") splice (nil ", " (((rendered-var . locator)) #("83" 
0 2 (:parent (citation-reference (:key "goldsmith-wu2008netctrl" :begin 162 
:end 192 :post-blank 0 :suffix ... :parent ...))) t)
  citeproc-citation--render(#s(citeproc-citation :cites ((... ... ... ... 
... ... ... ...)) :note-index nil :mode nil :suppress-affixes nil 
:capitalize-first nil :ignore-et-al nil :grouped nil) #s(citeproc-proc :style 
#s(citeproc-style :info (... ... ... ... ... ... ... ... ... ... ... ... ...) 
:opts (... ... ... ... ...) :bib-opts (... ... ...) :bib-sort (lambda ... ...) 
:bib-sort-orders (t t) :bib-layout (lambda ... ...) :cite-opts (... ... ...) 
:cite-note t :cite-sort nil :cite-sort-orders nil :cite-layout (lambda ... ...) 
:cite-layout-attrs (...) :locale-opts (... ...) :macros (... ... ... ... ... 
... ... ... ...) :terms (... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ... ... ... ... ... ... ... ... ...) :uses-ys-var nil 
:date-text (... ... ... ...) :date-numeric (... ... ... ...)) :getter 
#f(compiled-function (itemids) #) :itemdata 
# :citations #s(queue :head (...) :tail 
(...)) :names # :finalized t) t)
  citeproc-citation--render-formatted-citation(#s(citeproc-citation :cites 
((... ... ... ... ... ... ... ...)) :note-index nil :mode nil :suppress-affixes 
nil :capitalize-first nil :ignore-et-al nil :grouped nil) #s(citeproc-proc 
:style #s(citeproc-style :info (... ... ... ... ... ... ... ... ... ... ... ... 
...) :opts (... ... ... ... ...) :bib-opts (... ... ...) :bib-sort (lambda ... 
...) :bib-sort-orders (t t) :bib-layout (lambda ... ...) :cite-opts (... ... 
...) :cite-note t :cite-sort nil :cite-sort-orders nil :cite-layout (lambda ... 
...) :cite-layout-attrs (...) :locale-opts (... ...) :macros (... ... ... ... 
... ... ... ... ...) :terms (... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ... ... ... ... ... ... ... ... ... ...) :uses-ys-var nil 
:date-text (... ... ... ...) :date-numeric (... ... ... ...)) :getter 
#f(compiled-function (itemids) #) :itemdata 
# :citations #s(queue :head (...) :tail 
(...)) :names # :finalized t) latex t)
  #f(compiled-function (it) #)(#s(citeproc-citation :cites (((position . first) (itd . 
#s(citeproc-itemdata :varvals ((citation-number . "1") (label . "page") 
(publisher-place . "New York") (publisher . "Oxford University Press") (title . 
"Who Controls the Internet?") (issued ...) (type . "book") (author ... ...) 
(ISBN . "978-0-19-534064-8")) :rawcite nil :rc-uptodate nil :sort-key 
("Goldsmith, Jack/ Wu, Tim" "7008") :occurred-before t :disamb-pos first)) 
(id . "goldsmith-wu2008netctrl") (prefix) (suffix) (locator . #("83" 0 2 
(:parent (citation-reference ... (label . "page") (location . #("p. 83" 0 5 
(:parent (citation-reference ...)) 

Re: [org-cite] How to cite page number(s) in APA Style?

[Rudolf Adamkovič]

"Bruce D'Arcus"  writes:


ATM, your only option is to do "(p. 42)."


Bummer.

It would be possible (easy?) to add a "locators" style to 
citeproc-el/oc-csl as in oc-biblatex, in which case you would 
do: 

According to [cite/text:@someone-2021], foo-bar 
[cite/locators:@someone-2021].


[cite/locators:@someone-2021 42] rather, right?

Rudy 


--
"Contrariwise," continued Tweedledee, "if it was so, it might be; 
and if it were so, it would be; but as it isn't, it ain't. That's 
logic." -- Lewis Carroll, Through the Looking Glass  Rudolf 
Adamkovič  Studenohorská 25 84103 Bratislava 
Slovakia  [he/him]

Re: Inequalities in math blocks

[Rudolf Adamkovič]

Max Nikulin  writes:

Though I am a bit surprised that Org did not replace characters 
to   and  during export. Perhaps, it is possible to 
define a filter. 


That makes sense, and thank you for the explanation. Ignoring the 
dead link in the Org manual, I wonder how this bug can even exist 
in Org after 15+ years of development. Some people, including the 
author of TeX himself, write TeX without unnecessary whitespace. 
Strange! Either way, rearranging bullet points should never break 
math without any visual sign inside of Emacs. Thus, this 
represents a bug in Org. 


R+

--
I love deadlines. I love the whooshing noise they make as they go 
by. -- Douglas Adams, The Salmon of Doubt  Rudolf Adamkovič 
 Studenohorská 25 84103 Bratislava Slovakia 
[he/him]

Re: Inequalities in math blocks

[Timothy]

Hi Rudolf and Max,

>> Usually, it is sufficient simply to put spaces around these symbols to
>> cause the browser to avoid them, so
>> … when x < y we have …
>
> Though I am a bit surprised that Org did not replace characters to  and 
> 
> during export. Perhaps, it is possible to define a filter.

You’re going to be much better off if you just use LaTeX math delimiters, i.e. 
`\(
... \)'.

All the best,
Timothy

Re: How is the return value of `org-babel-execute:FOO` interpreted?

[Ihor Radchenko]

Kodi Arfer  writes:

> It works, thank you. I should've looked at the changelog more closely. I 
> wonder why this change was made. It would be annoyingly redundant to put 
> `:results file` next to every `:file`. I already have code to change the 
> default value of `:results` when `:file` is set, for a different Babel 
> language, so I should be able to adapt that to this language.

There are tools like subtree-local headers args or default headers args
at your disposal.

The argument why that change was made is the following (commit 26ed66b23):

>> Deducing the results from some other arguments is not obvious.
>> Moreover, it prevents users from setting, e.g., :file-ext, in a node
>> property, as every block would then create a file.
>> 
>> Reported-by: Alex Fenton 
>> 

Best,
Ihor

Re: How is the return value of `org-babel-execute:FOO` interpreted?

[Kodi Arfer]

On 2021 Oct 03 Sun 8:39:37 AM -0400, Ihor Radchenko  wrote:

Ihor Radchenko  writes:


Kodi Arfer  writes:


Are you sure that you have :file parameter in the source block you tried
to execute?


Yes, this is my code block:

#+begin_src hy :file g/foo.png
(plt.scatter [1 2 3] [4 5 -9])
#+end_src


What about

#+begin_src hy :results file :file g/foo.png
(plt.scatter [1 2 3] [4 5 -9])
#+end_src

?


If this code works for you, the problem is the folloing incompatible
change in Org 9.3 (see etc/ORG-NEWS file in the repo):

* Version 9.3
** Incompatible changes
*** ~:file~ header argument no longer assume "file" ~:results~

The "file" ~:results~ value is now mandatory for a code block
returning a link to a file.  The ~:file~ or ~:file-ext~ header
arguments no longer imply a "file" result is expected.


It works, thank you. I should've looked at the changelog more closely. I wonder 
why this change was made. It would be annoyingly redundant to put `:results 
file` next to every `:file`. I already have code to change the default value of 
`:results` when `:file` is set, for a different Babel language, so I should be 
able to adapt that to this language.

Re: How is the return value of `org-babel-execute:FOO` interpreted?

[Ihor Radchenko]

Ihor Radchenko  writes:

> Kodi Arfer  writes:
>
>>> Are you sure that you have :file parameter in the source block you tried
>>> to execute?
>>
>> Yes, this is my code block:
>>
>> #+begin_src hy :file g/foo.png
>> (plt.scatter [1 2 3] [4 5 -9])
>> #+end_src
>
> What about
>
> #+begin_src hy :results file :file g/foo.png
> (plt.scatter [1 2 3] [4 5 -9])
> #+end_src
>
> ?

If this code works for you, the problem is the folloing incompatible
change in Org 9.3 (see etc/ORG-NEWS file in the repo):

* Version 9.3
** Incompatible changes
*** ~:file~ header argument no longer assume "file" ~:results~

The "file" ~:results~ value is now mandatory for a code block
returning a link to a file.  The ~:file~ or ~:file-ext~ header
arguments no longer imply a "file" result is expected.

Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Ihor Radchenko]

Max Nikulin  writes:

>> Making \[ \] available outside of a paragraph would be a massive
>> breaking change.
>
> Is it really breaking? I can not estimate required amount of work to 
> implement it. However at the user side at first glance most of files 
> should remain valid and I could not imagine markup that will be broken 
> during export to LaTeX.

If I understand correctly, making \[ \] available outside paragraph
would mean that it becomes a new element (currently \[\] is a
latex-fragment object). New element means that all the exporters will
need to be updated and handle this new element specially. Indeed, it
will be a breaking change.

Best,
Ihor

Re: Inequalities in math blocks

[Max Nikulin]

On 03/10/2021 18:04, Rudolf Adamkovič wrote:

The following Org markup does not render properly in HTML export:

- foo $aa$ bar
In Emacs, I see no signs of problems, such as broken math highlighting. 
Further, when I export to LaTeX, the inequalities render properly. Does 
one have to use \lt and \gt instead of < and
all the time? If so, why allow < and > characters in math 
blocks? I ask because, when I reorganize my Org document, it breaks math 
"at random" when I use < and > and Emacs does not tell me about it.


I had another reason to look into the manual today, so I noticed:

https://orgmode.org/manual/Math-formatting-in-HTML-export.html


(131)

Please note that exported formulas are part of an HTML document, and
that signs such as ‘<’, ‘>’, or ‘&’ have special meanings. See MathJax
TeX and LaTeX support.


The link is broken however.

http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters


Usually, it is sufficient simply to put spaces around these symbols to
cause the browser to avoid them, so

... when $x < y$ we have ...


Though I am a bit surprised that Org did not replace characters to  
and  during export. Perhaps, it is possible to define a filter.

Re: How is the return value of `org-babel-execute:FOO` interpreted?

[Ihor Radchenko]

Kodi Arfer  writes:

>> Are you sure that you have :file parameter in the source block you tried
>> to execute?
>
> Yes, this is my code block:
>
> #+begin_src hy :file g/foo.png
> (plt.scatter [1 2 3] [4 5 -9])
> #+end_src

What about

#+begin_src hy :results file :file g/foo.png
(plt.scatter [1 2 3] [4 5 -9])
#+end_src

?

Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Max Nikulin]

On 03/10/2021 17:56, Stefan Nobis wrote:

Max Nikulin writes:

On 03/10/2021 00:51, Tom Gillespie wrote:



I guess one thing I'm missing/not understanding is when/why people
want to use \[ \] instead of full #+begin_export latex block?



For example, because document without equations may become almost
useless in the case of export to HTML or ODT file.


Remember, as Nicolas said, the alternative to \[...\] is not a
"#+begin_export" block, but

\begin{equation*}
...
\end{equation*}


Maybe you are right and Tom was actually assuming \begin{equation*}, not 
#+begin_export latex. Since Tom and Timothy started discussion of LaTeX 
preview issues, it was better to clarify that #+begin_export is not a 
rescue here at all, it has different purpose.


Just as Timothy, I believe that \begin{equation*} is unnecessary verbose 
when \[ works *mostly* in a similar way. It shifts the border when it is 
easier to avoid Org for particular paper and to write LaTeX markup directly.


Another branch of this thread is refactoring of `org-fill-element', but 
in my opinion, if \[ \] remains an inline object, adding a special case 
for it is anyway increasing overall mess. It \[ \] were became 
block-level element, it would not be necessary.

Re: How is the return value of `org-babel-execute:FOO` interpreted?

[Kodi Arfer]

On 2021 Oct 03 Sun 5:38:10 AM -0400, Ihor Radchenko  wrote:

Kodi Arfer  writes:

I have an `org-babel-execute` function for the Hy programming
language that seems to have partly broken when I upgraded Org (from
9.1.14 to 9.4.6). …


I just tested using ob-gnuplot and :file link is correctly inserted when
org-babel-execute:gnuplot returns nil.

Are you sure that you have :file parameter in the source block you tried
to execute?


Yes, this is my code block:

#+begin_src hy :file g/foo.png
(plt.scatter [1 2 3] [4 5 -9])
#+end_src

And it looks like `org-babel-execute:hy` is indeed receiving the argument, since `(message 
"%s" (assq :file (org-babel-process-params params)))` prints "(:file . 
g/foo.png)".

Re: Cannot clone org-mode's git repository

[Jens Lechtenboerger]

On 2021-10-03, Colin Baxter wrote:

> Hello,
>
> I get a strange error when I try to clone org-mode:
>
> redknight@jetstar:~/git$ git clone 
> https://git.savannah.gnu.org/git/emacs/org-mode.git
> Cloning into 'org-mode'...
> fatal: unable to access 
> 'https://git.savannah.gnu.org/git/emacs/org-mode.git/': server certificate 
> verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Hi there,

I got a similar error in a Docker image (with "CAfile: none"
instead).  A CA certificate was missing.  Eventually, I updated the
entire image (in particular, with a new version of ca-certificates).
Hopefully this helps:
https://stackoverflow.com/questions/35821245/github-server-certificate-verification-failed/35824116#35824116

Best wishes
Jens

Re: 9.5: coping with loss of ditaa.jar

[Max Nikulin]

On 03/10/2021 11:25, Jarmo Hurri wrote:


I use ditaa with org on a regular basis. Now that ditaa.jar is out of
org 9.5, I need to cope with the situtation.

I see two options, and neither was successful today. This is sort of
what I was afraid of when I voted for keeping ditaa bundled with org.

1. I am running Fedora 34, where ditaa is available as a
package. However, just pointing org-ditaa-jar-path to the correct
location /usr/share/java/ditaa.jar is not sufficient, because doing
so leads to errors when trying to execute a ditaa babel block:


I am not a ditaa user currently, but generally it should be the 
preferred option. I have not looked into ob-ditaa.el however to realize 
if it has enough defcustom options.



2. Ditaa is available via github at
https://github.com/stathissideris/ditaa

The developer section points to building with some clojure build
system lein, which is not available in my system, and in Fedora,
running

dnf list available '*lein*'


Option 3: jar built by ditaa developers 
https://github.com/stathissideris/ditaa/releases

Re: Comments break up a paragraph when writing one-setence-per-line

[Max Nikulin]

On 03/10/2021 00:57, Tom Gillespie wrote:

A general comment (heh) here. This is not a bug and not easily fixed.
Line comments are their own top level element distinct from
paragraphs. If you need something that fits in a paragraph you can use
@@comment:@@ at the start of a line.

I agree that it is annoying, but Org line comment syntax also only
works if it starts the line, so the behavior diverges from traditional
code comments. It may make sense to update the docs to call them "line
comments" instead of just comments.


Agree, if parser is not changed, I suppose, the manual and the guide 
should state very prominent that comment line disrupts current paragraph 
unlike "%" in TeX.


However there 5 users in this thread who expect that "# " or "#+latex:" 
should not be "element" and should be a part of surrounding paragraph.


Thank you for the idea with @@comment:@@, let me stress that final @@ 
should be on the next line. It is similar to my idea with a macro 
expanding to nothing. It may be documented in the manual. However I 
would expect that `org-lint' issues a warning concerning unknown 
backends to catch typos in names. By the way, `org-lint' does not like 
the variant with comment as macro.


I think, it is a bug in LaTeX backend that the following becomes 3 
separate paragraphs:


   #+macro: comment
   Beginning of a paragraph A.
   @@comment: FIXME@@
   Paragraph A continues.
   {{{comment(TODO)}}}
   End of paragraph A.

And the following is really confusing:

   How many paragraphs
   #+html: 
   is here
   #+latex: %
   in LaTeX and HTML output?

LaTeX backend exports it as a continuous paragraph (an idea of a weird 
hack how to comment a line if only LaTeX export is needed). HTML backend 
believes that it is 3 paragraphs.

Re: Cannot clone org-mode's git repository

[Ihor Radchenko]

Colin Baxter  writes:

> Hello,
>
> I get a strange error when I try to clone org-mode:
>
> --8<---cut here---start->8---
> redknight@jetstar:~/git$ git clone 
> https://git.savannah.gnu.org/git/emacs/org-mode.git
> Cloning into 'org-mode'...
> fatal: unable to access 
> 'https://git.savannah.gnu.org/git/emacs/org-mode.git/': server certificate 
> verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
> --8<---cut here---end--->8---

It works for me.

Try again later.  savannah may not be stable from time to time,
especially when you try a fresh clone of a large repo.

Best,
Ihor

Re: Cannot clone org-mode's git repository

[Timothy]

Hi Colin,

> I get a strange error when I try to clone org-mode:

Interesting, I just tried `git clone git://git.sv.gnu.org/emacs/org-mode.git' 
and
that seemed fine.

All the best,
Timothy

Cannot clone org-mode's git repository

[Colin Baxter]

Hello,

I get a strange error when I try to clone org-mode:

--8<---cut here---start->8---
redknight@jetstar:~/git$ git clone 
https://git.savannah.gnu.org/git/emacs/org-mode.git
Cloning into 'org-mode'...
fatal: unable to access 'https://git.savannah.gnu.org/git/emacs/org-mode.git/': 
server certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt CRLfile: none
--8<---cut here---end--->8---

There seems to be nothing wrong with my git. I can pull other
emacs. auctex, etc. with no problems.

Best wishes,

Colin Baxter.

Inequalities in math blocks

[Rudolf Adamkovič]

The following Org markup does not render properly in HTML export:

- foo $aa$ bar 

In Emacs, I see no signs of problems, such as broken math 
highlighting. Further, when I export to LaTeX, the inequalities 
render properly. Does one have to use \lt and \gt instead of < and 
all the time? If so, why allow < and > characters in math 
blocks? I ask because, when I reorganize my Org document, it 
breaks math "at random" when I use < and > and Emacs does not tell 
me about it.


R+
--
Logic is a science of the necessary laws of thought, without which 
no employment of the understanding and the reason takes place. -- 
Immanuel Kant, 1785  Rudolf Adamkovič  
Studenohorská 25 84103 Bratislava Slovakia  [he/him]

Re: [org-cite] How to cite page number(s) in APA Style?

[Bruce D'Arcus]

On Sun, Oct 3, 2021 at 6:35 AM Rudolf Adamkovič  wrote:

> I use APA (via CSL) to cite and would like to write
>
> > According to Someone (2021), foo-bar (p. 42).
>
> I can almost do it with
>
> > Accordint to [cite/text:@someone-2021], foo-bar
> > .
>
> Any ideas? In APA, this pattern comes up often.

ATM, your only option is to do "(p. 42)."

It would be possible (easy?) to add a "locators" style to
citeproc-el/oc-csl as in oc-biblatex, in which case you would do:

According to [cite/text:@someone-2021], foo-bar [cite/locators:@someone-2021].

Bruce

Re: [PATCH] Don't fill displayed equations

[Stefan Nobis]

Max Nikulin  writes:

> On 03/10/2021 00:51, Tom Gillespie wrote:

>> I guess one thing I'm missing/not understanding is when/why people
>> want to use \[ \] instead of full #+begin_export latex block?

> For example, because document without equations may become almost
> useless in the case of export to HTML or ODT file.

Remember, as Nicolas said, the alternative to \[...\] is not a
"#+begin_export" block, but

\begin{equation*}
...
\end{equation*}

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

[org-cite] How to cite page number(s) in APA Style?

[Rudolf Adamkovič]

I use APA (via CSL) to cite and would like to write


According to Someone (2021), foo-bar (p. 42).


I can almost do it with

Accordint to [cite/text:@someone-2021], foo-bar 
.


Any ideas? In APA, this pattern comes up often.

Thank you!

R+

--
I love deadlines. I love the whooshing noise they make as they go 
by. -- Douglas Adams, The Salmon of Doubt  Rudolf Adamkovič 
 Studenohorská 25 84103 Bratislava Slovakia 
[he/him]

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Ihor,

> Then would you mind proposing a patch for org-fill-element in
> particular? At least, you seem to have a motivation for this particular
> function ;)

Perhaps in a few weeks, for now I’m a bit to busy for anything other than
“accidental”  patches.

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Ihor Radchenko]

Timothy  writes:

> Ihor Radchenko  writes:
>
>> I personally would prefer modular function as a whole.  For my taste,
>> Org code has too much of (case (variant 1) (variant 2) …)-style
>> functions (i.e. org-todo, org-cycle, org-ctrl-c-ctrl-c, org-store-link,
>> etc) and they are a pain to debug and advice for users. 
>
> Mmmm, I’m with you on this in general. I also think the code base has far too
> many monolithic “200 line” functions which are crying out to be split up.
> Now if I could just clone myself once or twice… 

Then would you mind proposing a patch for org-fill-element in
particular? At least, you seem to have a motivation for this particular
function ;)

Best,
Ihor

Re: How is the return value of `org-babel-execute:FOO` interpreted?

[Ihor Radchenko]

Kodi Arfer  writes:

> I have an `org-babel-execute` function for the Hy programming language that 
> seems to have partly broken when I upgraded Org (from 9.1.14 to 9.4.6). It 
> has code to write a plot to a file when a `:file` argument is given to the 
> code block. It returns `nil` in this case, and previously, Org would 
> automatically insert a link to the file in the results block, as desired. 
> Now, however, the `nil` is printed in the results block. So I guess have to 
> edit the function to return a link instead, but I can't find documentation 
> for how Org interprets the return value of an `org-babel-execute` function: 
> as I vaguely recall, you have to use a certain cons structure to produce a 
> table, another to produce a link, and so on. So the concrete question in this 
> case is: what do I return to put a link in the document?

I just tested using ob-gnuplot and :file link is correctly inserted when
org-babel-execute:gnuplot returns nil.

Are you sure that you have :file parameter in the source block you tried
to execute?

Best,
Ihor

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Hi Ihor,

> What about separating the src_{nil} fontification into separate patch? I
> think that part raised no objections.

That sounds like a good idea to me. We may as well get that in.

> As for the results prettifications, I look at this and similar ideas as
> at Emacs themes.  It looks nice on your screenshot with your fonts and
> colours, but may not be good for other people.  Similar to org-bullets
> and co.

The behaviour makes me think of link prettification more than what Emacs themes
do. Hiding the text {{{results( with an overlay seems like something a
major/minor mode should be responsible for, not a theme.

> I can see how some people (I am among those people) want to reduce the
> markup noise beyond hiding emphasis markers.  However, some people
> prefer not to hide text in buffer under “bells and whistles”.

Indeed, and it’s good to have this option. This is why I also introduced a new
setting, `org-inline-src-prettify-results' (similarly named to
`org-pretty-entities').

> Maybe we can create some kind of “prettify-symbol themes” replacing different
> markup elements in bulk with nice symbols/svg (e.g. inline results, block
> headers/footers, uninteresting property drawers aka org-custom-properties,
> bullets, etc)? WDYT? Also, CCing Prot as it might be of interest for him.
> Best, Ihor

I think it could make sense for some prettification capabilities to be built
into Org well. Currently there are a few little things we have, but it seems to
be handled inconsistently and I think it could be nice to provide a more unified
approach. There are also things like
 which I feel 
just
make a lot of sense with Org (you never have to guess if `point' is before or
after a markup character).

All the best,
Timothy

Re: [org-cite] Testing on macOS, XML file missing

[Rudolf Adamkovič]

Kyle Meyer  writes:

This is hopefully resolved with bb209cd5ab (Update to Org 
9.5-30-g10dc9d, 2021-10-02) in the Emacs repo.


It works now. Thank you! 


R+

--
Logic is a science of the necessary laws of thought, without which 
no employment of the understanding and the reason takes place. -- 
Immanuel Kant, 1785  Rudolf Adamkovič  
Studenohorská 25 84103 Bratislava Slovakia  [he/him]

Re: org-capture-template with changing heading (including a TIMESTAMP)

[Ihor Radchenko]

Uwe Brauer  writes:

> I tried 
>
> ("mg" "Ejercicios Annu21: hechos, solicitados y asignados"
>  table-line (file+function 
> "~/ALLES/HGs/tex/vorlesungen/HGAnnu/Ejercios-Alumnos-Grupos/2021/Ejercios-Teoria21.org"
>  "Ejercicios Annu21: hechos, solicitados y asignados" (clock))
>  "| |%^{Grp|1|2|3|4|5|6|7|8}  |%^{Hj|1|2|3|4|5|6|7} 
> |%^{Ej-As|1|2|3|4|5} |%^{Tit}| | [] | |   | %:fromname| |%:fromaddress |  
> %(my-extract-cc)  |%:subject | %:date |%a | "  :prepend t :empty-lines 1 
> :unnarrowed t
>  )
>
> But it does not work, I receive the error 

Because you did not supply a function. The docstring says:
(file+function "path/to/file" function-finding-location)

function-finding-location should be a valid Elisp function that will
need to take care about moving point to target heading.  What you have
in your template is
(key description table-line (file+function file-name
!some-string-that-should-not-be-there! 
!(clock)-which-is-a-third-element-and-also-should-not-be-there!) ...


Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Timothy]

Ihor Radchenko  writes:

> I personally would prefer modular function as a whole.  For my taste,
> Org code has too much of (case (variant 1) (variant 2) …)-style
> functions (i.e. org-todo, org-cycle, org-ctrl-c-ctrl-c, org-store-link,
> etc) and they are a pain to debug and advice for users. 

Mmmm, I’m with you on this in general. I also think the code base has far too
many monolithic “200 line” functions which are crying out to be split up.
Now if I could just clone myself once or twice… 

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Ihor Radchenko]

Timothy  writes:

> Hi Ihor,
>
>> What about making org-fill-element modular?  We may define separate fill
>> functions for different elements and let the user override them
>> individually if the user prefer so.  It may be implemented similar to
>> export functionality with customisable formatters for different
>> elements.
>
> Thanks for that idea. Perhaps something along those lines may be the best
> solution here. If we don’t want to make the whole function modular, perhaps we
> could make a setting for this?

I personally would prefer modular function as a whole.  For my taste,
Org code has too much of (case (variant 1) (variant 2) ...)-style
functions (i.e. org-todo, org-cycle, org-ctrl-c-ctrl-c, org-store-link,
etc) and they are a pain to debug and advice for users. 

Best,
Ihor

Re: [PATCH] Fontification for inline src blocks

[Ihor Radchenko]

Timothy  writes:

> Ihor Radchenko  writes:
>
>> Let me bump this thread again and mark it as a patch ;)
>
> Thanks for the bump. I'd like to get this working, but I don't know how best 
> to
> deal with the "prettification" of {{{results(=value=)}}}, which is the major 
> blocker as I
> see it.

What about separating the src_{} fontification into separate patch? I
think that part raised no objections.

As for the results prettifications, I look at this and similar ideas as
at Emacs themes.  It looks nice on your screenshot with your fonts and
colours, but may not be good for other people.  Similar to org-bullets
and co.

I can see how some people (I am among those people) want to reduce the
markup noise beyond hiding emphasis markers.  However, some people
prefer not to hide text in buffer under "bells and whistles".  Maybe we
can create some kind of "prettify-symbol themes" replacing different
markup elements in bulk with nice symbols/svg (e.g. inline results,
block headers/footers, uninteresting property drawers aka
org-custom-properties, bullets, etc)?
WDYT?

Also, CCing Prot as it might be of interest for him.

Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Ihor,

> What about making org-fill-element modular?  We may define separate fill
> functions for different elements and let the user override them
> individually if the user prefer so.  It may be implemented similar to
> export functionality with customisable formatters for different
> elements.

Thanks for that idea. Perhaps something along those lines may be the best
solution here. If we don’t want to make the whole function modular, perhaps we
could make a setting for this?

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Max Nikulin]

On 03/10/2021 00:51, Tom Gillespie wrote:

do not see a reason for idiosyncrasy that markup intended to add LaTeX
snippet that looks like exactly as LaTeX commands for this purpose and
even actually preserved during export to LaTeX should have different
semantics for Org parser.


The answer is that \[ \] can only occur inside paragraphs.


Nicolas mentioned that meaning of \[ \] might be changed and that will 
allow among other things correctly working of paragraph filling. I like 
such idea.



Org gives
us a bit more power, but not the full power because Org is Org, not
Latex.


There is \( \) object for inline math. Is there use cases for 2 
(actually 2 groups of 2 elements counting $...$ and $$...$$) variants 
for inline math when primary backend for them behaves differently?



Making \[ \] available outside of a paragraph would be a massive
breaking change.


Is it really breaking? I can not estimate required amount of work to 
implement it. However at the user side at first glance most of files 
should remain valid and I could not imagine markup that will be broken 
during export to LaTeX.



I guess one thing I'm missing/not understanding is when/why people
want to use \[ \] instead of full #+begin_export latex block?


For example, because document without equations may become almost 
useless in the case of export to HTML or ODT file.

Re: [PATCH] Don't fill displayed equations

[Ihor Radchenko]

Timothy  writes:

> Hi Nicolas,
>
>> *snip lots of text*
>
> Thanks for going through my points in detail. I think I understand your
> perspective much better now. At this point though, I’m not really sure what to
> make of `\[ ... \]', I now feel like it’s sitting in some sort of markup limbo
> where it can’t be either fully LaTeX-y or fully Org-y. I still think it would 
> be
> good to improve this, but I no longer have such a firm idea that “modifying 
> fill
> is the way”.

What about making org-fill-element modular?  We may define separate fill
functions for different elements and let the user override them
individually if the user prefer so.  It may be implemented similar to
export functionality with customisable formatters for different
elements.

Best,
Ihor

Re: Possible bug? Combine emphasis marker faces?

[Ihor Radchenko]

Protesilaos Stavrou  writes:

> Hello everyone,
>
> I have noticed that it is not possible to combine org-emphasis-alist
> characters.  When applying multiple types of emphasis, the face
> corresponding to the outermost pair overrides its innermost counterparts.
>
> For example, */emphasise/* will render with the 'bold' face, while
> /*emphasise*/ will use the 'italic' face.

Confirmed

> Looking at the code, this seems to be intentional or unavoidable, while
> I do not know of a way to blend faces dynamically.
>
> Is there a way to get composite styles?  Such as bold and italic or
> verbatim and underline, etc.?

org-element-context does return nested emphasis, so it is certainly
possible to combine composite styles (at least, during export).
Fontification code does not work with elements though and I do not see
an easy way to change it.

Rewriting fontification using org-element API would eliminate this type
of issues.  However, I am not sure about performance (maybe with
org-element-cache?).

Best,
Ihor

Re: Unable to follow gnus links

[Ihor Radchenko]

Tom Ed White  writes:

> Following gnus links in org fails with the message:
>
> funcall: Wrong number of arguments: ((t) (path _) "Follow the Gnus
> message or folder link specified by PATH." (if (string-match
> "\\`\\([^#]+\\)\\(#\\(.*\\)\\)?" path) nil (error "Error in Gnus link
> %S" path)) (let ((group (match-string-no-properties 1 path)) (article
> (match-string-no-properties 3 path))) (org-gnus-follow-link group
> article))), 1

This should not happen.  Do you open the link using org-link-open?  Can
you share backtrace after M-x debug-on-entry org-gnus-open?

Best,
Ihor

Re: Org agenda width is one char-column too short

[Ihor Radchenko]

torys.ander...@gmail.com (Tory S. Anderson) writes:

> As seen in the linked image, my agenda width is a single char too short so it 
> clips the last : of the tags. I always use truncate-lines-mode, so this is a 
> minor inconvenience but might be something easily fixed for new users? I 
> think it has always done this for me.
>
> https://i.imgur.com/RFRhLMT.png

Judging from the screenshot, it appears that you have customised
org-agenda-prefix-format.  Can you share the value of this variable?

Best,
Ihor

Re: [O] BUG: Capture task clocking doesn't stop due to narrowing

[Ihor Radchenko]

Bernt Hansen  writes:

> Hi,
>
> I ran into an issue this morning where my capture task continues
> clocking on save.  This occurs in both master and maint when not
> clocking into a drawer.
>
> ECM follows.

Confirmed

[PATCH] [O] Single opening star induces bold face if immediately preceeding inlinetask

[Ihor Radchenko]

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

> Hello.
>
> With this org file, the "blah" is in bold face.
>
> * foo
> a *blah
> *** task
> bar
> *** END
>
> I would it is a small bug.  NB: If I insert a blank line before the
> task, the face goes back to normal.

Thanks for your report. It took a while to process, but here is the fix.

Best,
Ihor

>From ae325834b75944d81ad57087336ca6efa6e57480 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Sun, 3 Oct 2021 15:48:23 +0800
Subject: [PATCH] org.el: Do not span emphasis over inlinetask boundaries

* lisp/org.el (org-do-emphasis-faces): Check paragraph boundaries
within emphasis even when the boundary is not starting right at the
beginning of the emphasis.

Fixes https://orgmode.org/list/23707.20428.546749.44...@frac.u-strasbg.fr
---
 lisp/org.el | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3546e7edd..1551986f6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5096,8 +5096,14 @@ (defun org-do-emphasis-faces (limit)
 		   ;; Match full emphasis markup regexp.
 		   (looking-at (if verbatim? org-verbatim-re org-emph-re))
 		   ;; Do not span over paragraph boundaries.
-		   (not (string-match-p org-element-paragraph-separate
-	(match-string 2)))
+		   (not (save-match-data
+(save-excursion
+  (goto-char (match-beginning 2))
+  (re-search-forward org-element-paragraph-separate
+ (save-excursion
+   (goto-char (match-end 2))
+   (line-end-position))
+ 'noerror
 		   ;; Do not span over cells in table rows.
 		   (not (and (save-match-data (org-match-line "[ \t]*|"))
 			 (string-match-p "|" (match-string 4))
-- 
2.32.0

Re: org-capture-template with changing heading (including a TIMESTAMP)

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>> ("mg" "Exercicios Annu21: asignados"
>> table-line (file+headline "~/somefile.org" "Exercicios Annu21: asignados")
>> 
>> However in that file I also want a header of the form 
>> 
>> * Exercicios Annu21: asignados <2021-03-19 vie 09:48>
>> 
>> That is a changing timestamp in the heading. How can I achieve that for
>> my template?

> If you want to create a new heading with the timestamp, you can use
> file+function as your target in the template (see org-capture-templates
> docstring).

Thanks

I tried 

("mg" "Ejercicios Annu21: hechos, solicitados y asignados"
 table-line (file+function 
"~/ALLES/HGs/tex/vorlesungen/HGAnnu/Ejercios-Alumnos-Grupos/2021/Ejercios-Teoria21.org"
 "Ejercicios Annu21: hechos, solicitados y asignados" (clock))
 "| |%^{Grp|1|2|3|4|5|6|7|8}  |%^{Hj|1|2|3|4|5|6|7} 
|%^{Ej-As|1|2|3|4|5} |%^{Tit}| | [] | |   | %:fromname| |%:fromaddress |  
%(my-extract-cc)  |%:subject | %:date |%a | "  :prepend t :empty-lines 1 
:unnarrowed t
 )

But it does not work, I receive the error 


org-capture-set-target-location: Invalid capture target specification: 
(file+function 
"~/ALLES/HGs/tex/vorlesungen/HGAnnu/Ejercios-Alumnos-Grupos/2021/Ejercios-Teoria21.org"
 "Ejercicios Annu21: hechos, solicitados y asignados" (clock))

I also tried clock instead of clock.

I most likely misunderstood you.


> If you want to change the existing heading, you can use file+regexp as
> target and add a function modifying your heading to
> org-capture-before-finalize-hook

> You may also try https://github.com/progfolio/doct to make the above a
> little simpler.

I try that thanks

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

[PATCH] Improve formatting and documentation inline source block [9.3 (release_9.3 @ /usr/local/share/emacs/28.0.50/lisp/org/)]

[Ihor Radchenko]

dalanicolai  writes:

> This bug report contains two requests/bugs about inline source blocks
> namely:
>
> 1. Inline source blocks don't get formatted/propertized within
> org buffers.

There is now patch under review to fix this:
https://list.orgmode.org/87h7dy7f68.fsf@localhost/T/#t

> 2. Different from ordinary source blocks, the inline source blocks
> require the [:exports code] argument to get exported. I think it would
> be useful to mention it explicitly in [section 15.2 of the
> documentation](https://orgmode.org/manual/Structure-of-Code-Blocks.html),
> because it is somewhat unexpected behavior (compared to ordinary source
> blocks).

I agree that current manual is confusing.  The attached patch.

Dear all,

Maybe we also want to mention org-babel-default-inline-header-args in
the manual?  In addition to org-babel-default-header-args.

Best,
Ihor

>From 4f04548dc94549b9e50f6598636632e67715d9b8 Mon Sep 17 00:00:00 2001
Message-Id: <4f04548dc94549b9e50f6598636632e67715d9b8.1633245750.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Sun, 3 Oct 2021 15:20:18 +0800
Subject: [PATCH] orgmanual-org: Mention results export as default for inline
 src blocks

* doc/org-manual.org (Exporting Code Blocks): Clarify that results are
exported by default for inline source blocks.

The issue has been reported in https://orgmode.org/list/CACJP=3n_8tqzbz7ghmd+f44npptlby31htxhxrhselxtemo...@mail.gmail.com
---
 doc/org-manual.org | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b25da7889..6403b5e69 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18002,10 +18002,11 @@ ** Exporting Code Blocks
 It is possible to export the /code/ of code blocks, the /results/ of
 code block evaluation, /both/ the code and the results of code block
 evaluation, or /none/.  Org defaults to exporting /code/ for most
-languages.  For some languages, such as ditaa, Org defaults to
-/results/.  To export just the body of code blocks, see [[*Literal
-Examples]].  To selectively export sub-trees of an Org document, see
-[[*Exporting]].
+languages and /results/ for inline code blocks.  For some languages,
+such as ditaa, Org defaults to /results/ both in ordinary source
+blocks and in inline source blocks.  To export just the body of code
+blocks, see [[*Literal Examples]].  To selectively export sub-trees of an
+Org document, see [[*Exporting]].
 
 #+cindex: @samp{exports}, header argument
 The =exports= header argument is to specify if that part of the Org
-- 
2.32.0

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Ihor Radchenko  writes:

> Let me bump this thread again and mark it as a patch ;)

Thanks for the bump. I'd like to get this working, but I don't know how best to
deal with the "prettification" of {{{results(=value=)}}}, which is the major 
blocker as I
see it.

Other than that, this all works fantastically as far as I can tell from a few
months of usage of my branch of Org .

--
Timothy

Re: [PATCH] Fontification for inline src blocks

[Ihor Radchenko]

Timothy  writes:

> Hi All,
>
> I've been using inline src blocks a fair bit more recently, and I've
> thought it's a pity how bad they look as they are currently without
> fontification. A little digging into Org internals and font-lock later
> and we have this patch. I could speak about what's been done, but I
> think a screenshot does a much better comparison.

Let me bump this thread again and mark it as a patch ;)

Re: Changing the environment before calling source block?

[Ihor Radchenko]

"Loris Bennett"  writes:

> Hi,
>
> I have multiple versions of each of various languages such as Python
> or R.  On the command line I can select a version using the 'module'[1]
> mechanism provided by Lmod[2]:
>
> My question is: How do I change the environment, ideally call 'module
> load ...' but potentially just set environment variables, before calling
> a source block?

It depends on source block language.  For Python, there is :python
header arg where you can specify python command to be used.  I am not
sure about R

More generally, you can advice org-babel-execute-src-block and wrap it
into something like with-environment-variables macro (available in
newest Emacs).

Or you can write a bash source block, set envitonment there as usual,
and invoke your Python/R script using noweb.

Hope it helps.

Best,
Ihor

Re: org-capture-template with changing heading (including a TIMESTAMP)

[Ihor Radchenko]

Uwe Brauer  writes:

> ("mg" "Exercicios Annu21: asignados"
> table-line (file+headline "~/somefile.org" "Exercicios Annu21: asignados")
>
> However in that file I also want a header of the form 
>
> * Exercicios Annu21: asignados <2021-03-19 vie 09:48>
>
> That is a changing timestamp in the heading. How can I achieve that for
> my template?

If you want to create a new heading with the timestamp, you can use
file+function as your target in the template (see org-capture-templates
docstring).

If you want to change the existing heading, you can use file+regexp as
target and add a function modifying your heading to
org-capture-before-finalize-hook

You may also try https://github.com/progfolio/doct to make the above a
little simpler.

Hope it helps.

Best,
Ihor

Re: [PATCH] Include support for evaluating julia code

[陈贤文]

Dear Pedro,

Thank you!

I'm wondering if 
https://github.com/phrb/ob-julia/blob/master/ob-doc-template.org is up 
to date? By up to date I mean will the examples in the file work with 
the latest ob-julia as in https://github.com/phrb/ob-julia?


Yours sincerely,

Xianwen

 Original Message 

SUBJECT:
Re: [PATCH] Include support for evaluating julia code

DATE:
2021-09-24 20:31

FROM:
Pedro Bruel 

TO:
Timothy 

Hi Timothy,

Thanks for the reply! I am submitting a modded version the of the 
original ob-julia.el, where I had fixed the bugs I encountered and 
updated the interface with org-mode.
I've been using the version on https://github.com/phrb/ob-julia for a 
while now, mainly to write programming classes using julia.


Yours and Nicolò's version seems good though, I think you should submit 
it when you consider it ready. In the meantime, what do we do?


Thanks,
Pedro

Le ven. 24 sept. 2021 à 17:08, Timothy  a écrit :


Hi Pedro,

Thanks for your patch, it's great to see the interest in Julia support 
and it's something that I absolutely think should be in org-core . 
However, ob-julia.el was moved into org-contrib because it was not well 
maintained, and very buggy. I'm actually currently working on a 
successor with Nicolò (see the linked repo) in my free time, and intend 
to submit that to Org when I feel it is mature enough. See 
https://github.com/nico202/ob-julia/ for more information.


All the best,
Timothy

From: Pedro Bruel
Subject: [PATCH] Include support for evaluating julia code
To: Org-mode
Date: Sat, 25 Sep 2021 03:56:43 +0800

Hi,

This patch includes ob-julia.el from org-contrib, and a tentative 
test-ob-julia.el test file.
This is my first attempt at a patch, so please let me know if there's 
anything wrong!


Thanks,
Pedro

Re: Worg footnotes

[Thomas S. Dye]

Bastien  writes:

> Hi Thomas,
>
> "Thomas S. Dye"  writes:
>
>> Worg footnotes are oddly formatted for me.
>
> This should be fixed now.
>
> See https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-gnuplot.html
>
> Thanks!

Nice.  Thanks!

All the best,
Tom

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