Re: How to expand macro in LaTeX export? How to use different options per export type?

[Greg Minshall]

Jean Louis,

another thing that i find helpful in understanding the tao of export: if
you haven't, look at the help string for the variable
~org-export-options-alist~: [C-h v org-export-options-alist].

cheers, Greg

Re: How to expand macro in LaTeX export? How to use different options per export type?

[Greg Minshall]

Jean Louis,

when publishing, one presents a data structure
~org-publish-project-alist~ that defines the back ends and options for
publishing actions.  the options are here:

https://orgmode.org/manual/Publishing-options.html#Publishing-options


below is an example.  as you can see, publishing to different back ends
can have different values for a given option.  (well, not that i do it
that much here...)

cheers, Greg

  (setq org-publish-project-alist
'(("ess-org-html"
   :with-toc nil
   :base-directory "./"
   :publishing-directory "./artefacts"
   :exclude ".*"
   :include ("ess-org.org")
   :publishing-function org-html-publish-to-html)
  ("ess-org-pdf"
   :with-toc nil
   :base-directory "./"
   :publishing-directory "./artefacts"
   :exclude ".*"
   :include ("ess-org.org")
   :publishing-function org-latex-publish-to-pdf)
  ("ess-org-beamer-html"
   :with-toc nil
   :base-directory "./"
   :publishing-directory "./artefacts"
   :exclude ".*"
   :include ("ess-org-beamer.org")
   :publishing-function org-html-publish-to-html)
  ("ess-org-beamer-pdf"
   :with-toc nil
   :base-directory "./"
   :publishing-directory "./artefacts"
   :exclude ".*"
   :include ("ess-org-beamer.org")
   :publishing-function org-beamer-publish-to-pdf)
  ("ess-org" :components ("ess-org-html"
  "ess-org-pdf"
  "ess-org-beamer-html"
  "ess-org-beamer-pdf"

Re: Using backticks for the inline code delimeter?

[Greg Minshall]

George and all,

whether it's the right thing to do or not, i don't know.  but, i'm very
sympathetic to the urge.  even when posting to the list, the reflex to
use back ticks is strong.

Greg

Re: Using backticks for the inline code delimeter?

[Bill Burdick]

Grepping for src_ in *.el in the org distro shows 11 hits over 3 files:
ob-core.el, ob-exp.el, and org-element.el. That's where you can start
working if you want to copy those functions into your init files and modify
them for yourself, or you can see if maybe using function advice is
sufficient.

It's your emacs config, you can modify it however you want, if what you
want is to write the code yourself.


If you want someone else to write the code for you, however, you'll have to
convince someone to do it.

If you want someone else to write the code for you and also adopt it
into the main distro, that's an even tougher task...


-- Bill


On Wed, Mar 31, 2021 at 1:50 PM George Mauer  wrote:

> Markdown uses backticks to denote inline code which should get special
> (typically monospace) formatting, org uses the tilde character.
>
> Now I know that org is not markdown, is far more powerful than markdown,
> and is not (mostly) the same use cases as markdown. But this one use case
> *does* overlap. And the backticks thing is becoming so ingrained that not
> only do I reach for it all the time, but I've seen it crop up on this very
> mailing list and even in some README.org documents.
>
> I would like to submit that org consider adopting backticks as an
> alternate way of denoting inline code.
>
> Aside from any official movement, I would like to add this to my own files
> - is there a straightforward way to extend the org parser to do this?
>

Re: Using backticks for the inline code delimeter?

[Samuel Wales]

just personal opinion but i wouldn't want org's syntax to get more
heterogeneous and non-orthogonal/non-factored.

i could see room for an orthogonal/factored flexible syntax, like
"parsing risk" and "extensible syntax" threads on this ml.  this would
be the one syntax to rule them all, /vaguely/ similar to how you can
do stuff with cl's parser

...which here would require user-definability so that the user can
specify that $[emphasis :type 'code :hide t :marker ?`] shows as `.

the general idea would be desirable if new syntax is needed, but if it
is only used for this purpose it would imo be overkill*n.


On 3/31/21, Tim Cross  wrote:
>
> "Dr. Arne Babenhauserheide"  writes:
>
>> George Mauer  writes:
>>> - lists with dashes, org supports that just fine
>>
>> or stars (not possible with org) or plus (in org).
>>
>>> *bold text* with stars, again org already does this
>>
>> Note that this does not match markdown: Markdown uses *emphasis* and
>> **strong**.
>>
>>> `backtick code`, org doesn't handle this and actually uses the tilde as
>>> a
>>> delimeter which is extra jarring since its a strikethrough in many chat
>>> apps
>>
>> tilde or equals.
>>
>> - list
>> *bold*
>> =code=
>>
>> Adding more syntax is a slippery slope, because then `foo` can never be
>> used for anything else, and there is a limited amount of usable syntax
>> elements.
>>
>
> Yes, I think this is potentially a bad idea. Org parsing is already slow
> enough without adding yet more syntax and font-locking complexity.
>
> I also suspect this is not as simple as just adding this to org parsing
> - all backends and many contributed packages would likely also need to
> be updated to understand the new syntax. So probably not a trivial
> change and a change which is likely to have real impact wrt backwards
> compatibility.
>
> Part of the issue here is that there is no markdown 'standard'. There
> are a number of markdown 'flavors' or dialects. Org is just another one
> (and one of the older ones at that).
>
> --
> Tim Cross
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Using backticks for the inline code delimeter?

[Tim Cross]

"Dr. Arne Babenhauserheide"  writes:

> George Mauer  writes:
>> - lists with dashes, org supports that just fine
>
> or stars (not possible with org) or plus (in org).
>
>> *bold text* with stars, again org already does this
>
> Note that this does not match markdown: Markdown uses *emphasis* and 
> **strong**.
>
>> `backtick code`, org doesn't handle this and actually uses the tilde as a
>> delimeter which is extra jarring since its a strikethrough in many chat apps
>
> tilde or equals.
>
> - list
> *bold*
> =code=
>
> Adding more syntax is a slippery slope, because then `foo` can never be
> used for anything else, and there is a limited amount of usable syntax
> elements.
>

Yes, I think this is potentially a bad idea. Org parsing is already slow
enough without adding yet more syntax and font-locking complexity.

I also suspect this is not as simple as just adding this to org parsing
- all backends and many contributed packages would likely also need to
be updated to understand the new syntax. So probably not a trivial
change and a change which is likely to have real impact wrt backwards
compatibility.

Part of the issue here is that there is no markdown 'standard'. There
are a number of markdown 'flavors' or dialects. Org is just another one
(and one of the older ones at that). 

-- 
Tim Cross

Re: Using backticks for the inline code delimeter?

[Dr. Arne Babenhauserheide]

George Mauer  writes:
> - lists with dashes, org supports that just fine

or stars (not possible with org) or plus (in org).

> *bold text* with stars, again org already does this

Note that this does not match markdown: Markdown uses *emphasis* and **strong**.

> `backtick code`, org doesn't handle this and actually uses the tilde as a
> delimeter which is extra jarring since its a strikethrough in many chat apps

tilde or equals.

- list
*bold*
=code=

Adding more syntax is a slippery slope, because then `foo` can never be
used for anything else, and there is a limited amount of usable syntax
elements.

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


signature.asc
Description: PGP signature

Re: Using backticks for the inline code delimeter?

[George Mauer]

The point I'm making is that this is already the de-facto thing. People on
this email list do it, people in talking in irc and in forums do it. I
don't think it has so much to do with markdown documents as it does with
Slack, Discord, Teams, even google chat adopting that convention. All our
fingers are getting trained to backticks everywhere *except* org documents.
As those already have trained us to use this construction, it might be a
good idea to just swallow the pill.

I don't think there's much of a slippery slope here. Most popular chat
programs don't support making headings markdown-style for example, and even
if they did I don't see many people attempting to use that.

Trying to enumerate syntax that I feel falls squarely in this category I
come up with only a few

- lists with dashes, org supports that just fine
*bold text* with stars, again org already does this
`backtick code`, org doesn't handle this and actually uses the tilde as a
delimeter which is extra jarring since its a strikethrough in many chat apps

That's really it. You could maybe also argue
> gt for quotation - that would be be nice as we're used to it from email
as well, but I don't see people using it all that much

but that's really it as far as common usage right now. Sure that list might
grow as different usages become common, but I would hope org is not against
evolving in small and reasonable ways as the expectations of users shift.

On Wed, Mar 31, 2021 at 3:31 PM Diego Zamboni  wrote:

> The approach I've taken is to try and stop using Markdown altogether and
> write everything in Org, exporting to Markdown for those destinations that
> need it.
>
> You could even use https://github.com/tecosaur/org-pandoc-import to
> automatically convert/reconvert other formats as needed, and
> https://github.com/tecosaur/emacs-everywhere to do it even in other
> applications.
>
> It's not perfect - I still have to type Markdown sometimes, but you
> can eventually start losing the ingrained backtick habit :)
>
> --Diego
>
>
>
> On Wed, Mar 31, 2021 at 8:49 PM George Mauer  wrote:
>
>> Markdown uses backticks to denote inline code which should get special
>> (typically monospace) formatting, org uses the tilde character.
>>
>> Now I know that org is not markdown, is far more powerful than markdown,
>> and is not (mostly) the same use cases as markdown. But this one use case
>> *does* overlap. And the backticks thing is becoming so ingrained that not
>> only do I reach for it all the time, but I've seen it crop up on this very
>> mailing list and even in some README.org documents.
>>
>> I would like to submit that org consider adopting backticks as an
>> alternate way of denoting inline code.
>>
>> Aside from any official movement, I would like to add this to my own
>> files - is there a straightforward way to extend the org parser to do this?
>>
>

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Berry, Charles]

> On Mar 31, 2021, at 9:41 AM, Timothy  wrote:
> 
> I anticipate that this change may be somewhat contentions because ox-md
> explicitly follows only the original Markdown spec from 2003, however
> I've thought this over and come to the conclusion that this change is
> still in keeping with that, and beneficial.


Will this handle LaTeX macros[1] gracefully and other things intended as raw 
LaTeX?

Best,
Chuck

[1] https://pandoc.org/MANUAL.html#latex-macros

Re: Using backticks for the inline code delimeter?

[Diego Zamboni]

The approach I've taken is to try and stop using Markdown altogether and
write everything in Org, exporting to Markdown for those destinations that
need it.

You could even use https://github.com/tecosaur/org-pandoc-import to
automatically convert/reconvert other formats as needed, and
https://github.com/tecosaur/emacs-everywhere to do it even in other
applications.

It's not perfect - I still have to type Markdown sometimes, but you
can eventually start losing the ingrained backtick habit :)

--Diego



On Wed, Mar 31, 2021 at 8:49 PM George Mauer  wrote:

> Markdown uses backticks to denote inline code which should get special
> (typically monospace) formatting, org uses the tilde character.
>
> Now I know that org is not markdown, is far more powerful than markdown,
> and is not (mostly) the same use cases as markdown. But this one use case
> *does* overlap. And the backticks thing is becoming so ingrained that not
> only do I reach for it all the time, but I've seen it crop up on this very
> mailing list and even in some README.org documents.
>
> I would like to submit that org consider adopting backticks as an
> alternate way of denoting inline code.
>
> Aside from any official movement, I would like to add this to my own files
> - is there a straightforward way to extend the org parser to do this?
>

Re: How to expand macro in LaTeX export? How to use different options per export type?

[Jean Louis]

* Greg Minshall  [2021-03-31 14:33]:
> Jean Louis,
> 
> > Another issue related to this setup is that I would like:
> > 
> > - for HTML export: title:t toc:t
> > 
> > - for LaTeX PDF export: title:nil toc:nil
> > 
> > Is there way to have options different for different exports?
> 
> sometimes "publishing" gives me easier control over options than
> "exporting".  in case that might help.

Greg, help me understand that.

-- 
Jean

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

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: fuzzy link can't be exported when \begin{foo} is there

[James Powell]

Thank you Kyle.  I can see how using the latex environments the way I 
did caused the table part to not be org-mode at all any more.  I didn't 
realize org behaved that way, and the workaround of using #+LATEX works 
wonderfully.


Incidentally would not org-mode benefit from a bug tracker? Ordinarily 
here I would say "close the bug" but this is close enough I hope?


- JP

On 3/29/21 9:45 PM, Kyle Meyer wrote:

James Powell writes:


First time poster, long time user.  Glad to be here.

Welcome.


This seems to a bug.

[...]

When I add some latex in the middle:
<>
In Table [[tableOne]] I show that this site has AADT 143925, by
TVT_Detailed_2019.xlsx.

\begin{landscape}
#+NAME: tableOne
#+CAPTION: Site 26016 has AADT 143925.
| SITE_ID | LRM  |  BEGMP |  ENDMP | CLASS_01 | [...] |   AADT |
K_FACTOR | D_FACTOR | Ton_Factor |
|   26016 | 00100I00 | 297.31 | 298.93 | 0.11 | [...] | 143925
|  7.5 |   52 |  4 |
\end{landscape}
<>
I expect it to keep on working.  But instead, now I get

:  1 high  Unknown fuzzy location "tableOne"
in org-lint.  Latex export reports "BROKEN LINK".

I believe the above text is sent as is (i.e. that won't be processed as
an Org table).  Calling org-element-at-point on it reports that it's a
latex-environment.

Perhaps you want

--8<---cut here---start->8---
#+LATEX: \begin{landscape}
#+NAME: tableOne
#+CAPTION: Site 26016 has AADT 143925.
| SITE_ID | LRM  |  BEGMP |  ENDMP | CLASS_01 | [...] |   AADT | K_FACTOR | 
D_FACTOR | Ton_Factor |
|   26016 | 00100I00 | 297.31 | 298.93 | 0.11 | [...] | 143925 |  7.5 | 
  52 |  4 |
#+LATEX: \end{landscape}
--8<---cut here---end--->8---


Incidentally I started this bug report with org-mode 9.3.6.  Back in
9.3.6, it was worse: not only would org-lint report 'unknown fuzzy'
and latex export say "BROKEN LINK" but also C-c C-o
(org-open-at-point) would fail to find the target and make the jump.

The type error was guarded against with 3bb073b63 (ol: Fix type error in
org-link-search corner case, 2020-11-30).  There's no name here, so it
then falls back to fuzzy search.
Compare

   (org-element-property :name (org-element-at-point))

in with point on the table in your original snippet and the suggested
one above.


--
James E. Powell, MS
Pronouns: he/him/his
Applied Physics PhD Candidate
Department of Physics
Portland State University
Home page: http://web.pdx.edu/~powellj
Office: SRTC 409B Phone: +1-503-725-8515

Re: Using backticks for the inline code delimeter?

[autofrettage]

> > I would like to submit that org consider adopting backticks as an alternate
> > way of denoting inline code.
>
> Just FYI, this is almost certainly not going to happen.

Perhaps as unlikely as Python adopts 'i' instead of 'j' in complex numbers? It 
looks awful for all but electrical and electronics engineers.

Cheers
Rasmus

Re: Using backticks for the inline code delimeter?

[Timothy]

George Mauer  writes:

> I would like to submit that org consider adopting backticks as an alternate
> way of denoting inline code.

Just FYI, this is almost certainly not going to happen.

--
Timothy

Re: Using backticks for the inline code delimeter?

[Sébastien Miquel]

George Mauer writes:

is there a straightforward way to extend the org parser to do this?


I don't think so. It seems the emphasis markers are hard-coded
in various places.

From a quick look at the code, you'd have to customize
`org-emphasis-alist` and redefine `org-set-emph-re`  and
`org-do-emphasis-faces`. Maybe that'd be enough.


For the cosmetic part, there's this  piece of code from
https://archive.casouri.cat/note/2020/better-looking-verbatim-markup-in-org-mode/index.html
that displays org's `=` and `~` markers as ```.

--
Sébastien Miquel

Re: Using backticks for the inline code delimeter?

[Timothy]

autofrettage  writes:

> Quick and Dirty: Bind key '`' to ~ in Emacs?
>
> (I guess it is clear I haven't thought about the consequences.)

You can add that just to the Org-mode map. That wouldn't be too bad,
there's always C-q.

--
Timothy

Re: Using backticks for the inline code delimeter?

[autofrettage]

Hi,

George> Aside from any official movement, I would like to add this to my own 
files - is there a straightforward way to extend the org parser to do this?

Quick and Dirty: Bind key '`' to ~ in Emacs?

(I guess it is clear I haven't thought about the consequences.)

Cheers
Rasmus

Re: About exporting

[Juan Manuel Macías]

Martin Steffen  writes:

> [...] And last not least; if I ``compile'' the document (firing off latex,
> bibtex, or index or whatever), the compilation runs in the background.
> As far as I do that in org (exporting to pdf), it blocks emacs. Not
> that it's a huge delay even, at least for smaller documents, I hate
> that an editor or some tool is slower than me, it gets on my nerves if
> the computer slows me down.

There is the async-export (C-a) option in org-export-dispatcher.

Anyway, I usually use the latexmk script a lot, even with Org
(combined with Org Publish: I export sub-documents to *tex from Org and
compile later with latexmk the master document. latexmk with the -pvc
options is wonderful.

I agree that AUCTeX is excellent; maybe (IMHO) the best LaTeX editor out
there.

Best regards,

Juan Manuel 

Using backticks for the inline code delimeter?

[George Mauer]

Markdown uses backticks to denote inline code which should get special
(typically monospace) formatting, org uses the tilde character.

Now I know that org is not markdown, is far more powerful than markdown,
and is not (mostly) the same use cases as markdown. But this one use case
*does* overlap. And the backticks thing is becoming so ingrained that not
only do I reach for it all the time, but I've seen it crop up on this very
mailing list and even in some README.org documents.

I would like to submit that org consider adopting backticks as an alternate
way of denoting inline code.

Aside from any official movement, I would like to add this to my own files
- is there a straightforward way to extend the org parser to do this?

Re: About exporting

[Martin Steffen]

> "Eric" == Eric S Fraga  writes:

Eric> On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
>> However, *I would not recommend anyone to use LaTeX for
>> writing*. A light markup language is more comfortable and
>> efficient for me.

Eric> Totally agree!  Although, over the years, I have written many
Eric> papers in LaTeX directly, in the past decade I have
Eric> increasingly relied on org as the writing tool.  It imposes
Eric> much less friction on the creative process and, as you say, it
Eric> enables better management of the writing task.  And, as it
Eric> gives direct access to LaTeX when necessary, you lose nothing
Eric> by writing in org.

I would not go so far as not recommend latex (over org) for _anyone_ at
all. I for my part will stick with latex for a certain documents; for
others, org is better (has to do with the mentioned creative process,
and other advantages).


However, I write papers heavy in  math-notation (in the more theoretical
corners of conmputer science). There is a lot of math discplay (and I
like to rely heavily on macros etc).

For me, part of the preference of latex is the ratio between math and
similar things over ``text''. a blog-like text (not heavy on math), or a
note, or a wiki-like document etc, all that's great with org.

For math-typesetting, that's less of a ``creative flow of ideas
thing''. Of course, as having been mentioned, I can always escape to
latex inline or for displays etc. And I can also import my
macro-definitions etc (and I do that).

But actually, when typing, I think I am faster in latex. There are a
couple of features, I like (and my muscle-memory of my fingers rely in
them) in latex-modes of emacs.

Tab completion for environments and macros, remembering the last
environments I used, support of bibtex (like also completion or showing
the reference). Indentention of environments plus highlighting. And last
not least; if I ``compile'' the document (firing off latex, bibtex, or
index or whatever), the compilation runs in the background. As far as I
do that in org (exporting to pdf), it blocks emacs. Not that it's a
huge  delay even, at least for smaller documents, I hate that an editor
or some tool is slower than me, it gets on my nerves if the computer
slows me down. And there is a final thing which (for me) seem to work
better in latex-mode compared to org. That's jumping to the ``next
error'' with some key stroke. That's important,  LaTeX's own error
output it quite poor, but jumping to error locations is vital.


I would not be surprised if some of that is somehow supported by org as
well (for TeX), only I have not figured it out, or perhaps I was too
lazy to figure it out how. Too lazy because LateX mode works for me fine
even for challenging and long documents (where for simpler ones or where
the focus is not on typesetting org works).

Martin






Eric> And *tables*!  Enough said. :-)

Eric> But, as always, YMMV.

Eric> -- : Eric S Fraga via Emacs 28.0.50, Org
Eric> release_9.4.4-254-g37749c

[PATCH] Wrap LaTeX snippets in $$ with markdown export

[Timothy]

Hi All,

I anticipate that this change may be somewhat contentions because ox-md
explicitly follows only the original Markdown spec from 2003, however
I've thought this over and come to the conclusion that this change is
still in keeping with that, and beneficial.

Currently ox-md simply inherits the output from ox-html's handling of
LaTeX snippets. Needless to say, the original Markdown specification
does not mention LaTeX snippets. As such, by subtly tweaking the output
(either adding $$ or substituting out LaTeX-style \(\) / \[\] for $ /
$$) we are not deviating from the original specification any more than we
already are.

While I don't see any issue with this, I do see some benefits. Namely
that, of the many Markdown variants that now exist, many support LaTeX
snippets, but exclusively in the TeX $$ form. Hence, by applying this
change the overall utility of ox-md is increased.

Let me know what you think,

Timothy

>From b7f1b89a50752398672a642519534818d23c72a4 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Thu, 1 Apr 2021 00:25:41 +0800
Subject: [PATCH] ox-md: Use TeX-style $ math wrapping

* lisp/ox-md.el (org-md-latex-environment, org-md-latex-fragment):
These two new filters wrap LaTeX maths in $ / $$ TeX-style notation.
While ox-md endeavours to adhere to the original Markdown specification,
and not any particular variant, the original specification does not deal
with LaTeX fragments at all, and so this change does not reduce how
faithfully the original specification is followed.
There is a major upside to this though. Of the many Markdown variants
that have emerged, those that support LaTeX very often exclusively
support TeX style notation.  This change thus improves the utility of
the Markdown export for many use cases, and deviates no more from the
original specification that the current method.
---
 lisp/ox-md.el | 28 
 1 file changed, 28 insertions(+)

diff --git a/lisp/ox-md.el b/lisp/ox-md.el
index b6b2c1728..c5c0e05a5 100644
--- a/lisp/ox-md.el
+++ b/lisp/ox-md.el
@@ -100,6 +100,8 @@ (org-export-define-derived-backend 'md 'html
 		 (italic . org-md-italic)
 		 (item . org-md-item)
 		 (keyword . org-md-keyword)
+ (latex-environment . org-md-latex-environment)
+ (latex-fragment . org-md-latex-fragment)
 		 (line-break . org-md-line-break)
 		 (link . org-md-link)
 		 (node-property . org-md-node-property)
@@ -460,6 +462,32 @@ (defun org-md-keyword (keyword contents info)
 (_ (org-export-with-backend 'html keyword contents info
 
 
+ Latex Environment
+
+(defun org-md-latex-environment (latex-environment contents info)
+  "Transcode a LATEX-ENVIRONMENT object from Org to Markdown.
+CONTENTS is nil.  INFO is a plist holding contextual information."
+  (when (plist-get info :with-latex)
+(concat "$$\n"
+(org-html-latex-environment latex-environment contents info)
+"$$\n")))
+
+
+ Latex Fragment
+
+(defun org-md-latex-fragment (latex-fragment contents info)
+  "Transcode a LATEX-FRAGMENT object from Org to Markdown.
+CONTENTS is nil.  INFO is a plist holding contextual information."
+  (when (plist-get info :with-latex)
+(let ((frag (org-html-latex-fragment contents info)))
+  (cond
+   ((string-match-p "^(" frag)
+(concat "$" (substring frag 2 -2) "$"))
+   ((string-match-p "^\\[" frag)
+(concat "$$" (substring frag 2 -2) "$$"))
+   (t (message "unrecognised fragment: %s" frag)
+  frag)
+
  Line Break
 
 (defun org-md-line-break (_line-break _contents _info)
-- 
2.30.1

[PATCH] Add font-lock rule for inline export snippets

[Timothy]

Hello,

The latest in my visually-oriented (mostly) short patch series, adding
basic fontification to inline export snippets --- @@comment:these things@@.

I think fontification for stuff like this is nice because it visually
indicates to the user that they've written out an Org construct, and
haven't just mis-remembered / imagined some syntax.

In future this could be extended to use native fontification for
recognised export formats (like src blocks do), but I think this is a
nice improvement over nothing.

--
Timothy

>From 3584602f88381ab9624c767a83c18cfd93ffeaf0 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 31 Mar 2021 23:47:58 +0800
Subject: [PATCH] org: Add font-lock rule for inline export snippets

* lisp/org.el (org-set-font-lock-defaults): Add font-lock rule for
inline export snippets.
---
 lisp/org.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index f4d069504..240f745c7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5719,6 +5719,11 @@ (defun org-set-font-lock-defaults ()
 	   ;; Description list items
 	   '("^[ \t]*[-+*][ \t]+\\(.*?[ \t]+::\\)\\([ \t]+\\|$\\)"
 	 1 'org-list-dt prepend)
+   ;; Inline export snippets
+   '("\\(@@\\)\\([a-z-]+:\\).*?\\(@@\\)"
+ (1 'font-lock-comment-face t)
+ (2 'org-tag t)
+ (3 'font-lock-comment-face t))
 	   ;; ARCHIVEd headings
 	   (list (concat
 		  org-outline-regexp-bol
-- 
2.30.1

[PATCH] avoid loading major modes when exporting to file

[Timothy]

Hello,

Another little patch, this time a one-liner.
I think the commit description is pretty thorough, so give that a look.
TLDR; it makes `org-export-to-file' behave a bit more nicely.

--
Timothy

>From eb9d7c038dbb9e7a4b89edf61db83a31dda27170 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 31 Mar 2021 23:16:58 +0800
Subject: [PATCH] ox: don't load a major-mode when exporting to file

* lisp/ox.el (org-export-to-file): Prior to this, when
`org-export-to-file' was called it activated the major mode for that
file type based on `auto-mode-alist'.  This can be mildly annoying in
various ways as loading the major mode (1) makes the export take
longer, (2) can produce unwanted "noise" while initialising, namely
warnings and errors related to the mode itself, (3) can produce spurious
files like an .auctex-auto folder.  By locally binding `auctex-auto' to
nil all of these undesirable behaviours can be avoided.
---
 lisp/ox.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index f705bc83a..96d2866dd 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6388,7 +6388,8 @@   (defun org-latex-export-to-latex
   (declare (indent 2))
   (if (not (file-writable-p file)) (error "Output file not writable")
 (let ((ext-plist (org-combine-plists `(:output-file ,file) ext-plist))
-	  (encoding (or org-export-coding-system buffer-file-coding-system)))
+	  (encoding (or org-export-coding-system buffer-file-coding-system))
+  (auto-mode-alist nil))
   (if async
   (org-export-async-start
 	  `(lambda (file)
-- 
2.30.1

Re: How to expand macro in LaTeX export? How to use different options per export type?

[Eric S Fraga]

> Another solution could be if a program in BEGIN_SRC block could
> generate Org inline, so that it gets processed after generation.

Or even an inline src block, e.g. src_elisp{...}, which checks the
/backend/ for export and outputs accordingly.  Search the mailing list
as there have been examples along the way.  I don't have anything at
hand unfortunately.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: How to expand macro in LaTeX export? How to use different options per export type?

[Greg Minshall]

Jean Louis,

> Another issue related to this setup is that I would like:
> 
> - for HTML export: title:t toc:t
> 
> - for LaTeX PDF export: title:nil toc:nil
> 
> Is there way to have options different for different exports?

sometimes "publishing" gives me easier control over options than
"exporting".  in case that might help.

cheers, Greg

Re: How to expand macro in LaTeX export? How to use different options per export type?

[Jean Louis]

* Eric S Fraga  [2021-03-31 13:46]:
> On Wednesday, 31 Mar 2021 at 13:29, Jean Louis wrote:
> > By doing this:
> >
> > @@latex:\def\version{@@ {{{version}}} @@latex:}@@
> >
> > Then {{{version}}} will get expanded in the document, right? As I have
> > hidden then only tags surrounding {{{version}}}.
> 
> Yes.

OK yet it is not doing what I need. The LaTeX definition of new
command is there because I cannot expand macro in LaTeX export
block. But nothing from that definition helps me in HTML.

Another solution could be if a program in BEGIN_SRC block could
generate Org inline, so that it gets processed after generation.

Maybe I could verify if export backend is HTML and then produce lines:

OPTION specific for HTML
and NOT produce LaTeX related lines

or if LaTeX export

OPTION specific for LaTeX
and NOT produce LaTeX related lines

Would that decision be possible in source block?

-- 
Jean

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

Re: How to expand macro in LaTeX export? How to use different options per export type?

[Eric S Fraga]

On Wednesday, 31 Mar 2021 at 13:29, Jean Louis wrote:
> By doing this:
>
> @@latex:\def\version{@@ {{{version}}} @@latex:}@@
>
> Then {{{version}}} will get expanded in the document, right? As I have
> hidden then only tags surrounding {{{version}}}.

Yes.

>> Also, a macro can itself use the @@ directive to provide alternate
>> versions for LaTeX and HTML, as in
>> 
>> #+macro: blah @@html:some HTML codelatex: some LaTeX code@@
>
> I have tried this:
>
> #+OPTIONS: @@html:title:t toc:t@@ @@latex:title:nil toc:nil@@ todo:nil
>
> But it is not working in options. It would be good if it works in OPTIONS.

The reason it can work in the macro but not for options is that the
macro is expanded into the text and then the text is processed as normal
text so the @@ directives are processed.  The options line does not go
through the same processing.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: How to expand macro in LaTeX export? How to use different options per export type?

[Jean Louis]

* Eric S Fraga  [2021-03-31 13:06]:
> On Wednesday, 31 Mar 2021 at 12:40, Jean Louis wrote:
> > But then the line with \def\version{ {{{version}}} } gets shown in
> > HTML export, which is not what I want. How to resolve that?
> 
> Can you surround the line with @@latex: ... @@?
> 
> You might need to do @@latex:\def\version{@@ {{{version}}}
> @@latex:}@@

I did not know this, it looks like a solution in sight. Thank you.

By doing this:

@@latex:\def\version{@@ {{{version}}} @@latex:}@@

Then {{{version}}} will get expanded in the document, right? As I have
hidden then only tags surrounding {{{version}}}.

> Also, a macro can itself use the @@ directive to provide alternate
> versions for LaTeX and HTML, as in
> 
> #+macro: blah @@html:some HTML codelatex: some LaTeX code@@

I have tried this:

#+OPTIONS: @@html:title:t toc:t@@ @@latex:title:nil toc:nil@@ todo:nil

But it is not working in options. It would be good if it works in OPTIONS.

-- 
Jean

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

Re: About exporting

[Eric S Fraga]

On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
> However, *I would not recommend anyone to use LaTeX for writing*. A
> light markup language is more comfortable and efficient for me. 

Totally agree!  Although, over the years, I have written many papers in
LaTeX directly, in the past decade I have increasingly relied on org as
the writing tool.  It imposes much less friction on the creative process
and, as you say, it enables better management of the writing task.  And,
as it gives direct access to LaTeX when necessary, you lose nothing by
writing in org.

And *tables*!  Enough said. :-)

But, as always, YMMV.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: How to expand macro in LaTeX export? How to use different options per export type?

[Eric S Fraga]

On Wednesday, 31 Mar 2021 at 12:40, Jean Louis wrote:
> But then the line with \def\version{ {{{version}}} } gets shown in
> HTML export, which is not what I want. How to resolve that?

Can you surround the line with @@latex: ... @@?

You might need to do @@latex:\def\version{@@ {{{version}}} @@latex:}@@

Also, a macro can itself use the @@ directive to provide alternate
versions for LaTeX and HTML, as in

#+macro: blah @@html:some HTML codelatex: some LaTeX code@@

> Another issue related to this setup is that I would like:

I cannot help you with this unfortunately.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

How to expand macro in LaTeX export? How to use different options per export type?

[Jean Louis]

In this following peculiar setup, I wish to publish the macro value
{{{version}}} inside of the LaTeX source code export. That makes the
first page how I need it, as it displays logo and other matters. But I
cannot use macro replacements in src blocks, right?

That is why I have defined \def\version{ {{{version}}} } that it gets
expanded in LaTeX source code, that works fine, and all is good.

But then the line with \def\version{ {{{version}}} } gets shown in
HTML export, which is not what I want. How to resolve that?

Possible solution would be:

- to somehow be able to expand macros in LaTeX section? Is that
  possible?

- to somehow hide \def\version{ {{{version}}} }in HTML. But I do not
  know how.

Another issue related to this setup is that I would like:

- for HTML export: title:t toc:t

- for LaTeX PDF export: title:nil toc:nil

Is there way to have options different for different exports?

#+TITLE: My title
#+MACRO: version Time-stamp: 
#+AUTHOR: Jean Louis
#+SETUPFILE: 
/home/admin/Programming/git/org-html-themes/setup/theme-readtheorg.setup
#+OPTIONS: title:nil toc:nil todo:nil
\def\version{ {{{version}}} }

#+BEGIN_EXPORT latex
\begin{titlepage}
\begin{center}

{\Huge My title in LaTeX \\ Project by Jean Louis}

%{\Large Some other title, maybe}

\vspace{0.5cm}
{\large Revision: \version{} }

\includegraphics[width=12cm]{/home/graphics/my-logo.jpg}

\end{center}
\end{titlepage}
\tableofcontents
#+END_EXPORT


-- 
Jean

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

Re: org-adapt-indentation not honored prior to Org 9.4?

[Bastien]

Hi,

Kyle Meyer  writes:

> Tim Cross writes:
>
>> one thing I think might help (maybe too late) would be to put the
>> entries for both electric-indent-mode and org-adapt-indentation so that
>> they are together in the release notes as they do interact with each
>> other and often people stop looking once they see one and not the other
>> (they are currently a fair 'distance' apart in the file). 
>
> Thanks for the suggestion.  I'm not sure that it will help, but it's
> easy to do, at least in the Git repo [*], so I've done so in
> d017cdb0a.

Thanks for doing this.

> [*] That of course won't be in effect for the file included with Emacs
> 27.2.  It also won't be at .
> Cc'ing Bastien in case he thinks updating 9.4's Changes.html is
> worth it.

The overall discussion convinced me that `nil' is probably a better
default for `org-adapt-indentation' (instead of `t') so I suggest we
wait for the 9.5 changelog to promote these clarifications.  

(I generally don't like the idea of revising the changelog after the
release even if we had and may well accept exceptions.)

-- 
 Bastien