Re: Please document the caching and its user options

[Jens Lechtenboerger]

On 2024-06-14, Ihor Radchenko wrote:

> Eli Zaretskii  writes:
>
>> Please document the caching features of Org in the manual, including
>> how to turn that off.  (I also question the wisdom of turning this on
>> by default without as much as a single request for confirmation from
>> the user.)
>
> Hmm. What aspect of caching do you want us to document?
> FYI, Org mode has been doing various forms of caching since
> forever. Recently, we just employed a bit more regular API and
> introduced one more kind of caching - parser cache. In addition to the
> previously existing image cache, publishing cache, ID cache, clock
> cache, etc.

Jumping in here, I do not understand the publishing cache.  Some of
my org documents are re-published every time, while others are only
re-published after changes.  What is checked where?

Best wishes,
Jens


smime.p7s
Description: S/MIME cryptographic signature

[BUG] Org export fails on $k$-ary

[Jens Lechtenboerger]

Dear all,

I would expect this to be exported to HTML and LaTeX correctly:
"A $k$-ary function has $k$ arguments"

In 12.5.1 LaTeX fragments, this use of a hyphen is documented:
"To avoid conflicts with currency specifications, single ‘$’
characters are only recognized as math delimiters if the enclosed text
contains at most two line breaks, is directly attached to the ‘$’
characters with no whitespace in between, and if the closing ‘$’ is
followed by whitespace, punctuation or a dash."

However, the HTML export result contains
"A $k$-ary function has \(k\) arguments",
which is not rendered correctly.  The first two dollar signs should
be replaced as well.

The LaTeX result contains "A \$k\$-ary ...", which produces literal
dollar signs, not math mode.

In contrast, "A \(k\)-ary..." works.

This happens with Org mode version 9.6.15 and with
9.7-pre (release_9.6.24-1336-gc8d133 @ ...).

Recipe:
emacs -Q
(add-to-list 'load-path "~/src/org-mode/lisp")
Then export an Org buffer/file with the above line:
C-c C-e h h
C-c C-e l l

Best wishes,
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Suggestions for Text-To-Speech (TTS) from Org sources?

[Jens Lechtenboerger]

On 2023-09-28, Jude DaShiell wrote:

> espeak-ng likes to have speechdispatcher on a system

Does this improve the quality of the generated speech?

> and festival likes to have language-specific voices on it to use.

Indeed.  Which one(s) do you recommend?  I tried
voice_cmu_us_slt_arctic_hts and the mbrola us voices.

> fenrir which you didn't mention runs in user land and has no kernel
> dependencies.

I briefly tried that but failed.  Also, I was under the impression
that fenrir does produce speech by itself but relies on some TTS
implementation like espeak.  Is that wrong?

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Suggestions for Text-To-Speech (TTS) from Org sources?

[Jens Lechtenboerger]

Dear all,

some time ago I asked for suggestions concerning Text-To-Speech
(TTS) from Org sources.  Thank you to everyone who provided
suggestions!  In case you are interested, you can listen to sample
results at [1].

Briefly, Emacspeak, espeak-ng, and festival are not good enough for
my purposes.  Maybe I'm missing relevant backend options.  IMHO,
Coqui-AI TTS [2] and Microsoft SpeechT5 [3] are far superior.

Best wishes
Jens

[1] https://gitlab.com/oer/emacs-reveal/-/wikis/Sample-TTS-results
[2] https://github.com/coqui-ai/TTS/
[3] https://huggingface.co/microsoft/speecht5_tts

Re: Suggestions for Text-To-Speech (TTS) from Org sources?

[Jens Lechtenboerger]

Thank you for the additional pointers!  I still need to check out
promising combinations of those approaches, also options for MBROLA
(which is not free, but applies a custom AGPL-3.0-but-not-be-sold
license to the voices).  ADRIANE is certainly fascinating.

Best wishes
Jens

On 2023-09-11, briangpowell wrote:

> * eSpeak seems to focus on small footprints & a "format synthesis" method
>
> * Suggest using Festival with MBrola:
>
> https://www.cstr.ed.ac.uk/projects/festival/mbrola.html
>
> https://www.cstr.ed.ac.uk/projects/festival/
>
> and/or just install FestivalLite:
>
> apt-get install -f -y --force-yes flite
>
> * Note EmacSpeak {mentioned in another email} is written by OrgMode user &
> programmer TV Raman--not sure EmacSpeak will help you at all; but it might
> be interesting for you
>
> ** Klaus Knopper distributes some very interesting free software that
> includes an audio-desktop called ADRIANE that maybe you can look at--I'd
> love to hear what you find out if you do:
>
> https://www.knopper.net/knoppix-adriane/index-en.html
>
> ** Knopper invented the "run Linux entirely from a cdrom" craze--which
> still is very useful in many ways--suggest you give Knoppix & Adriane a look
>
> On Mon, Sep 11, 2023 at 4:02 AM Christian Thäter  wrote:
>
>> On Sun, 10 Sep 2023 16:39:26 +0200
>> Jens Lechtenboerger  wrote:
>>
>> > On 2023-09-10, Ihor Radchenko wrote:
>> >
>> > > Jens Lechtenboerger  writes:
>> > >
>> > >> does someone here produce audio via Text-To-Speech (TTS) from Org
>> > >> sources?  I plan to do that in the context of emacs-reveal to
>> > >> generate voice-over for reveal.js presentations, with open
>> > >> questions [1] concerning my initial, experimental approach.
>> > >
>> > > Emacspeak is a mature Emacs solution for TTS. However, it aims blind
>> > > users, not presentations. Still,
>> > > http://tvraman.github.io/emacspeak/manual/Quick-Installation.html
>> > > might be a good starting point for TTS options.
>> >
>> > Thank you for the suggestion.  With espeak this indeed pronounces
>> > numbers and abbreviations but its audio quality it not good enough
>> > for my purposes.  I am looking for (near-) human voices...
>>
>> using mbrola is probably as good as possible with free software:
>> https://en.wikipedia.org/wiki/MBROLA
>>
>> still not perfect, but much better than the builtin voices of espeak or
>> festival (YYMV).
>>
>> >
>> > Best wishes
>> > Jens
>> >
>>
>>
>>


smime.p7s
Description: S/MIME cryptographic signature

Re: Suggestions for Text-To-Speech (TTS) from Org sources?

[Jens Lechtenboerger]

On 2023-09-10, Christian Thäter wrote:

> On Sun, 10 Sep 2023 16:39:26 +0200
> Jens Lechtenboerger  wrote:
>
>> On 2023-09-10, Ihor Radchenko wrote:
>> 
>> > Jens Lechtenboerger  writes:
>> >  
>> >> does someone here produce audio via Text-To-Speech (TTS) from Org
>> >> sources?  I plan to do that in the context of emacs-reveal to
>> >> generate voice-over for reveal.js presentations, with open
>> >> questions [1] concerning my initial, experimental approach.  
>> >
>> > Emacspeak is a mature Emacs solution for TTS. However, it aims blind
>> > users, not presentations. Still,
>> > http://tvraman.github.io/emacspeak/manual/Quick-Installation.html
>> > might be a good starting point for TTS options.  
>> 
>> Thank you for the suggestion.  With espeak this indeed pronounces
>> numbers and abbreviations but its audio quality it not good enough
>> for my purposes.  I am looking for (near-) human voices...
>
> using mbrola is probably as good as possible with free software:
> https://en.wikipedia.org/wiki/MBROLA
>
> still not perfect, but much better than the builtin voices of espeak or
> festival (YYMV).

This sounds promising.  I’ll check it out.

Many thanks
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Suggestions for Text-To-Speech (TTS) from Org sources?

[Jens Lechtenboerger]

On 2023-09-10, Ihor Radchenko wrote:

> Jens Lechtenboerger  writes:
>
>> does someone here produce audio via Text-To-Speech (TTS) from Org
>> sources?  I plan to do that in the context of emacs-reveal to
>> generate voice-over for reveal.js presentations, with open questions
>> [1] concerning my initial, experimental approach.
>
> Emacspeak is a mature Emacs solution for TTS. However, it aims blind
> users, not presentations. Still,
> http://tvraman.github.io/emacspeak/manual/Quick-Installation.html might
> be a good starting point for TTS options.

Thank you for the suggestion.  With espeak this indeed pronounces
numbers and abbreviations but its audio quality it not good enough
for my purposes.  I am looking for (near-) human voices...

Best wishes
Jens

Re: Suggestions for Text-To-Speech (TTS) from Org sources?

[Jens Lechtenboerger]

On 2023-09-09, briangpowell wrote:

> I've turned OrgMode files into audio desktops
>
> It was pretty simple
>
> Just find the code that reveals what an icon is when you hover over it &
> pipe it to some text-to-speech engine & then on to usual routes

Thank you for the reply.  In my case (GNU/Linux), I guess that the
usual text-to-speech engine is espeak.  I find its speech quality to
be disappointing (much worse than the language models that I
mentioned earlier).  I am looking for (near-) human quality...

Best wishes
Jens

Suggestions for Text-To-Speech (TTS) from Org sources?

[Jens Lechtenboerger]

Dear all,

does someone here produce audio via Text-To-Speech (TTS) from Org
sources?  I plan to do that in the context of emacs-reveal to
generate voice-over for reveal.js presentations, with open questions
[1] concerning my initial, experimental approach.

Currently, I like the default model of Coqui-AI TTS [2] and
Microsoft SpeechT5 [3] best.  Any suggestions for free and open TTS
implementations that produce even better results?  Other models of
Coqui-AI?  The solution should work without GPU support, which seems
to rule out Suno Bark [4].

The above models do not pronounce numbers/digits, and they fail to
pronounce most acronyms.  In a preprocessing step I could replace
those.  I use preprocessing anyways to get rid of Org markup that
might confuse the language models.  Anyone here who did that
already?  Maybe gruut [5] in conjunction with SSML [6] handling?

Any other suggestions?

Best wishes
Jens

[1] https://gitlab.com/oer/emacs-reveal/-/issues/20
[2] https://github.com/coqui-ai/TTS/
[3] https://huggingface.co/microsoft/speecht5_tts
[4] https://github.com/suno-ai/bark
[5] https://github.com/rhasspy/gruut
[6] https://www.w3.org/TR/speech-synthesis11/

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link?

[Jens Lechtenboerger]

On 2023-09-01, Ihor Radchenko wrote:

> In theory, we might change the parser to treat anything like foo:bar or
>  or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
> And introduce [[::fig:something]] to allow explicit internal links.
> But, despite simplifying the parser, it will certainly be a breaking
> change.

What would the implications be?  FAQ 18.25 [1] contains a recipe to
use colors on text like this: [[color:red][red]]

Would that be a problem?

Also, I use custom link types for additional markup like this:

[[basic:https://en.wikipedia.org/wiki/Cache_(computing)][Caching]]

In both cases, the part before the first colon is certainly no
protocol.

Besides, concerning wording in this discussion: A URIs may or may
not embed a protocol.  It contains a scheme, then a colon, then a
scheme-specific part, see [2].

Best wishes
Jens

[1] https://orgmode.org/worg/org-faq.html
[2] https://datatracker.ietf.org/doc/html/rfc3986

Re: How to tell `org-html-link' to create a link with some HTML class?

[Jens Lechtenboerger]

On 2023-06-20, Marcin Borkowski wrote:

> Dear Orgers,
>
> as I mentioned some time ago, I'm writing a custom exporter (actually,
> a very thin wrapper around the HTML exporter).  I'd like `org-html-link'
> to add some class to the links it generates.  Is that possible?

Dear Marcin,

yes, that’s possible, ":attr_html" is read in `org-html-link'.  You
have to set that in your code, see [1] for an example for classes in
my reveal.js backend.

Briefly, with `elem' being the link, I use this:
`(org-element-put-property elem :attr_html (list newattrs))'

Best wishes
Jens

[1] https://gitlab.com/oer/org-re-reveal/-/blob/master/org-re-reveal.el#L2167

Re: Unicode problem with export of literal contents

[Jens Lechtenboerger]

On 2023-02-20, Bruno Barbier wrote:

> Jens Lechtenboerger  writes:
>
>> On 2023-02-20, Bruno Barbier wrote:
>>
>> However, if I use insert-file-contents-literally with a unicode
>> file, I do *not* have to set the coding-system-for-write.  This just
>> works:
>>
>>(with-temp-buffer
>>   (insert-file-contents-literally "~/unicode.org")
>>   (secure-hash 'md5 (current-buffer)))
>
> Humm. Emacs is amazing: it managed to guess the right encoding, from the
> buffer context, probably...
>
> But, what you are giving to 'org-export-string-as' is not the buffer,
> it's a string. So, let's try the same without using an org function:
>
>  (with-temp-buffer
>(insert (with-temp-buffer
>  (insert-file-contents-literally "~/unicode.org")
>  (buffer-string)))
>(secure-hash 'md5 (current-buffer)))
>
> And, that fails, requesting an encoding.

Thank you for this example.

>> In the context of Org export, secure-hash seems to require a coding
>> system.  Why?
>
> I'm not an expert, so, you'll need to confirm with other sources.  But
> secure-hash requires an encoding in all cases, to compute the hash of
> some text, because it needs the array of bytes that represents that text
> to compute its hash.
>
> I don't see any bug in org, and, I don't see any bug in secure-hash either.
>
> You literally shoud stop using "literally" ;-)

Indeed.  

> And, you might want to read:
>(info "(elisp) Non-ASCII Characters")

The first section was already helpful, thanks!  (I still need to
read more of this...)

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Unicode problem with export of literal contents

[Jens Lechtenboerger]

On 2023-02-20, Bruno Barbier wrote:

> If you're always using utf-8, here is a way to force it so that
> secure-hash can compute the hash. This should work:
>
>(with-temp-buffer
>   (let ((coding-system-for-write 'utf-8))
> (insert "Lechtenb\303\266rger")
> (secure-hash 'md5 (current-buffer

Yes, that works.

However, if I use insert-file-contents-literally with a unicode
file, I do *not* have to set the coding-system-for-write.  This just
works:

   (with-temp-buffer
  (insert-file-contents-literally "~/unicode.org")
  (secure-hash 'md5 (current-buffer)))

In the context of Org export, secure-hash seems to require a coding
system.  Why?

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Unicode problem with export of literal contents

[Jens Lechtenboerger]

On 2023-02-17, Ihor Radchenko wrote:

> Jens Lechtenboerger  writes:

>> Also, when I call secure-hash on the literal buffer-string, no
>> problem arises.
>
> Org is calling secure-hash on buffer. Calling on buffer-string would
> require unnecessary memory allocation to create the string.

I can call secure-hash on the buffer with literally inserted
contents without problems.

>> It is not obvious that Org tries to write something here and why
>> that fails now
>
> Org is not trying to write something. In you example, Org is just trying
> to calculate buffer string hash - nothing wrong on Org side. "Something
> wrong with encoding" way my guess. If you think that your case should be
> perfectly fine, I recommend asking Emacs devs by filing a bug report to
> them.

Thank you for the clarifications.  Probably I have to do that.

For the record, if I insert "Lechtenb\303\266rger" as string into a
buffer, secure-hash asks for a decoding.  If I insert that literally
via an UTF-8 encoded file, secure-hash works.

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Unicode problem with export of literal contents

[Jens Lechtenboerger]

On 2023-02-17, Bruno Barbier wrote:

> Here is a way to reproduce that doesn't use org, in case it might help
> to manully fix your encoding issue:
>
>(with-temp-buffer
>   (insert "Lechtenb\303\266rger")
>   (let ((buffer-file-name (make-temp-file "mailtest")))
> (save-buffer)))
>
> Does it work with your old config (with your old org) ?

This also asks for an encoding.

> What kind of failure do you get elsewhere if you let Emacs use the
> correct encoding (i.e. if you use `insert-file-contents') ?

I want to be sure to use the file contents in unchanged form, as
promised by insert-file-contents-literally.  For now, I copied part
of the code from insert-file-contents-literally to avoid
after-insert processing and file handlers.  I still do not
understand what is happening differently in my case, though...

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Unicode problem with export of literal contents

[Jens Lechtenboerger]

On 2023-02-17, Ihor Radchenko wrote:

> Jens Lechtenboerger  writes:
>
>> With Org 9.6.1 from Emacs master, I get the following warning, and I
>> am asked to select a coding system:
>>
>>> These default coding systems were tried to encode the following
>>> problematic characters in the buffer ‘ *temp*’:
>>> ...
>>
>> With previous Org versions, this did not happen, export would just
>> work.  Note that I insert contents literally because I do not want
>> ‘find-file-hook’, automatic uncompression, etc. (which are avoided
>> according to the doc string of insert-file-contents-literally).
>
> This warning appears upon Org calling `secure-hash'.
> Org is doing nothing wrong here - your file does not have proper encoding.
> You did not see this error in the past by chance.

I was afraid you would say so.  To me, this is a breaking change.

Also, when I call secure-hash on the literal buffer-string, no
problem arises.

> Not a bug. You need to fix your files with improper encoding.

The file has the proper encoding.  I insert literally on purpose as
stated above.

It is not obvious that Org tries to write something here and why
that fails now (I could use the results in exporters writing to
files just fine previously).

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Unicode problem with export of literal contents

[Jens Lechtenboerger]

Hi Bruno,

On 2023-02-17, Bruno Barbier wrote:

> Hi Jens,
>
> Jens Lechtenboerger  writes:
>
>> ...
>> Note that I insert contents literally because I do not want
>> ‘find-file-hook’, automatic uncompression, etc. (which are avoided
>> according to the doc string of insert-file-contents-literally).
>>
>> Could the old behavior be restored?
>
> By using `insert-file-contents-literally' (as opposed to
> `insert-file-contents'), you're also forbidding Emacs to decode the
> binary content of your file into text.
>
> My guess is that it was working by chance in previous versions.

in any case, this will introduce failures elsewhere.

> In case somebody might help you, here is a simple way to trigger the
> encoding question with a recent version of org (mine is Org mode version 
> 9.6.1).
>
>(with-temp-buffer
>   (insert "Lechtenb\303\266rger")
>   (org-mode))

Thank you for the simpler recipe.  This indeed fails now.

So, maybe my question is: Must text be decoded for Org mode from now on?

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Unicode problem with export of literal contents

[Jens Lechtenboerger]

Hi there,

consider this piece code, where unicode-file.org contains umlauts
(say, just the word “Lechtenbörger”):

(org-export-string-as
 (with-temp-buffer
   (insert-file-contents-literally "unicode-file.org")
   (buffer-string))
 'html t)

With Org 9.6.1 from Emacs master, I get the following warning, and I
am asked to select a coding system:

> These default coding systems were tried to encode the following
> problematic characters in the buffer ‘ *temp*’:
> ...

With previous Org versions, this did not happen, export would just
work.  Note that I insert contents literally because I do not want
‘find-file-hook’, automatic uncompression, etc. (which are avoided
according to the doc string of insert-file-contents-literally).

Could the old behavior be restored?

Best wishes
Jens

Re: Syntax question: What is BORDER in 4.17. Text Markup?

[Jens Lechtenboerger]

On 2022-12-07, Timothy wrote:

> Hi Jens,
>
>> Actually, what about this?  Get rid of both, BORDER and BODY, and
>> specify CONTENTS as follows:
>> “Either a string (when MARKER represents code or verbatim) or a
>> series of objects from the standard set, not spanning more than
>> three lines.  In any case, CONTENTS must neither begin nor end with
>> whitespace.”
>
> This seems like an improvement to me, implemented in 56338725e61 :)

Many thanks, Timothy!

Best wishes
Jens

Re: Syntax question: What is BORDER in 4.17. Text Markup?

[Jens Lechtenboerger]

On 2022-12-07, Jens Lechtenboerger wrote:

> On 2022-12-07, Max Nikulin wrote:
>
>> On 07/12/2022 01:28, Jens Lechtenboerger wrote:
>>> Hi there,
>>> the syntax for Text Markup such as *bold* at [1] specifies
>>> PRE MARKER CONTENTS MARKER POST with
>>> CONTENTS as BORDER BODY BORDER and
>>> BORDER as “Any non-whitespace character.”
>>> What is the role of BORDER here?  Does it really exist?
>>
>> I think, the idea is to stress that
>>
>> / / or * word *
>>
>> must not be considered as emphasis.
>
> I see, thanks.
>
>>> What is BORDER if CONTENTS should be a single character, e.g., in
>>> the two strings “*x*” and “~*~”?  Are single characters forbidden?
>>
>> The spec is not precise here. It is close to the code that actually
>> allows single character contents, see
>> `org-element--parse-generic-emphasis' and the docstring of
>> `org-emphasis-regexp-components'.
>>
>> Perhaps it should be stated as (in regexp notation)
>>
>> BORDER (BODY? BORDER)?
>>
>> or as alternatives
>>
>> BORDER or BORDER BORDER or BORDER BODY BORDER.
>
> If find this confusing.  What is BODY (semantically) if two of its
> characters are assigned to BORDERs?
>
> What about getting rid of BORDER in the spec and replacing
> “Where BORDER and BODY are not separated by whitespace.”
> with
> “Where BODY does neither begin nor end with whitespace”?
> (If that is correct...)
>
> The implementation with regexps is a different issue.

Actually, what about this?  Get rid of both, BORDER and BODY, and
specify CONTENTS as follows:
“Either a string (when MARKER represents code or verbatim) or a
series of objects from the standard set, not spanning more than
three lines.  In any case, CONTENTS must neither begin nor end with
whitespace.”

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Syntax question: What is BORDER in 4.17. Text Markup?

[Jens Lechtenboerger]

On 2022-12-07, Max Nikulin wrote:

> On 07/12/2022 01:28, Jens Lechtenboerger wrote:
>> Hi there,
>> the syntax for Text Markup such as *bold* at [1] specifies
>> PRE MARKER CONTENTS MARKER POST with
>> CONTENTS as BORDER BODY BORDER and
>> BORDER as “Any non-whitespace character.”
>> What is the role of BORDER here?  Does it really exist?
>
> I think, the idea is to stress that
>
> / / or * word *
>
> must not be considered as emphasis.

I see, thanks.

>> What is BORDER if CONTENTS should be a single character, e.g., in
>> the two strings “*x*” and “~*~”?  Are single characters forbidden?
>
> The spec is not precise here. It is close to the code that actually
> allows single character contents, see
> `org-element--parse-generic-emphasis' and the docstring of
> `org-emphasis-regexp-components'.
>
> Perhaps it should be stated as (in regexp notation)
>
> BORDER (BODY? BORDER)?
>
> or as alternatives
>
> BORDER or BORDER BORDER or BORDER BODY BORDER.

If find this confusing.  What is BODY (semantically) if two of its
characters are assigned to BORDERs?

What about getting rid of BORDER in the spec and replacing
“Where BORDER and BODY are not separated by whitespace.”
with
“Where BODY does neither begin nor end with whitespace”?
(If that is correct...)

The implementation with regexps is a different issue.

Best wishes
Jens

Syntax question: What is BORDER in 4.17. Text Markup?

[Jens Lechtenboerger]

Hi there,

the syntax for Text Markup such as *bold* at [1] specifies
PRE MARKER CONTENTS MARKER POST with
CONTENTS as BORDER BODY BORDER and
BORDER as “Any non-whitespace character.”

What is the role of BORDER here?  Does it really exist?

What is BORDER if CONTENTS should be a single character, e.g., in
the two strings “*x*” and “~*~”?  Are single characters forbidden?

Best wishes
Jens

[1] https://orgmode.org/worg/org-syntax.html#Emphasis_Markers

Re: index for HTML export

[Jens Lechtenboerger]

On 2022-07-14, Fraga, Eric wrote:

> On Thursday, 14 Jul 2022 at 08:13, Jens Lechtenboerger wrote:
>>   (list "index-terms"
>
> [...]
>
>> :preparation-function 'oer-reveal--add-advice-link
>> :completion-function 'oer-reveal--remove-advice-link
>> :publishing-function '(org-html-publish-to-html)
>> :publishing-directory "./public")
>>
>> So, do you see theindex.org and theindex.inc?  Do you publish the
>> former?
>
> Yes, I do see theindex.org and theindex.inc but there are no index
> entries.

That is strange.  File theindex.inc should contain the index entries.
I believe that “:makeindex t” on the Org source files with #+INDEX:
entries should do the job.

> What do the first two functions listed above do?

They adapt the link format for my specific export backend (to point
to slides of presentations).  That is not relevant in your case.

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: index for HTML export

[Jens Lechtenboerger]

On 2022-07-13, Fraga, Eric wrote:

> Publishing works, in the sense that my org file is exported to HTML just
> fine.  An index file is created but is not populated with any index
> links.  What am I missing?  The info page is less than helpful
> unfortunately.  Are index lines, e.g.
>
> #+index: test!org publishing
>
> processed in any way?

Over here, yes: https://oer.gitlab.io/OS/index-terms.html

I use this in my publish code:

   (list "org-presentations"
 :base-directory "."
 :base-extension "org"
 :makeindex oer-reveal-publish-makeindex
 :exclude 
"index\\|backmatter\\|config\\|course-list\\|license-template\\|imprint\\|privacy\\|README\\|CONTRIBUTING\\|CHANGELOG"
 :publishing-function 
oer-reveal-publish-org-publishing-functions
 :publishing-directory "./public")

where oer-reveal-publish-makeindex is t and my publish.el makes sure
to publish to HTML:
https://gitlab.com/oer/OS/-/blob/master/elisp/publish.el

  (list "index-terms"
:base-directory "."
;; A file theindex.org (which includes theindex.inc)
;; is created due to assignment to
;; oer-reveal-publish-makeindex above.
;; Using that setting, the file is automatically published with
;; org-re-reveal, which is useless.
;; Thus, publish as HTML here.  For this to work, index-terms.org
;; is a manually created file including theindex.inc.
;; The preparation and completion functions below set up an
;; advice on org-html-link to rewrite links into presentations
;; using org-re-reveal's anchor format.
:include '("index-terms.org")
:exclude ".*"
:preparation-function 'oer-reveal--add-advice-link
:completion-function 'oer-reveal--remove-advice-link
:publishing-function '(org-html-publish-to-html)
:publishing-directory "./public")

So, do you see theindex.org and theindex.inc?  Do you publish the
former?

Best wishes
Jens

Re: Publish to HTML and LaTeX/PDF with cross-file links?

[Jens Lechtenboerger]

On 2022-06-16, at 09:55, Tim Cross wrote:

> Jens Lechtenboerger  writes:
>
>> [...]
>> More precisely: For HTML export, a link like
>> [[file:foo.org::#custom-id][elsewhere]] turns into a hyperlink to
>> “foo.html#custom-id”, which is what I want.
>>
>> However, for LaTeX/PDF export, the hyperlink points to the source
>> file “foo.org”, which in my case is a broken link.  I would like
>> that to be “foo.pdf” (or even something pointing at the proper
>> section in the PDF file).
>>
>> Is this (easily) possible?
>>
>
> I think what you need is an export filter function for links in latex
> exports. Have a look at the docstring for variable 
> org-export-filter-link-functions. 
>
> As a very basic example, the following should work
> [...]

Thank you for the suggestion!

I am still undecided which way to go.  Maybe a refactoring of code
from ox-html (to be usable across backends) would be appropriate
here.

Best wishes
Jens

Publish to HTML and LaTeX/PDF with cross-file links?

[Jens Lechtenboerger]

Hi all,

I publish OER (https://oer.gitlab.io/) from Org sources and wonder
about links to local files as documented at [1].  That page only
talks about HTML export.  How can I achieve similar behavior for
LaTeX/PDF export?

More precisely: For HTML export, a link like
[[file:foo.org::#custom-id][elsewhere]] turns into a hyperlink to
“foo.html#custom-id”, which is what I want.

However, for LaTeX/PDF export, the hyperlink points to the source
file “foo.org”, which in my case is a broken link.  I would like
that to be “foo.pdf” (or even something pointing at the proper
section in the PDF file).

Is this (easily) possible?

Best wishes
Jens


[1] https://orgmode.org/manual/Publishing-links.html#Publishing-links

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: modify citation links in a derived HTML backend

[Jens Lechtenboerger]

On 2021-07-03, Matt Price wrote:

> I've added some comments in the issue you linked to, but in the meantime
> I've also come up with what seems to be at least a semi-viable hack for
> adding native CSL citation support to org-re-reveal. It involves creating
> two new variables and then let-setting `citeproc-fmt--formatters-alist` in
> `org-re-reveal-export-to-html`. Something similar could presumably be done
> in other derived backends.
>
> I find it quite hackish and I don't know whether perhaps some more general
> solution could be found, but in any case here is the code, which I have
> inserted into org-re-reveal.el locally:

Thank you for sharing your code, Matt!

What is the general state of this new citation handling with respect
to export backends?  Did you create the settings for HTML from
scratch or did you take inspiration from HTML export functionality?
I guess that basic support should go into ox-html, while small
modifications could than take care of specifics for reveal.js
presentations...

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: modify citation links in a derived HTML backend

[Jens Lechtenboerger]

On 2021-07-02, Matt Price wrote:

> Hi,
>
> (cc:ing Jens L. in case this is relevant for his dev work on org-re-reveal).

Hi Matt,

just a quick reply: Yes, that is certainly relevant for me, but I do
not have the time to investigate this at the moment.  Note that I
use references with org-ref and org-re-reveal-ref (for which Bruce
opened an issue for org-cite support [1]).  Currently, I configure
org-ref-ref-html (although its doc string suggests otherwise).

Best wishes
Jens

[1] https://gitlab.com/oer/org-re-reveal-ref/-/issues/2


smime.p7s
Description: S/MIME cryptographic signature

Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag

[Jens Lechtenboerger]

On 2021-04-20, Tim Visher wrote:

> I guess regardless it sounds like if I were to go to the trouble of making
> a patch for this it would be good to make sure that it was behind an option
> and probably defaulting to the current HEAD behavior of including the ASCII
> markup with an option to strip the non-word characters from it.

That would be great.

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag

[Jens Lechtenboerger]

On 2021-04-19, Kyle Meyer wrote:

> Tim Visher writes:
>
>> Unfortunately, the title now is essentially the exact text of the org
>> heading, which is awkward in terms of readability for a general audience
>> (and probably for SEO etc.). I know I said in my original message that I
>> think stripping all the markup characters would be going too far but now I
>> think I've come full circle and rendering the title as nothing but the
>> plain text without any markup information feels like the right solution
>> given what the title is supposed to convey.
>>
>> So, would we be willing to accept a patch to that effect? :)
>
> I don't have an informed opinion about the above, but providing a patch
> might prompt those that do (including TEC, the author of the above
> commit, as well as Jens, who provided reviews) to give their input.

The following is not a strong opinion: The author writes “what the
title is supposed to convey”.  If there is *emphasis*, why not
export that as ASCII markup to HTML?

With an additional option, authors could choose.

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] tweaks to ox-html style

[Jens Lechtenboerger]

On 2021-02-13, Timothy wrote:

> Jens Lechtenboerger  writes:
>
>> On 2021-02-12, Jens Lechtenboerger wrote:
>>
>>> I do not know why the CDATA lines exist.  I don’t see a reason to
>>> keep them (patch 0001), but that might be a lack of understanding on
>>> my part.
>>
>> OK, that is probably for XHTML, where < and & are only allowed
>> inside CDATA sections.
>>
>> Timothy, did you try to validate XHTML output?
>
> If you look at the commit message for 001, you can see the following:
>
>> remove CDATA strings, as they are now
>> considered obsolete --- see
>> https://developer.mozilla.org/en-US/docs/Web/API/CDATASection#specifications
>
> Does that page clear things up for you?

No, sorry, I don’t get it.  I see:
“Re-added in issue #295 due to web breakage”

> I did a bit more googling and found
> https://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5
> which mentions CDATA:
>
>> The CDATA code is then seen as text by the HTML parser (and can thus
>> interfere with the scripting or styling language!), while the XML
>> parser sees the content as text without markup semantics.
>
> In other words, CDATA allows you to keep XML comparability,

Exactly.  In fact, the “&” in the magnet URI should be “” or
it might be placed into the CDATA section.

> but now breaks strict HTML comparability.

What do you mean?  If I use html5 as HTML_DOCTYPE, the validator at
https://validator.w3.org/nu/ does not complain.

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] tweaks to ox-html style

[Jens Lechtenboerger]

On 2021-02-12, Jens Lechtenboerger wrote:

> I do not know why the CDATA lines exist.  I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.

OK, that is probably for XHTML, where < and & are only allowed
inside CDATA sections.

Timothy, did you try to validate XHTML output?

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] tweaks to ox-html style

[Jens Lechtenboerger]

On 2021-02-12, Kyle Meyer wrote:

> TEC writes:
>
>> Hi All,
>>
>> This is just some tweaks to the styling in ox-html that I think may
>> appeal (and prevent ridiculously long lines on non-small displays, which
>> are an issue for legibility).
>>
>> I also took the opportunity to remove the (obsolete) CDATA strings and
>> make the CSS more consistently formatted. If you don't want this to
>> get its own commit, please just squash it.
>>
>> Style changes:
>> - Restrict max content width, and centre
>> - tweak styling of source code blocks
>
> I'm sure there are plenty of opinionated ox-html users on the list.  Is
> anyone willing to provide feedback on this series?  Please don't assume
> you need commit access to provide reviews.

Hi there,

I do not know why the CDATA lines exist.  I don’t see a reason to
keep them (patch 0001), but that might be a lack of understanding on
my part.

Patch 0003 is about whitespace fixes.

Patches 0002, 0004, 0005 change defconst styling.  I don’t have a
strong opinion here.  However, if they are changed now, what about
turning them into defcustoms?  Then each of us would be entitled to
their own opinion ;)

The docstring for org-html-head-include-default-style says that
org-html-style-default (a defconst proposed to be changed here)
should not be changed.  Why not?

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2021-01-14, TEC wrote:

> TEC  writes:
>
>>> Sorry, I still see the flycheck warning and "amp;" for "&".
>> Maybe I accidently sent you the old patches? I'll check tomorrow.
>
> Hah, I check and guess what I see? The changes were unstaged .
>
> Sorry about that, here's an actual revision.

This looks fine to me.  Many thanks!

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2021-01-10, TEC wrote:

> Jens Lechtenboerger  writes:
>
>> On line 1432 I get this suggestion from flycheck:
>> There should be two spaces after a period (emacs-lisp-checkdoc)
>>
>> More importantly, I just realized that for author information,
>> org-html-plain-text is applied twice, leading to "amp;" when
>> translating "&".  (Once inside org-html-meta-tags-default, then in
>> org-html--build-meta-entry.)  This should not happen.
>>
>> Best wishes
>> Jens
>
> Fixed. [exhales]

Sorry, I still see the flycheck warning and "amp;" for "&".

Please try with: "#+AUTHOR: Foo & Bar"

In org-html-meta-tags-default, function org-html-plain-text replaces
"&" with "", and in org-html--build-meta-entry, function
org-html-encode-plain-text replaces "&" once more.

I suggest to remove org-html-plain-text from
org-html-meta-tags-default.

Best wishes
Jens

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2021-01-04, TEC wrote:

> Jens Lechtenboerger  writes:
>
>> org-html--build-meta-entry and org-html--build-meta-info include some long 
>> lines.
>
> Hehe. We've had a lot of back-and-forth haven't we.
> At least it feels like it's coming to a close now.

On line 1432 I get this suggestion from flycheck:
There should be two spaces after a period (emacs-lisp-checkdoc)

More importantly, I just realized that for author information,
org-html-plain-text is applied twice, leading to "amp;" when
translating "&".  (Once inside org-html-meta-tags-default, then in
org-html--build-meta-entry.)  This should not happen.

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2021-01-03, TEC wrote:

> Jens Lechtenboerger  writes:
>
>> The doc strings of org-html-meta-tags and org-html-meta-tags-default
>> need to be updated, they still mention author and title.
>
> Ah, yep. Fixed.
>
>> Also, please try checkdoc ;)
>
> Ahhh yes.

Actually, I use flycheck (https://www.flycheck.org/), which displays
warnings right away.  org-html--build-meta-entry and
org-html--build-meta-info include some long lines.

For org-html-meta-tags-default, I suggest this as last line for the doc
string (typos, active voice):
Use document's plist INFO to derive relevant information for the tags.

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2021-01-03, TEC wrote:

> After considering the information passed to a meta info generation
> function, I'm now in agreement with you that just passing `info' is the
> most sensible way forward.

Hi Timothy,

great, thanks :-)

> Attached is a (final?) set of patches, which is as described.

The doc strings of org-html-meta-tags and org-html-meta-tags-default
need to be updated, they still mention author and title.

Also, please try checkdoc ;)

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2020-12-20, TEC wrote:

> Jens Lechtenboerger  writes:
>
>>> For people who want to customise this to add metadata, the page title is
>>> something they're probably interested in.
>>
>> What metadata would you derive from the title?
>
> In my earlier example, I use the "og:title" property.

I see.  Maybe the doc string could explain such a use case?

(I do not understand the benefit of adding that redundantly to an
HTML page, but that is not our topic here.)

>>> If so, I think it's work giving the title processed by
>>> org-html--build-meta-info as it's not so simple as
>>> (plist-get info :title).
>>
>> Extracting it from ~info~ might be more flexible as it would not be
>> tied to the current implementation.
>
> My thoughts are just that its seems like title/author may be handy, and
> we've already worked those out, so why not just pass them along?
>
> Could probably reduce to just info, not sure what's best though.

My personal view: If those attributes are present in the default
value, they should be used or their use should at least be explained.

> Other than this, is there anything else you think might be worth
> considering before merging?

No suggestions from my side.  Thank you for your work!

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2020-12-16, TEC wrote:

> Jens Lechtenboerger  writes:

>>> Maybe it should be applied to the rest (in ~org-html--build-meta-info~)?
>>> I'm not sure.
>>
>> I’m not sure either.  Maybe people expect their typed characters,
>> maybe not.  This might call for a new variable.
>
> I'm tempted to leave the current behaviour as-is, and then we can
> introduce a new variable if we want later :)

I agree.

>> I like the new variant much better.  However, I still do not
>> understand why you pass the title into org-html-meta-tags-default
>> just to ignore it.  The title is already dealt with elsewhere, isn’t
>> it?
>
> For people who want to customise this to add metadata, the page title is
> something they're probably interested in.

What metadata would you derive from the title?

> If so, I think it's work giving the title processed by
> org-html--build-meta-info as it's not so simple as
> (plist-get info :title).

Extracting it from ~info~ might be more flexible as it would not be
tied to the current implementation.

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

Hello everyone,

On 2020-12-15, TEC wrote:

> Jens Lechtenboerger  writes:
>
>> [title export being dodgy, how about treating like author?]
>
> Yep, ~org-element-interpret-data~ is necessary. I found that wrapping it
> in ~org-html-plain-text~ seems better again though, as it encodes
> entities like "---" (org) to "", and doesn't seem to introduce
> any nested tags. I've also applied this to the author field as a result.

I like this!

> Maybe it should be applied to the rest (in ~org-html--build-meta-info~)?
> I'm not sure.

I’m not sure either.  Maybe people expect their typed characters,
maybe not.  This might call for a new variable.

I like the new variant much better.  However, I still do not
understand why you pass the title into org-html-meta-tags-default
just to ignore it.  The title is already dealt with elsewhere, isn’t
it?

Some comments raise complaints by checkdoc (lines too long, no
sentence in fist line).  (Actually, the file has more problems in
that regard.)

Many thanks for your continued work!

Best wishes
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

Hi everybody,

On 2020-12-14, Bastien wrote:

> Hi Timothy,
>
> TEC  writes:
>
>> Thanks for testing this :) I haven't forgotten about this.
>
> Let's wait for Jens feedback on this patch, since he took care of
> testing it so far.

I exported this:

#+begin_src org
,#+TITLE: A title with *bold* index_1^2 and characters &ß<"
,#+AUTHOR: An /emphasized/ "anonymous" author_1^2 with 
[[https://example.org][hyperlink]] and characters &ß<"
,#+DESCRIPTION: A description_1^2 with /emphasis/ and 
[[https://example.org][hyperlink]] and characters &ß<"
,#+KEYWORDS: key, wörd, *bold*, sub_script

Test
#+end_src

The title now exports follows, which needs fixing:
A title with 

What about treating the title like the author?  (Again, Org mode
currently produces invalid HTML as nested sub-elements are produced
inside the title element.)

The keywords export as follows, where the name attribute is missing:


The current lambda functions in org-html-meta-tags all accept three
arguments, where the first one is ignored in all cases.  The second
one is used in exactly one case.  Why not add four calls to
org-html--build-meta-entry (for author, description, keywords,
generator) in org-html--build-meta-info?

Best wishes
Jens

Re: Reply-All noise

[Jens Lechtenboerger]

On 2020-10-09, to...@tuxteam.de wrote:

> On Fri, Oct 09, 2020 at 10:10:41PM +0200, to...@tuxteam.de wrote:
>> On Fri, Oct 09, 2020 at 09:24:34PM +0200, c.bu...@posteo.jp wrote:
>> > Hi,
>
> [...]
>
>> There is no clear-cut answer to that [...]
>
> You might also want to experiment with setting the Mail-Followup-To:
> header [1] in your mails to the list (I have no experience with that,
> so take with a fist of salt!).
> [...]
> [1] https://cr.yp.to/proto/replyto.html

That is what I’m using with Gnus, see [2].  In my case,
message-subscribed-addresses contains "emacs-orgmode@gnu.org".

With that setting I say: Please send replies just to the list, not
to me individually.

Best wishes
Jens

[2] 
https://www.gnu.org/software/emacs/manual/html_node/message/Mailing-Lists.html

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2020-09-28, TEC wrote:

> Jens Lechtenboerger  writes:
>
>> On 2020-09-28, TEC wrote:
>>
>>> Jens Lechtenboerger  writes:
>>>> Also, in org-html--build-meta-info you call
>>>> org-html-encode-plain-text with two arguments, but it just accepts
>>>> one.
>>>
>>> ? No I don't.
>>
>> Your patch contains this:
>>
>> +  (let* ((title (org-html-encode-plain-text (plist-get info :title)
>> info))
>
> O, that's the bit you were referring to. That's just copied from
> the
> current state (iirc). Anyway, I dropped the second argument.

Without the second argument I get an error “Wrong type argument:
stringp,” when evaluating regular expressions against the cons cell
that is returned as title.

As I see now, author and title are cons cells, which is why
org-element-interpret-data is necessary to produce strings with Org
syntax.

Also, after fixing the title, I get “wrong-type-argument sequencep
utf-8” for “(concat "text/html;charset=" charset)”.

Best wishes
Jens

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2020-09-28, TEC wrote:

> Jens Lechtenboerger  writes:
>> Also, in org-html--build-meta-info you call
>> org-html-encode-plain-text with two arguments, but it just accepts
>> one.
>
> ? No I don't.

Your patch contains this:

+  (let* ((title (org-html-encode-plain-text (plist-get info :title)
info))

Best wishes
Jens

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2020-09-26, TEC wrote:

> @Maintainers I think this is ready for a review.
>
> Jens Lechtenboerger  writes:
>
>> My suggestion would be to go with the handling of description in all
>> cases, including the title.
>
> Currently the only element handled differently to
> `org-html-encode-plain-text' is "author". I don't know why so I don't
> want to touch it.

I believe that was also the previous conclusion.  However, as this
is not documented, maybe now could be the chance to change this?

>> I added keywords to my OER presentations because some crawlers use
>> them to extract topics for classification of documents.  I’d like to
>> keep that.
>
> Re-added.
>
> Let me know if there's anything else,

I must I admit that I do not fully understand your approach.

Why do you treat keywords and description differently (with
description in org-html-meta-tags and keywords in
org-html--build-meta-info)?

Why do you pass _title into the lambda expressions in
org-html-meta-tags when it is never used?  Currently, the variable
org-html-meta-tags does not seem user-friendly to me.

Also, in org-html--build-meta-info you call
org-html-encode-plain-text with two arguments, but it just accepts
one.

Best wishes
Jens

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2020-09-18, TEC wrote:

> Jens Lechtenboerger  writes:
> [...]
> I was not aware of org-element-interpret-data, and I can't say I can
> really tell what it does. If you'd care to elaborate that would be
> helpful.

Hi Timothy,

I don’t know why that is used.  For this test case:

#+begin_src org
,#+TITLE: A title with *bold* index_1^2 and characters &ß<"
,#+AUTHOR: An /emphasized/ "anonymous" author_1^2 with 
[[https://example.org][hyperlink]] and characters &ß<"
,#+DESCRIPTION: A description_1^2 with /emphasis/ and 
[[https://example.org][hyperlink]] and characters &ß<"

Test
#+end_src

I get this with Org master:

#+begin_src html
A title with bold index12 and characters 
ß"
https://example.org][hyperlink]] and characters ß" />
https://example.org][hyperlink]] and characters ß"
#+end_src

The title is not valid HTML.  I suggest to export it with Org
syntax.

I cannot see a difference between the handling of author and
description.  So, for this example, org-element-interpret-data is
not necessary for author.  I don’t know whether others have author
information where a difference would be visible.

My suggestion would be to go with the handling of description in all
cases, including the title.

>> Besides, did you forget keywords or remove them on purpose?
>
> This is a deliberate omission. My impression is that the value of
> keywords in HTML documents has evaporated over the past decade, see:
> https://yoast.com/meta-keywords/

I added keywords to my OER presentations because some crawlers use
them to extract topics for classification of documents.  I’d like to
keep that.

Best wishes
Jens

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

On 2020-09-17, TEC wrote:

> Hi All,
>
> This just replaces the current `org-html--build-meta-info' with a
> cleaner, more extensible (I also added a new variable)
> version. Please give it a look and let me know what you think!

Hi Timothy,

yes, I agree that org-html--build-meta-info needs work, and the HTML
backend would benefit from more documentation.  Back then [1], I
wondered which parts of meta data need to be treated how.  That was
continued in thread [2].

As pointed out back then, using org-export-data on the title is
wrong as it creates nested elements, leading to invalid HTML.

Currently, org-element-interpret-data is applied for author
information, while description and keywords are treated differently.

Your patch goes for org-html-encode-plain-text in the new function
org-html--build-meta-entry, which (if I’m not mistaken) produces
author and description.  Did you think about using
org-element-interpret-data instead?  What if that was used?
I believe this to be an important question as it might affect
backward compatibility and should be documented.

Does this really work for you?  For the author, first
org-html--build-meta-entry gets called from the new defcustom.  The
result is assigned with setq to form, which then is non-nil so that
org-html--build-meta-entry is applied again, leading to an error
here.

Besides, did you forget keywords or remove them on purpose?

Best wishes
Jens

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00193.html
[2] https://lists.gnu.org/archive/html/emacs-orgmode/2020-02/msg00368.html


smime.p7s
Description: S/MIME cryptographic signature

Re: pcase failure with Emacs 24 (was Emacs version for Org 9.4?)

[Jens Lechtenboerger]

On 2020-09-15, Kyle Meyer wrote:

> It is pretty tricky to debug, but the failure starts with 4a27b67fd
> (org-element: Fix property drawers parsing, 2020-04-22).  As far as I
> can see, the pattern introduced there is perfectly valid and should be
> compatible with Emacs 24.  I'd _guess_ this is a pcase bug in Emacs 24,
> particularly the one fixed by 528872c5f8 (bug#18554, 2014-09-27), but I
> didn't make an effort to try to understand that commit.
>
> Interestingly, the error goes away if I just swap the elements in the
> pcase (and ...) pattern added by that commit.  Dunno, but if that clears
> up the failure on your end as well, I don't see any reason to not make
> that change.
>
>
> diff --git a/lisp/org-element.el b/lisp/org-element.el
> [...]

Yes, that fixes the problem over here.

Many thanks for debugging this, I’m deeply impressed.

Best wishes
Jens

Re: Emacs version for Org 9.4?

[Jens Lechtenboerger]

On 2020-09-15, Jeremie Juste wrote:

> Hello Jens,
>
> I'm afraid I cannot test your issue. I don't have the ability to switch
> emacs version yet.
>
> What I can tell you is that org-9.4 is working fine on GNU Emacs 27.1,
> and on Emacs 28.0.50.

Hello Jeremie,

thanks for your reply.  Yes, I’m aware that newer versions of Emacs
work.  I’m interested in the officially supported “lowest” version
of Emacs.  (When trying Org mode 9.4, I got a test failure with
org-re-reveal, for which I still promise compatibility with Emacs
24: https://gitlab.com/oer/org-re-reveal/-/pipelines/190002022)

Best wishes
Jens

Emacs version for Org 9.4?

[Jens Lechtenboerger]

Hi there,

if I open an Org file on
“GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of
2017-09-12 on hullmann, modified by Debian”
I get this error (which I don’t know how to debug):

Eager macro-expansion failure: (wrong-type-argument listp :pcase--succeed)

Recipe:
touch empty.org
curl -L https://orgmode.org/elpa/org-plus-contrib-20200914.tar > org.tar
mkdir org && tar xf org.tar -C org --strip-components 1
rm -f org.tar
emacs -Q -L org
C-x C-f empty.org

In ORG-NEWS, I only found that “Emacs 24.4 or above is suggested.”
Did that change?

Best wishes
Jens

Re: ox-* vs org-* naming convention?

[Jens Lechtenboerger]

On 2020-06-07, Diego Zamboni wrote:

> Hi,
>
> I am working on submitting a new set of exporters I've been working on
> (https://gitlab.com/zzamboni/ox-leanpub) to MELPA, and I received
> feedback [1] about the discrepancy between the package names
> (ox-leanpub-*) and the functions they define (org-leanpub-*). This is
> also flagged by =package-lint=.
>
> [1] https://github.com/melpa/melpa/pull/6942
>
> [...]
>
> I would appreciate any feedback about this - what are strong arguments
> for or against insisting in this convention vs just adapting to the
> rules suggested by package-lint?

Hi there,

for org-re-reveal, I use a small wrapper ox-re-reveal.el [2], whose
commentary explains this:

;; Org export back-ends have file names starting with "ox-".
;; However, such files typically define variables and functions
;; starting with "org-", which causes errors by package-lint.  To
;; define variables and functions with the usual prefix "org-" while
;; avoiding errors by package-lint, code is located in
;; org-re-reveal.el.
;; However, the prefix "ox-" is hard-coded in org.el and used to load
;; back-ends in `org-export-backends'.  With this file, you can
;; customize `org-export-backends' and add `re-reveal'.  Then, when
;; pressing `C-c C-e', this file will be loaded, which loads
;; org-re-reveal.el.

Best wishes
Jens

[2] https://gitlab.com/oer/org-re-reveal/-/blob/master/ox-re-reveal.el

Re: emacs + org-mode in virtual machine/docker/...

[Jens Lechtenboerger]

On 2020-05-23, Olivier Berger wrote:

> Hi.
>
> This looks quite similar to my approach to producing course material,
> which is documented here : https://olberger.gitlab.io/org-teaching
> including the use of Docker (see
> https://gitlab.com/olberger/docker-org-teaching-export/ )

Indeed, the philosophy of using the right source format is the same.
Thanks for the pointer.

What I see as differences: Emacs-reveal embeds plugins for audio and
quizzes to create what I hope to be material for asynchronous
learning (particularly useful in Corona times but preferable to
lecturing in “normal” years as well).  It supports a bibliography
slide and focuses on Free and Open Educational Resources with
simplified (in my view) treatment of license information.

Do you share your teaching material for “Web architecture and
applications (CSC4101)”?

Best wishes
Jens

Re: emacs + org-mode in virtual machine/docker/...

[Jens Lechtenboerger]

On 2020-05-21, John Kitchin wrote:

> What do you do with this image? I would be happy to continue this off-list
> if it seems better.

I generate self-study HTML presentations with audio as OER based on
reveal.js.  See there for a course about to start in two weeks:
https://oer.gitlab.io/OS/

Material generated from this:
https://gitlab.com/oer/OS/-/blob/master/.gitlab-ci.yml

A howto: https://oer.gitlab.io/emacs-reveal-howto

Best wishes
Jens

Re: emacs + org-mode in virtual machine/docker/...

[Jens Lechtenboerger]

On 2020-05-21, John Kitchin wrote:

> Has anyone had any success in creating or using any kind of virtual machine
> that can work across platforms to run emacs+org-mode?

I maintain Docker images, emacs-reveal includes org-ref.  It is
large, though:
https://gitlab.com/oer/emacs-reveal/container_registry

Best wishes
Jens

Re: ox-html: Bug or feature for export of title and meta information?

[Jens Lechtenboerger]

Hi there!

On 2020-02-17, at 10:47, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:

>> Which “non exportable objects” can be skipped by that function (as
>> mentioned in a comment in org-html--build-meta-info)? Should they also
>> be skipped for description or title?
>
> That non-exportable part is confusing. I think
>
>   (org-element-interpret-data auth)
>
> is sufficient. I pushed a change in that direction.

Thank you!

The function org-element-interpret-data seems to return the empty
string for nil.  Is that by contract or accident?  In the former
case, maybe use

(org-element-interpret-data (plist-get info :author))

instead of the let statement?

What do you think about applying org-element-interpret-data (instead
of org-export-data) when let-binding title, like the following?

(org-html-encode-plain-text
 (org-element-interpret-data (plist-get info :title)))

As far as I can tell, this would create valid (X)HTML.

Best wishes
Jens

Re: ox-html: Bug or feature for export of title and meta information?

[Jens Lechtenboerger]

Hi there!

On 2020-02-15, at 15:02, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> the W3C Markup Validator [1] disagrees with this output from
>> ox-html (which I reduced to the essential parts):
>
> OK. I was talking about the Org syntax. I misread your initial report.
>
> I won't comment about the generated HTML. If needed, the HTML exporter
> can prevent parsing TITLE keyword.

I do not know what is needed.  Function org-html--build-meta-info
should return valid XHTML (also in case of HTML5, I believe that
Org syntax is preferable over ignored [1] HTML tags).

Based on the treatment of meta elements for author and description
in that function, alternatives might use org-element-interpret-data
(author) or not (description).  I do not understand the role of
org-element-interpret-data to generate author information.  Which
“non exportable objects” can be skipped by that function (as
mentioned in a comment in org-html--build-meta-info)?  Should they
also be skipped for description or title?

Best wishes
Jens

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title

Re: ox-html: Bug or feature for export of title and meta information?

[Jens Lechtenboerger]

On 2020-02-14, at 20:31, Nicolas Goaziou wrote:

> Hello,
>
> Jens Lechtenboerger  writes:
>
>> 1. Export to HTML when the title contains markup, say this one:
>>
>> #+TITLE: This does *not* work
>
> What does not work?
>
>> The HTML title element contains a nested b element, which is
>> invalid as only text is allowed.
>
> Who said that? The above is perfectly valid.

Good morning (over here),

the W3C Markup Validator [1] disagrees with this output from
ox-html (which I reduced to the essential parts):

#+begin_src html

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="en" xml:lang="en">

This does not work


#+end_src

Best wishes
Jens

[1] https://validator.w3.org/#validate_by_input

Re: ox-html: add option to restore old src block behaviour?

[Jens Lechtenboerger]

On 2020-02-11, at 16:40, Bastien wrote:

> Matt Price  writes:
>
>> However, at least one very common syntax highlighter, https://
>> highlinghtjs.org, expects just a single  tag, as do other
>> common CSS frameworks. These often leave odd borders or background
>> color disruptions which somewhat distort the view of the code.
>> There's also a funny conflict with `org-re-reveal`, which expects the
>> old behaviour (see https://gitlab.com/oer/org-re-reveal/issues/27). 
>> It would in principal be possible to fix these issues directly in
>> CSS, but it might be much more practical to have an option -- a
>> defvar or a file/headline-settable property -- that restores the old
>> behaviour when desired.  If this would be welcome, I could do it. I
>> know org already has a bewildering number of options,though,and the
>> code change would be oddly a number of times as large as the
>> substantive change of that commit, os thought I'd check first.
>
> Yes, an option makes sense here -- can you provide one that allows to
> restore the old behavior (and avoid all those ... lines)?

Hi Bastien,

that issue has been resolved:
https://lists.gnu.org/archive/html/emacs-orgmode/2019-10/msg00099.html

Best wishes
Jens

Re: ox-html: Bug or feature for export of title and meta information?

[Jens Lechtenboerger]

On 2020-02-11, at 09:16, Bastien wrote:

> Hi Jens,
>
> it is difficult to justify existing code, it is easier to answer to
> bug reports.  If you think there is a bug in this aread, can you tell
> what it is?

Hi Bastien,

many thanks for following up on this!

I see two or more bugs:

1. Export to HTML when the title contains markup, say this one:

#+TITLE: This does *not* work

The HTML title element contains a nested b element, which is
invalid as only text is allowed.

2. The documentation does not explain which headers are exported how
to HTML.  I described different variants in my previous e-mail.
I’m not sure whether there was a reason to treat them differently.
So, this is at least a bug in the documentation (with potentially
more bugs in the code if the current treatment was not desirable).

Best wishes
Jens

Re: [PATCH] Derive non-default start value for ordered list

[Jens Lechtenboerger]

On 2019-12-02, at 08:23, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> [...]
>> What do you think about the attached patch that allows to omit the
>> @-syntax?  Controlled by the new variable
>> org-list-use-first-bullet-as-non-standard-counter, the code assigns
>> a counter value to the first list item from its bullet string if the
>> item
>> 1. does not specify a counter itself,
>> 2. has an alphanumeric bullet, and
>> 3. does not have a default start value (1, a, A).
>
> I think the current situation is better. It works, as advertised, and it
> allows you to re-number any item in the list, not necessarily the first
> one.

One can still do this.

> Of course, it may be less "elegant", but the overhead is negligible,
> and, as a data point, I'd rather have continuation lists more visible
> than not, as it could create confusion in the document.

I understand.

> I do not know about org-re-reveal, but included exporters do not display
> the [@xxx] part. However, they use its value to start lists at an
> appropriate number, if technically possible. I suggest org-re-reveal to
> do the same if that's not the case.

My backend does this, but maybe the user did not know about the
@-syntax.  Also, he did not want to change all his preexisting
lists.

Thanks for your feedback
Jens

Re: [PATCH] Derive non-default start value for ordered list

[Jens Lechtenboerger]

On 2019-12-01, at 14:13, Samuel Wales wrote:

> i think it might be partlly a question of whether these numbers are
> fixed things that refer to fixed items [like referring to sections in
> a law that is not in the document] vs. being used to continue lists.
>
> they are both legitimate uses.  in the first case, the @ syntax makes
> sense to me, because it specifies a fixed alphanumber.  yes i made
> that word up.
>
> some exporters assume the numbers in the org source list don't matter
> and start from 1 or the @ in the exported text.

If I took the effort to type something, then that should not be
ignored by an exporter.

> so your solution would be anomalous.

But meet some users’ expectations.  Quite likely, those of new Org
users.

> and i'm used to exporters doing that so it feels strange to me to rely
> on the org text.

If text is ignored, I should not need to type it in the first
place.

> i view that as potentially changing.  what should
> occur if you do something that renumbers it?

If I renumber, then, of course, I want to see the new numbers after
export.

> in the second case, the @ syntax and your solution both seem brittle
> to me.  you might add to the first list.

I agree.

> i think there can be a third solution that would be less brittle.
>
> just as a brainstorm, consider the common case of continued lists like
>
> vvv
> 1.  asdf
> 2.  <> asdf
>
> a paragraph.
>
> 3.  [@asdf-list-end] asdf
> ^^^

This would indeed be a cool solution.

Thanks
Jens

[PATCH] Derive non-default start value for ordered list

[Jens Lechtenboerger]

Hi there,

currently, we have to write the following to continue an ordered
list from a value different from 1:

42. [@42] Answer
43. Question?

The requirement to type redundant information with the @-syntax
always struck me as odd.  For my export backend org-re-reveal, I
recently received a request to export lists without @-syntax to
their “correct” start values [1].

Before working on my backend, I’d like to ask for feedback: Why was
the @-syntax introduced?  Of what non-obvious effects should I be
aware?

What do you think about the attached patch that allows to omit the
@-syntax?  Controlled by the new variable
org-list-use-first-bullet-as-non-standard-counter, the code assigns
a counter value to the first list item from its bullet string if the
item
1. does not specify a counter itself,
2. has an alphanumeric bullet, and
3. does not have a default start value (1, a, A).

I hacked this as postprocessing step on the list’s struct.  Maybe an
Org expert could suggest how to do this in one pass?

Best wishes
Jens

P.S.  I did not work on documentation yet as I’m not sure that this
change is acceptable.

[1] https://gitlab.com/oer/org-re-reveal/merge_requests/27

>From 2eea43d84687259633f847bd17883e5fe578b6bc Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger 
Date: Sun, 1 Dec 2019 21:17:43 +0100
Subject: [PATCH] Use bullet as non-standard counter

* lisp/org-list.el: New variable
org-list-use-first-bullet-as-non-standard-counter and new function
org-list-struct-maybe-add-counters to assign counters from bullets
that indicate non-standard start values.
(org-list-struct): Use new variable and function.

* lisp/org-element.el (org-element-item-parser): Use new variable and
mirror behavior of org-list.el.
---
 lisp/org-element.el | 19 ++-
 lisp/org-list.el| 33 -
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 56b3cc413..80b7cab99 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -1269,6 +1269,8 @@ Assume point is at the beginning of the item."
 (beginning-of-line)
 (looking-at org-list-full-item-re)
 (let* ((begin (point))
+   (prevs (org-list-prevs-alist struct))
+   (prev-item (org-list-get-prev-item begin struct prevs))
 	   (bullet (match-string-no-properties 1))
 	   (checkbox (let ((box (match-string 3)))
 		   (cond ((equal "[ ]" box) 'off)
@@ -1277,7 +1279,22 @@ Assume point is at the beginning of the item."
 	   (counter (let ((c (match-string 2)))
 		  (save-match-data
 			(cond
-			 ((not c) nil)
+			 ((not c)
+			  (and
+			   org-list-use-first-bullet-as-non-standard-counter
+			   ;; As in org-list-struct-maybe-add-counters,
+			   ;; assign non-standard counter from bullet of
+			   ;; first list item.  To exclude "A", check range
+			   ;; from "B".
+   (not prev-item)
+   (or (and (string-match "[B-Zb-z]" bullet)
+(- (string-to-char
+	(upcase (match-string 0 bullet)))
+   64))
+   (and (string-match "[0-9]+" bullet)
+(string< "1" (match-string 0 bullet))
+(string-to-number
+ (match-string 0 bullet))
 			 ((string-match "[A-Za-z]" c)
 			  (- (string-to-char (upcase (match-string 0 c)))
 			 64))
diff --git a/lisp/org-list.el b/lisp/org-list.el
index c4aef32fc..fe8742f42 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -336,6 +336,14 @@ clearly distinguish sub-items in a list."
   :version "24.1"
   :type 'integer)
 
+(defcustom org-list-use-first-bullet-as-non-standard-counter nil
+  "Non-nil means to use first bullet of an ordered list as counter.
+Then, you can start an ordered list with \"42. Answer\" instead of
+\"42. [@42] Answer\"."
+  :group 'org-plain-lists
+  :package-version '(Org . "9.3")
+  :type 'boolean)
+
 (defvar org-list-forbidden-blocks '("example" "verse" "src" "export")
   "Names of blocks where lists are not allowed.
 Names must be in lower case.")
@@ -731,7 +739,30 @@ Assume point is at an item."
   ;; 3. Associate each item to its end position.
   (org-list-struct-assoc-end struct end-lst)
   ;; 4. Return STRUCT
-  struct)))
+  (if org-list-use-first-bullet-as-non-standard-counter
+  (org-list-struct-maybe-add-counters struct)
+struct
+
+(defun org-list-struct-maybe-add-counters (struct)
+  "Maybe add counters to first list items of STRUCT.
+For the first list items in STRUCT (those without previous item) that
+1. do not specify a counter,
+2. has an alphanumeric bullet, and
+3. do not have a default start value (1, a, A),
+set the counter to the item's bullet."
+  (le

Re: [O] [PATCH] ox-html: add option to restore old src block behaviour?

[Jens Lechtenboerger]

On 2019-10-13, at 09:30, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> Subject: [PATCH] ox-html: Control wrapping of source lines
>>
>> * lisp/ox-html.el (org-html-format-code, org-html-do-format-code):
>>   Use new export option :html-wrap-src-lines with variable
>>   org-html-wrap-src-lines to control whether source code lines should
>>   be wrapped in code elements or not.
>> * doc/org-manual.org: Document the new option
>
> Applied. Would you mind adding an ORG-NEWS entry about it?

Thanks!  A patch is attached.

Best wishes
Jens

>From f2f93c573fef6a079c2f7f434e6c65d51e2f0906 Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger 
Date: Sun, 13 Oct 2019 14:06:09 +0200
Subject: [PATCH] Mention option html-wrap-src-lines in ORG-NEWS

* etc/ORG-NEWS: Mention new option html-wrap-src-lines.
---
 etc/ORG-NEWS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9fff4ad16..0e07326cb 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -123,6 +123,12 @@ auto-commit attachments to git:
   one need to require the =org-attach-git= module in the startup.
 
 ** New features
+*** New option to wrap source code lines in HTML export
+
+When new option ~html-wrap-src-lines~ (with variable
+~org-html-wrap-src-lines~) is non-nil, HTML export wraps source code
+lines in HTML ~code~ elements.
+
 *** New option to handle schedules and deadlines in iCalendar export
 
 Export ignore done tasks with a deadline when
-- 
2.17.1

Re: [O] [PATCH] ox-html: add option to restore old src block behaviour?

[Jens Lechtenboerger]

On 2019-10-08, at 11:31, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> The attached patch adds a new variable org-html-wrap-src-lines to
>> control whether code tags should be added or not.
>
> Thank you.
>
> However, the patch is not right. Exporters do not use defcustoms
> directly. Instead, you register them within :options-alist in the the
> back-end definition, e.g., under :html-wrap-src-lines and then call
> (plist-get info :html-wrap-src-lines) in the function. This allows to
> control these options during publishing.

Indeed, sorry.  Many thanks for the detailed feedback!

I had to change the calling function org-html-format-code and add an
argument to org-html-do-format-code as info is not available in the
latter function.

> Also, this would need an entry in the manual, if only in the "options
> for the exporters" subsection.

Done.

>> I’m not sure whether :package-version 9.3 is correct.
>
> It is correct. You can also use :safe t.

Added.

>> Also, I set the value to t, which does not change the current
>> functionality. However, for backwards compatibility (up to version
>> 9.2.6), a value of nil would be preferable. Any thoughts?
>
> I agree with the nil default value.

Done.

>> +(defcustom org-html-wrap-src-lines t
>> +  "If t, wrap individual lines of source blocks in \"code\" elements.
>
> When non-nil, wrap...

Done.

Best wishes
Jens

>From 961c0b45ff3e5548df11fc3fe9274e913c467c65 Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger 
Date: Tue, 8 Oct 2019 20:15:06 +0200
Subject: [PATCH] ox-html: Control wrapping of source lines

* lisp/ox-html.el (org-html-format-code, org-html-do-format-code):
  Use new export option :html-wrap-src-lines with variable
  org-html-wrap-src-lines to control whether source code lines should
  be wrapped in code elements or not.
* doc/org-manual.org: Document the new option
---
 doc/org-manual.org |  3 ++-
 lisp/ox-html.el| 39 +++
 2 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index f2f059e77..68543d67c 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -10789,7 +10789,7 @@ environments and math templates.  Inside Org mode, you can make use of
 some of the features of CDLaTeX mode.  You need to install
 =cdlatex.el= and =texmathp.el= (the latter comes also with AUCTeX)
 using [[https://melpa.org/][MELPA]] with the [[https://www.gnu.org/software/emacs/manual/html_node/emacs/Package-Installation.html][Emacs packaging system]] or alternatively from
-[[https://staff.fnwi.uva.nl/c.dominik/Tools/cdlatex/]].  Do not use 
+[[https://staff.fnwi.uva.nl/c.dominik/Tools/cdlatex/]].  Do not use
 CDLaTeX mode itself under Org mode, but use the special version Org
 CDLaTeX minor mode that comes as part of Org.  Turn it on for the
 current buffer with {{{kbd(M-x org-cdlatex-mode)}}}, or for all Org
@@ -15753,6 +15753,7 @@ Settings]]), however, override everything.
 | ~:html-use-infojs~ | ~org-html-use-infojs~ |
 | ~:html-validation-link~| ~org-html-validation-link~|
 | ~:html-viewport~   | ~org-html-viewport~   |
+| ~:html-wrap-src-lines~ | ~org-html-wrap-src-lines~ |
 | ~:html-xml-declaration~| ~org-html-xml-declaration~|
 
  LaTeX specific properties
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 882f82dcb..83d0fd2e9 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -172,6 +172,7 @@
 (:html-table-row-open-tag nil nil org-html-table-row-open-tag)
 (:html-table-row-close-tag nil nil org-html-table-row-close-tag)
 (:html-xml-declaration nil nil org-html-xml-declaration)
+(:html-wrap-src-lines nil nil org-html-wrap-src-lines)
 (:html-klipsify-src nil nil org-html-klipsify-src)
 (:html-klipse-css nil nil org-html-klipse-css)
 (:html-klipse-js nil nil org-html-klipse-js)
@@ -932,6 +933,15 @@ in all modes you want.  Then, use the command
   :group 'org-export-html
   :type 'string)
 
+(defcustom org-html-wrap-src-lines nil
+  "If non-nil, wrap individual lines of source blocks in \"code\" elements.
+In this case, add line number in attribute \"data-ox-html-linenr\" when line
+numbers are enabled."
+  :group 'org-export-html
+  :package-version '(Org . "9.3")
+  :type 'boolean
+  :safe t)
+
  Table
 
 (defcustom org-html-table-default-attributes
@@ -2231,14 +2241,15 @@ is the language used for CODE, as a string, or nil."
 	(if (and beg end) (substring code beg end) code)
 
 (defun org-html-do-format-code
-  (code  lang refs retain-labels num-start)
+  (code  lang refs retain-labe

[O] ox-html: Bug or feature for export of title and meta information?

[Jens Lechtenboerger]

Hi there,

I wonder about the treatment of different pieces of HTML header
information in org-html--build-meta-info: Contents for the title
element are computed by org-export-data.  This interprets Org markup
such as italics or hyperlinks although title elements are not
allowed to contain the resulting sub-elements.  Why is
org-export-data applied?  Why not produce plain text?

Contents for the description and keywords meta attributes are
computed with org-html-encode-plain-text and replacement of
quotation marks.  Seems fine to me.

Contents for the author meta attribute are computed with
org-element-interpret-data, before org-html-encode-plain-text and
quotation mark replacement are applied.  How would author
information look like that benefits from this more complex treatment
(compared to description and keywords)?

Thanks
Jens

[O] [PATCH] ox-html: add option to restore old src block behaviour?

[Jens Lechtenboerger]

On 2019-09-19, Matt Price wrote:

> Over the summer, commit ded3d27b1468b878197e5fe55a70c5e13350ea27
> by Nik Clayton was merged to master. It's a one-line change that
> adds new ~~ tags around each lin of code in html export of
> source blocks.  It's useful because it allows individual lines to
> be addressed directly by CSS.
>
> However, at least one very common syntax highlighter,
> https://highlinghtjs.org, expects just a single  tag, as do
> other common CSS frameworks.
> [...]

The attached patch adds a new variable org-html-wrap-src-lines to
control whether code tags should be added or not.

I’m not sure whether :package-version 9.3 is correct.  Also, I set
the value to t, which does not change the current functionality.
However, for backwards compatibility (up to version 9.2.6), a value
of nil would be preferable.  Any thoughts?

Best wishes
Jens

>From ba3130deb9dbbab3c7d293f901ff08be839a8a9d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jens=20Lechtenb=C3=B6rger?= 
Date: Sat, 21 Sep 2019 12:01:59 +0200
Subject: [PATCH] ox-html: Control source line wrapping

* list/ox-html.el (org-html-do-format-code): Use new variable
  org-html-wrap-src-lines to control whether source code lines should
  be wrapped in code elements or not.

Allow to revert to behavior before commit
ded3d27b1468b878197e5fe55a70c5e13350ea27.
---
 lisp/ox-html.el | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 757006321..969e649fc 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -932,6 +932,14 @@ in all modes you want.  Then, use the command
   :group 'org-export-html
   :type 'string)
 
+(defcustom org-html-wrap-src-lines t
+  "If t, wrap individual lines of source blocks in \"code\" elements.
+In this case, add line number in attribute \"data-ox-html-linenr\" when line
+numbers are enabled."
+  :group 'org-export-html
+  :package-version '(Org . "9.3")
+  :type 'boolean)
+
  Table
 
 (defcustom org-html-table-default-attributes
@@ -2256,11 +2264,13 @@ line of code."
 		(format "%s"
 			(format num-fmt line-num)))
 	  ;; Transcoded src line.
-	  (format "%s"
-  (if num-start
-  (format " data-ox-html-linenr=\"%s\"" line-num)
-"")
-  loc)
+	  (if org-html-wrap-src-lines
+		  (format "%s"
+			  (if num-start
+  (format " data-ox-html-linenr=\"%s\"" line-num)
+"")
+			  loc)
+		loc)
 	  ;; Add label, if needed.
 	  (when (and ref retain-labels) (format " (%s)" ref
;; Mark transcoded line as an anchor, if needed.
-- 
2.20.1

Re: [O] Two bibliography slides using org-reveal

[Jens Lechtenboerger]

Johannes Brauer  writes:

> GET 
> file:///Users/jb/Downloads/org-re-reveal-ref-master/reveal.js/lib/js/head.min.js
>  net::ERR_FILE_NOT_FOUND  README.html:173 
>
> Is this a relevant message?

Hi Johannes,

that message appears for newer versions of reveal.js (but does not
hurt).  You can avoid it by customizing variable
org-re-reveal-script-files to remove lib/js/head.min.js, which does not
seem to exist for your version.

Alternatively, if you added (require 'org-re-reveal) in your ~/.emacs,
you could add the following:
(setq org-re-reveal-script-files '("js/reveal.js"))

Best wishes
Jens

Re: [O] Two bibliography slides using org-reveal

[Jens Lechtenboerger]

Johannes Brauer  writes:

> I downloaded [1] but when I try M-x load-library  followed by 
> org-re-reveal-ref I get
> "Cannot open load file: No such file or directory, org-re-reveal"
> although I’ve org-ref installed. What is going wrong?

Hi Johannes,

you also need to install org-re-reveal, from MELPA or from GitLab [2].
I just updated org-re-reveal-ref to clarify this.  Sorry for the
omission.

Best wishes
Jens

[2] https://gitlab.com/oer/org-re-reveal/

Re: [O] Two bibliography slides using org-reveal

[Jens Lechtenboerger]

I created org-re-reveal-ref [1] based on my fork org-re-reveal for
bibliographies with org-ref.  I only use it for export to reveal.js and
PDF, but HTML seems fine as well.  That package is part of emacs-reveal
[2].

Best wishes
Jens

[1] https://gitlab.com/oer/org-re-reveal-ref
[2] https://gitlab.com/oer/emacs-reveal

John Kitchin  writes:

> the bibliography export is not too fancy. It is defined in the function 
> org-ref-bibliography-format.
>
> I am not sure you can win, for latex export it doesn't make sense to put the 
> bibliography link in a heading. you might be able to add a specific reveal 
> export
> option to the export function though.
>
> John
>
> ---
> Professor John Kitchin 
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
> On Thu, Jul 25, 2019 at 9:55 AM Johannes Brauer  
> wrote:
>
>  Yes, I have tried that and indeed then I get only one bib slide. But then, 
> in normal Html export, the bibliography appears under the preceding headline,
>  that’s ugly.
>
>  > Am 25.07.2019 um 14:41 schrieb Fraga, Eric :
>  > 
>  > I have no idea but, on the off-chance, maybe don't make that line a
>  > headline?
>  > -- 
>  > Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-399-g4e6222

Re: [O] [RFC] Fixing link encoding once and for all

[Jens Lechtenboerger]

On 2019-03-01, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> On 2019-03-01, Nicolas Goaziou wrote:
>>
>>> 3. There will be some backward compatibility issues. We can add
>>>a checker in Org Lint to catch most of those. For example, we could
>>>look at URI where every percent is followed only by 25, 5B, and 5D.
>>
>> I do not understand this point.  What is special about URIs where
>> *only* those occur?  Might compatibility issues not arise if those
>> occur at all (while others such as %28 and %29 for parentheses might
>> occur without problems as well)?
>
> If a URI seems percent encoded, but only uses %25, %5B and %5D as escape
> combinations, there is a high chance that it is Org-encoded, and
> therefore uses a deprecated syntax. We could send a warning to the user
> in this case; they might want to clean the URI.
>
> OTOH, if there is %28, or %29, we are sure it isn't Org-encoded, and
> therefore, the percent-encoding was intended right from the start (like
> in your Wikipedia link).

Thanks for the clarification.  Makes sense.

Best wishes
Jens

Re: [O] [RFC] Fixing link encoding once and for all

[Jens Lechtenboerger]

Hi there,

I like this proposal.

On 2019-03-01, Nicolas Goaziou wrote:

> 3. There will be some backward compatibility issues. We can add
>a checker in Org Lint to catch most of those. For example, we could
>look at URI where every percent is followed only by 25, 5B, and 5D.

I do not understand this point.  What is special about URIs where
*only* those occur?  Might compatibility issues not arise if those
occur at all (while others such as %28 and %29 for parentheses might
occur without problems as well)?

Best wishes
Jens

Re: [O] [RFC] Fixing link encoding once and for all

[Jens Lechtenboerger]

On 2019-02-27, Nicolas Goaziou wrote:

> Hello,
>
> Jens Lechtenboerger  writes:
>
>> When exporting the following link to LaTeX, the decoding fails.
>>
>> --8<---cut here---start->8---
>> [[https://en.wikipedia.org/wiki/Red%E2%80%93black_tree][Red-black trees]]
>> --8<---cut here---end--->8---
>
> According to my suggestion in this thread, this link should be written
>
>   [[https://en.wikipedia.org/wiki/Red%25E2%2580%2593black_tree][Red-black 
> trees]]
>
> i.e., either you wrote it by hand, or `org-insert-link' failed.

I copied that from the address bar of my browser, probably two years
ago.  Today, I was surprised by a compilation failure.

> With the \-escape solution suggested by Neil, it would be correctly
> processed without additional change. Of course, that would entail other
> difficulties.

You mentioned Windows file names.  I’m not affected by that.  URLs
in my Org files neither contain “[” nor “\” (but lots of “%”).  So
the suggestion by Neil would be fine for me.

Best wishes
Jens

Re: [O] [RFC] Fixing link encoding once and for all

[Jens Lechtenboerger]

On 2019-02-24, Nicolas Goaziou wrote:

> Recently[1], issues about link escaping have resurfaced. I'd like to
> solve this once and for all.

Good morning,

I updated to Org mode version 9.2.1 (9.2.1-33-g029cf6-elpa @
/home/user/.emacs.d/elpa/org-20190225/).

When exporting the following link to LaTeX, the decoding fails.

--8<---cut here---start->8---
[[https://en.wikipedia.org/wiki/Red%E2%80%93black_tree][Red-black trees]]
--8<---cut here---end--->8---

The output is this:
--8<---cut here---start->8---
\href{https://en.wikipedia.org/wiki/Red\â\€\“black\_tree}{Red-black trees}
--8<---cut here---end--->8---

Previously, I got:
--8<---cut here---start->8---
\href{https://en.wikipedia.org/wiki/Red\%E2\%80\%93black\_tree}{Red-black trees}
--8<---cut here---end--->8---

Best wishes
Jens

Re: [O] Key bindings for Org export back-ends?

[Jens Lechtenboerger]

On 2019-02-08, at 22:03, Jens Lechtenboerger wrote:

> On 2019-02-08, at 10:54, Kaushal Modi wrote:
>
>> On Fri, Feb 8, 2019 at 10:48 AM Thomas S. Dye  wrote:
>>
>>> One place for the list of key bindings might be here:
>>> https://orgmode.org/worg/exporters/index.html
>>>
>>
>> That's a great idea! How about creating a single Org table with columns
>> like Name, Description, Binding, Core/Contributed, and then sort the rows
>> by the Binding column?
>>
>> We can leave the obsolete exporters section separate as it is right now.
>
> Should the description really go into a table?  Or might the table
> just provide an overview before the current section “Core
> exporters”?

Actually, a similar table exists, marked as in progress:
https://orgmode.org/worg/exporters/ox-overview.html

Column “Worg Tutorial” is mostly empty.  Column “Org-mode Manual”
only contains entries for the upper half.  Should we combine both
into one, “Tutorial/Manual”?

Or is such a table a futile goal given the potential amount of
back-ends pointed out by Chuck in a parallel answer?

Best wishes
Jens

Re: [O] Key bindings for Org export back-ends?

[Jens Lechtenboerger]

On 2019-02-08, at 10:54, Kaushal Modi wrote:

> On Fri, Feb 8, 2019 at 10:48 AM Thomas S. Dye  wrote:
>
>> One place for the list of key bindings might be here:
>> https://orgmode.org/worg/exporters/index.html
>>
>
> That's a great idea! How about creating a single Org table with columns
> like Name, Description, Binding, Core/Contributed, and then sort the rows
> by the Binding column?
>
> We can leave the obsolete exporters section separate as it is right now.

Should the description really go into a table?  Or might the table
just provide an overview before the current section “Core
exporters”?

Best wishes
Jens

Re: [O] Key bindings for Org export back-ends?

[Jens Lechtenboerger]

On 2019-02-08, at 06:51, Kaushal Modi wrote:

> On Fri, Feb 8, 2019, 3:28 AM Jens Lechtenboerger  wrote:
>
>> - org-reveal [3]: R
>> - org-re-reveal [4]: r (conflict with RSS)
>
> I see that org-re-reveal is based off org-reveal. So do you see a use case
> where people would `require' both org-reveal and org-re-reveal? If not,
> then using the same binding as that of org-reveal should be fine too.

I don’t recommend that but org-re-reveal should allow for a parallel
installation.  Therefore, I would like to bind a different key.

> I'm pretty sure there are many more Org backends out there. For example, I
> have a little ox-minutes backend that uses the M binding (and overrides the
> binding for ox-man, but that's fine for me as I don't use ox-man).
>
> We can start collecting a list of all Org backends on the Worg wiki. That's
> a good idea.

OK, let’s see whether additional input arrives.

> But doing so in order to not override the binding of some
> other backend might not be possible.

Fair enough.  At least some guidance will be given.

>> Or C-r?  So far, no back-end uses the
>> control key.  Any reasons not to do this?
>>
>
> You could probably use C-, but one has to ensure that it doesn't
> override the inbuilt bindings like C-s (C-c C-e C-s ..). Also, not sure if
> that override would actually be effective.

On my machine using "?\C-r" instead of "?r" as letter works,
(resulting in integer number 18 in org-export-registered-backends).
However, the Org Export Dispatcher shows "[^R]" as key, which is not
ideal.

Best wishes
Jens

Re: [O] Key bindings for Org export back-ends?

[Jens Lechtenboerger]

On 2019-02-08, at 06:51, Kaushal Modi wrote:

> On Fri, Feb 8, 2019, 3:28 AM Jens Lechtenboerger  wrote:
>
>> - org-reveal [3]: R
>> - org-re-reveal [4]: r (conflict with RSS)
>
> I see that org-re-reveal is based off org-reveal. So do you see a use case
> where people would `require' both org-reveal and org-re-reveal? If not,
> then using the same binding as that of org-reveal should be fine too.

I don’t recommend that but org-re-reveal should allow for a parallel
installation.  Therefore, I would like to bind a different key.

> I'm pretty sure there are many more Org backends out there. For example, I
> have a little ox-minutes backend that uses the M binding (and overrides the
> binding for ox-man, but that's fine for me as I don't use ox-man).
>
> We can start collecting a list of all Org backends on the Worg wiki. That's
> a good idea.

OK, let’s see whether additional input arrives.

> But doing so in order to not override the binding of some
> other backend might not be possible.

Fair enough.  At least some guidance will be given.

>> Or C-r?  So far, no back-end uses the
>> control key.  Any reasons not to do this?
>>
>
> You could probably use C-, but one has to ensure that it doesn't
> override the inbuilt bindings like C-s (C-c C-e C-s ..). Also, not sure if
> that override would actually be effective.

On my machine using "?\C-r" instead of "?r" as letter works,
(resulting in integer number 18 in org-export-registered-backends).
However, the Org Export Dispatcher shows "[^R]" as key, which is not
ideal.

Best wishes
Jens

[O] Key bindings for Org export back-ends?

[Jens Lechtenboerger]

Hi there,

I need to assign a key to an Org export back-end.  My first attempt
ended in a conflict, so I’d like to collect a (full?) list.

Built-in
- iCalendar: c
- HTML: h
- Texinfo: i
- LaTeX and Beamer: l
- Man: M
- Markdown: m
- ODT: o
- Org: O
- Publish: P
- Plain text: t

Contrib (ox-bibtex, ox-extra, ox-confluence without keys):
- Deck.js: d
- Freemind: f
- Groff: g
- Taskjuggler: J
- KOMA: k
- RSS: r
- s5: s

Other:
- ox-hugo [1]: H
- org-opml [2]: m (conflict with Markdown)
- org-reveal [3]: R
- org-re-reveal [4]: r (conflict with RSS)
- ox-rst [5]: r (conflict with RSS)
- ox-slimhtml [6]: s (conflict with s5)

So, these keys are taken:
c, d, f, g, h, H, i, J, k, l, M, m, o, O, P, R, r, s, t

Besides, SPC, DEL, C-a, C-b, C-f, C-n, C-p, C-s, C-v are taken.

Anyone with additional back-ends and keys?  Where could we document
the resulting list?

I’m thinking of changing org-re-reveal to p (for presentation) or v
(as occurring letter).  Or C-r?  So far, no back-end uses the
control key.  Any reasons not to do this?

Best wishes
Jens


[1] https://ox-hugo.scripter.co/
[2] https://github.com/org-opml/org-opml
[3] https://github.com/yjwen/org-reveal
[4] https://gitlab.com/oer/org-re-reveal
[5] https://github.com/msnoigrs/ox-rst
[6] https://github.com/balddotcat/ox-slimhtml

Re: [O] Bug: LaTeX export of table with caption broken

[Jens Lechtenboerger]

On 2019-01-19, at 16:06, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> when exporting a table with caption to LaTeX on the master branch,
>> invalid code is generated.
>
> Fixed. Thank you.

Wow, that was lightning fast.

Many thanks!
Jens

[O] Bug: LaTeX export of table with caption broken

[Jens Lechtenboerger]

Hi there,

when exporting a table with caption to LaTeX on the master branch,
invalid code is generated.

Example Org file:

#+CAPTION: Some text
| Col1 | Col2 |
|--+--|
| foo  | bar  |

The resulting tex file contains this, without table environment,
which is necessary for the use of captions:

begin{center}
\caption{Some text}
\begin{tabular}{ll}
Col1 & Col2\\
\hline
foo & bar\\
\end{tabular}
\end{center}

The above happens on the current master branch, but did already
happen last month on the next branch:
Org mode version 9.2 (release_9.2-193-ge7901c @ 
/usr/share/emacs/24.5/site-lisp/org/)
Org mode version 9.1.14 (release_9.1.14-1178-gdd26f0 @ 
/usr/share/emacs/24.5/site-lisp/org/)

In contrast, Org mode version 9.1.9 (release_9.1.9-65-g5e4542)
shipping with Emacs is fine, creating the following:

\begin{table}[htbp]
\caption{Some text}
\centering
\begin{tabular}{ll}
Col1 & Col2\\
\hline
foo & bar\\
\end{tabular}
\end{table}


Best wishes
Jens

[O] License information for figures in Org mode?

[Jens Lechtenboerger]

Hi there,

I’ve written code based on Org mode to generate Open Educational
Resources (OER, learning material under free licenses, typically
variants of Creative Commons), which include figures with proper
license attribution (source, author, license) [1].  If you ever wanted
to publish OER yourself, you are probably aware of the hassle of doing
that properly as figures usually do not embed license information,
which needs to be obtained and annotated separately.

Currently, I use Org macros to embed figures, e.g.:
#+BEGIN_SRC org
{{{reveallicense("./figures/org/jitt/JiTT-Java-MX.meta","33vh","figure fragment 
appear")}}}
#+END_SRC

The meta file in the first argument uses an ad-hoc text format,
embedding a path for the figure along with licensing information
inspired by standard metadata vocabularies, e.g.:
#+BEGIN_SRC emacs-lisp
((filename . "./figures/org/jitt/JiTT-Java-MX.png")
 (licenseurl . "https://creativecommons.org/licenses/by-sa/4.0/;)
 (licensetext . "CC BY-SA 4.0")
 (cc:attributionName . "Jens Lechtenbörger")
 (cc:attributionURL . "https://gitlab.com/lechten;)
 (dc:source . 
"https://gitlab.com/oer/figures/blob/master/org/jitt/JiTT-Java-MX.org;)
 (sourcetext . "GitLab")
 (dc:title . "Improved Java MX understanding")
 (texwidth . 0.9)
)
#+END_SRC

Currently, export to LaTeX (and, thus, PDF) and reveal.js (HTML with
RDFa) are supported (templates and the essential function
reveal-export-attribution are in [2]).

The above macro uses eval, whose syntax differs between released Org
mode versions and the master branch, which implies that I need to
reconsider my approach.  Any ideas or interest how such functionality
could be integrated into Org mode in general?

Best wishes
Jens

[1] https://gitlab.com/oer/emacs-reveal
[2] https://gitlab.com/oer/emacs-reveal/blob/master/reveal-config.el

[O] Quoting of macros with eval

[Jens Lechtenboerger]

Hi there,

given a macro like

#+MACRO: foo (eval (message "%s" $1))

I need to call {{{foo("text")}}} with Org mode 9.1.14-9-g131531-elpa.

On the master branch, that call will include the quotation marks as
part of the string, so I need to call {{{foo(text)}}} (documented in
the manual, but I didn’t notice that until now).

Could the master branch offer backward compatible functionality,
please?  I’m thinking about checking for and removing leading and
trailing quotation marks...

Best wishes
Jens

Re: [O] [PATCH] ox.el: Define subtitle macro

[Jens Lechtenboerger]

Hi there,

On 2017-11-21, Nicolas Goaziou wrote:

> For the record, I implemented a "keyword" macro (master branch).

That has been in master for over a year now.  Are there plans for
inclusion in a release?  (Or did I overlook that?)

Best wishes
Jens

[O] PATCH: Extract HTML attributes from link if present

[Jens Lechtenboerger]

Hi there,

for HTML export, attributes are added to links with what is called a
“HACK” in a comment in ox-html.el: Attribute :attr_html is read from
the parent, to be transferred to the first link.

That mechanism can used to assign attributes to the first link in
each paragraph/sentence.  For org-reveal, I would like to assign
computed classes to links in general (several per paragraph).  The
attached patch extends the current functionality to add attributes
of the link to those of the parent.

Could that please be included?

Best wishes
Jens

>From 3ac50ac3a3c8951d59a1d30b047ae0407731b789 Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger 
Date: Sat, 8 Dec 2018 16:44:06 +0100
Subject: [PATCH] ox-html.el: Export attributes specified with :attr_html for
 links

* lisp/ox-html.el (org-html-link): Export :attr_html from link
---
 lisp/ox-html.el | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 6a81be126..bbe38d8e2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -3045,19 +3045,25 @@ INFO is a plist holding contextual information.  See
 			  "#"
 			  (org-publish-resolve-external-link option path t))
 	   (t raw-path)))
-	 ;; Extract attributes from parent's paragraph.  HACK: Only do
-	 ;; this for the first link in parent (inner image link for
-	 ;; inline images).  This is needed as long as attributes
-	 ;; cannot be set on a per link basis.
 	 (attributes-plist
-	  (let* ((parent (org-export-get-parent-element link))
-		 (link (let ((container (org-export-get-parent link)))
-			 (if (and (eq (org-element-type container) 'link)
-  (org-html-inline-image-p link info))
-			 container
-			   link
-	(and (eq (org-element-map parent 'link 'identity info t) link)
-		 (org-export-read-attribute :attr_html parent
+	  (org-combine-plists
+	   ;; Extract attributes from parent's paragraph.  HACK: Only do
+	   ;; this for the first link in parent (inner image link for
+	   ;; inline images).  This is needed as long as attributes
+	   ;; cannot be set on a per link basis.
+	   (let* ((parent (org-export-get-parent-element link))
+		  (link (let ((container (org-export-get-parent link)))
+			  (if (and (eq (org-element-type container) 'link)
+   (org-html-inline-image-p link info))
+			  container
+			link
+	 (and (eq (org-element-map parent 'link 'identity info t) link)
+		  (org-export-read-attribute :attr_html parent)))
+	   ;; Also add attributes from link itself.  Currently, those need
+	   ;; to be added programmatically before org-html-link is invoked,
+	   ;; for example, by backends building upon HTML export, such as
+	   ;; org-reveal.
+	   (org-export-read-attribute :attr_html link)))
 	 (attributes
 	  (let ((attr (org-html--make-attribute-string attributes-plist)))
 	(if (org-string-nw-p attr) (concat " " attr) ""
-- 
2.17.1

Re: [O] PATCH: Allow class attribute for headline in HTML export

[Jens Lechtenboerger]

Hello!

On 2018-12-08, at 12:46, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> Function org-reveal-headline calls org-html-headline to generate
>> h-elements.  Of course, I could parse the generated HTML in
>> ox-reveal and add a class attribute based on org properties, but
>> doing so in ox-html seems much cleaner to me.  (Besides, given the
>> current situation of ox-reveal [1], that change would only make it
>> into my fork, not into the original project.)
>
> Fair enough. I applied your patch on "next" branch.

Thank you, I really appreciate this change!

Best wishes
Jens

Re: [O] PATCH: Allow class attribute for headline in HTML export

[Jens Lechtenboerger]

Hello,

On 2018-12-04, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> I plan to use that for a table-of-contents plugin [1] of reveal.js,
>> which looks for class attributes inside h-elements to exclude them
>> selectively.
>
> Then I suggest to submit it to "ox-reveal"
> (https://github.com/yjwen/org-reveal/) instead.

Function org-reveal-headline calls org-html-headline to generate
h-elements.  Of course, I could parse the generated HTML in
ox-reveal and add a class attribute based on org properties, but
doing so in ox-html seems much cleaner to me.  (Besides, given the
current situation of ox-reveal [1], that change would only make it
into my fork, not into the original project.)

Best wishes
Jens

[1] https://github.com/yjwen/org-reveal/issues/349

Re: [O] PATCH: Allow class attribute for headline in HTML export

[Jens Lechtenboerger]

On 2018-12-02, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:
>
>> From 068fb45f5276d61e86271988efbcf6c29e08c411 Mon Sep 17 00:00:00 2001
>> From: Jens Lechtenboerger 
>> Date: Sun, 2 Dec 2018 20:25:38 +0100
>> Subject: [PATCH] ox-html.el: New property HTML_HEADLINE_CLASS for class of
>>  headline
>
> Thank you.
>
>> * lisp/ox-html.el (org-html-headline): Add new property
>> HTML_HEADLINE_CLASS to assign class attribute to headline.
>
> Doesn't CUSTOM_ID already fit the bill?

Good morning,

I plan to use that for a table-of-contents plugin [1] of reveal.js,
which looks for class attributes inside h-elements to exclude them
selectively.

Best wishes
Jens

[1] https://github.com/e-gor/Reveal.js-TOC-Progress

Re: [O] PATCH: Allow class attribute for headline in HTML export

[Jens Lechtenboerger]

On 2018-12-02, at 19:25, Jens Lechtenboerger wrote:

> Dear all,
>
> the attached patch allows to add a class attribute to headline
> elements in HTML export.  Is that acceptable for inclusion?

In that patch, "when" should have been "if", sorry.  Fixed version
attached.

Best wishes
Jens

>From 068fb45f5276d61e86271988efbcf6c29e08c411 Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger 
Date: Sun, 2 Dec 2018 20:25:38 +0100
Subject: [PATCH] ox-html.el: New property HTML_HEADLINE_CLASS for class of
 headline

* lisp/ox-html.el (org-html-headline): Add new property
HTML_HEADLINE_CLASS to assign class attribute to headline.

* doc/org-manual.org: Document new property HTML_HEADLINE_CLASS.
---
 doc/org-manual.org | 6 +-
 lisp/ox-html.el| 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 458e59a4a..9d14c4cdc 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12780,7 +12780,11 @@ external file.
 In order to add styles to a sub-tree, use the =HTML_CONTAINER_CLASS=
 property to assign a class to the tree.  In order to specify CSS
 styles for a particular headline, you can use the ID specified in
-a =CUSTOM_ID= property.
+a =CUSTOM_ID= property or =HTML_HEADLINE_CLASS= as described next.
+
+#+cindex: @samp{HTML_HEADLINE_CLASS}, property
+In order to assign a class to a headline, use the =HTML_HEADLINE_CLASS=
+property.
 
 Never change the ~org-html-style-default~ constant.  Instead use other
 simpler ways of customizing as described above.
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 6a81be126..b043ab8fd 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2608,6 +2608,7 @@ holding contextual information."
 		  (format "\n" html-type
 	;; Standard headline.  Export it as a section.
 (let ((extra-class (org-element-property :HTML_CONTAINER_CLASS headline))
+	  (headline-class (org-element-property :HTML_HEADLINE_CLASS headline))
   (first-content (car (org-element-contents headline
   (format "<%s id=\"%s\" class=\"%s\">%s%s\n"
   (org-html--container headline info)
@@ -2616,9 +2617,12 @@ holding contextual information."
   (concat (format "outline-%d" level)
   (and extra-class " ")
   extra-class)
-  (format "\n%s\n"
+  (format "\n%s\n"
   level
   id
+			  (if headline-class
+			  (format " class=\"%s\"" headline-class)
+			"")
   (concat
(and numberedp
 (format
-- 
2.17.1

[O] PATCH: Allow class attribute for headline in HTML export

[Jens Lechtenboerger]

Dear all,

the attached patch allows to add a class attribute to headline
elements in HTML export.  Is that acceptable for inclusion?

Best wishes
Jens

P.S. The change is tiny, but I assigned copyright to the FSF in
2015.

>From e8f16b04903bc32c4ea006727c82dbcb40b591a8 Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger 
Date: Sun, 2 Dec 2018 19:05:55 +0100
Subject: [PATCH] ox-html.el: New property HTML_HEADLINE_CLASS for class of
 headline

* lisp/ox-html.el (org-html-headline): Add new property
HTML_HEADLINE_CLASS to assign class attribute to headline.

* doc/org-manual.org: Document new property HTML_HEADLINE_CLASS.
---
 doc/org-manual.org | 6 +-
 lisp/ox-html.el| 5 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 458e59a4a..9d14c4cdc 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12780,7 +12780,11 @@ external file.
 In order to add styles to a sub-tree, use the =HTML_CONTAINER_CLASS=
 property to assign a class to the tree.  In order to specify CSS
 styles for a particular headline, you can use the ID specified in
-a =CUSTOM_ID= property.
+a =CUSTOM_ID= property or =HTML_HEADLINE_CLASS= as described next.
+
+#+cindex: @samp{HTML_HEADLINE_CLASS}, property
+In order to assign a class to a headline, use the =HTML_HEADLINE_CLASS=
+property.
 
 Never change the ~org-html-style-default~ constant.  Instead use other
 simpler ways of customizing as described above.
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 6a81be126..d9d976753 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2608,6 +2608,7 @@ holding contextual information."
 		  (format "\n" html-type
 	;; Standard headline.  Export it as a section.
 (let ((extra-class (org-element-property :HTML_CONTAINER_CLASS headline))
+	  (headline-class (org-element-property :HTML_HEADLINE_CLASS headline))
   (first-content (car (org-element-contents headline
   (format "<%s id=\"%s\" class=\"%s\">%s%s\n"
   (org-html--container headline info)
@@ -2616,9 +2617,11 @@ holding contextual information."
   (concat (format "outline-%d" level)
   (and extra-class " ")
   extra-class)
-  (format "\n%s\n"
+  (format "\n%s\n"
   level
   id
+			  (when headline-class
+			(format " class=\"%s\"" headline-class))
   (concat
(and numberedp
 (format
-- 
2.17.1

Re: [O] Help with sharing emacs-org presentation

[Jens Lechtenboerger]

On 2018-10-25, Feiming Chen wrote:

> I gave a talk on emacs-org in a local workshop (Government Advances
> in Statistical Programming) in Washington D.C. yesterday.  I'd like to
> share the slides and org source file with the community (see attached).

Thanks for sharing!

I wonder why you stress the following:
- Not good for collaborative use (unlike Microsoft Office).
- Good for private, non-collaborative use.

My view is the opposite: Org mode is excellent for collaboration as
it is plain text, suitable for diff/merge in Git repositories.
Thanks to the separation of contents from style,
cross-organizational collaboration is possible, which I find *very*
hard with any office tool:  Changing a document master leads to all
kinds of layout destruction.  Switching to a different corporate
identity is just hard with what-you-see-is-what-you-get tools.

In contrast, Org mode can be a basis for what is called Single
Sourcing [1] in the context of technical writing.

You can see my approach towards Open Educational Resources with Org
mode at [2].

Best wishes
Jens

[1] http://rockley.com/articles/Single_Sourcing_and_Technology.pdf
[2] https://gitlab.com/oer/OS

Re: [O] org-crypt broken on Ubuntu 18.04

[Jens Lechtenboerger]

On 2018-06-14, Óscar Fuentes wrote:

> While trying to create a demo file I noticed that decryption works fine
> as long as the content was relatively new, while it fails for content
> that was encrypted years ago.
>
> I tried setting epg-gpg-program to "gpg" (it is "gpg2" by default) for
> encrypting some tests but then decryption worked fine on those tests.

Probably you encrypted without integrity protection, which was
always a bad idea but in view of EFAIL attacks has recently gained
lots of attention as Bad Thing.  Nowadays GnuPG returns a failure,
you can override that if you know what you are doing.

See there: https://dev.gnupg.org/T3714

Best wishes
Jens

Re: [O] org-reveal: content side by side

[Jens Lechtenboerger]

On 2018-02-13, Michael Welle wrote:

> That jumping of the headings is one of my main issues, I think it's not
> acceptable.

I see.  I don’t know how to fix the headings at the top and have the
contents vertically centered.

Best wishes
Jens

Re: [O] org-reveal: content side by side

[Jens Lechtenboerger]

On 2018-02-11, Michael Welle wrote:

> Looks easy, eh? A header at the top, a footer at the bottom and a lot
> of space in between. In some cases, like in [1], I wanted content (e.g.
> Ich...OS/2 Warp 4) to be centered horizontally and
> vertically between the footer and the header.

I created emacs-reveal [0] for my own slides.  Contents are centered
vertically (default for reveal.js).  CSS with “text-align: center”
can be used for horizontal alignment.

The howto for emacs-reveal is available at [1].  First-level
headings are centered vertically and horizontally.  I just added
slide 20 with horizontally centered text (underneath a heading,
which—as ugly hack—could just be a non-breaking space I guess).

I hope that helps and would be happy to help more.  (Responses may
be slow in the coming days, though.)

Best wishes
Jens

[0] https://gitlab.com/oer/emacs-reveal
[1] https://oer.gitlab.io/emacs-reveal-howto/howto.html

Re: [O] [PATCH] ox.el: Define subtitle macro

[Jens Lechtenboerger]

On 2017-11-21, Nicolas Goaziou wrote:

> For the record, I implemented a "keyword" macro (master branch).

Excellent, that works for me. 

Many thanks
Jens

Re: [O] [PATCH] ox.el: Define subtitle macro

[Jens Lechtenboerger]

On 2017-11-17, Nicolas Goaziou wrote:

> SUBTITLE keyword may not be supported in every back-end. As
> a consequence, supporting a global {{{subtitle}}} macro sounds
> presumptuous.
>
> Anyway, it begs for generalisation. The same problem is going to arise
> for CREATOR, KEYWORDS, and WHATNOT. Instead of {{{subtitle}}}, we could
> implement {{{option(KWD)}}}. Basically,
>
>   {{{option(SUBTITLE)}}} => (org-element-interpret-data (plist-get
> info :subtitle))
>
> Options with a `split' behaviour would need a special treatment,
> however.
>
> WDYT? Do you want to have a stab at it?

Thanks for your reply.  That would be great but goes way beyond my
current understanding of org internals.  I've never heard of `split'
behaviour.  Currently I don't have time to investigate this.

I'll stick with a local change for now.

Best wishes
Jens

Re: [O] [PATCH] ox.el: Define subtitle macro

[Jens Lechtenboerger]

On 2017-11-17, Rasmus wrote:

> Jens Lechtenboerger <lech...@wi.uni-muenster.de> writes:
>
>> the attached patch adds a subtitle macro with documentation.
>
> AFAIK it’s already added to the backends where it makes sense.  It’s not a
> basic keyword like "#+author".  It should be documented under the relevant
> backends that support it.

Sorry, I don't understand your suggestion.  I'm interested in
org-reveal [1], which is based on ox-html.el.  In ox-html.el,
subtitles are used at some hardcoded positions (preamble, postamble,
template), but I need access to the subtitle elsewhere.

What should I document where?

Best wishes
Jens

[1] https://github.com/lechten/org-reveal

[O] [PATCH] ox.el: Define subtitle macro

[Jens Lechtenboerger]

Hi there,

the attached patch adds a subtitle macro with documentation.

Best wishes
Jens

>From 3f54f515847f1f3034274d79fff6cfd1f92c72a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jens=20Lechtenb=C3=B6rger?= 
Date: Thu, 16 Nov 2017 15:03:33 +0100
Subject: [PATCH] Define and document subtitle macro

* lisp/ox.el (org-export-as): Define macro for subtitle.

* lisp/org-macro.el: Mention new macro in comment among others.

* doc/org.texi: Document new macro.
---
 doc/org.texi  | 2 ++
 lisp/org-macro.el | 2 +-
 lisp/ox.el| 6 --
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index e116a9b..3907eda 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -11080,9 +11080,11 @@ Org comes with following pre-defined macros:
 
 @table @code
 @item @{@{@{title@}@}@}
+@item @{@{@{subtitle@}@}@}
 @itemx @{@{@{author@}@}@}
 @itemx @{@{@{email@}@}@}
 @cindex title, macro
+@cindex subtitle, macro
 @cindex author, macro
 @cindex email, macro
 Org replaces these macro references with available information at the time of
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 1d2823e..c82bfd8 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -43,7 +43,7 @@
 ;;   {{{n(counter,action}}}.
 
 ;; Upon exporting, "ox.el" will also provide {{{author}}}, {{{date}}},
-;; {{{email}}} and {{{title}}} macros.
+;; {{{email}}}, {{{title}}}, and {{{subtitle}}} macros.
 
 ;;; Code:
 (require 'cl-lib)
diff --git a/lisp/ox.el b/lisp/ox.el
index cc3c48b..6feec3e 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3083,8 +3083,8 @@ Return code as a string."
 	 (let ((result (funcall filter info backend-name)))
 	   (when result (setq info result)
 	 ;; Expand export-specific set of macros: {{{author}}},
-	 ;; {{{date(FORMAT)}}}, {{{email}}} and {{{title}}}.  It must
-	 ;; be done once regular macros have been expanded, since
+	 ;; {{{date(FORMAT)}}}, {{{email}}}, {{{title}}}, and {{{subtitle}}}.
+	 ;; It must be done once regular macros have been expanded, since
 	 ;; parsed keywords may contain one of them.
 	 (org-macro-replace-all
 	  (list
@@ -3102,6 +3102,8 @@ Return code as a string."
 		 value)))
 	   (cons "email" (org-element-interpret-data (plist-get info :email)))
 	   (cons "title" (org-element-interpret-data (plist-get info :title)))
+	   (cons "subtitle"
+		 (org-element-interpret-data (plist-get info :subtitle)))
 	   (cons "results" "$1"))
 	  'finalize
 	  parsed-keywords)
-- 
2.1.4

[O] [PATCH] ox-publish.el: Fix regexp `match' to be non-nil

[Jens Lechtenboerger]

Hi there,

recursive publishing fails with base-extension any because a nil
regexp is passed.  The attached patch fixes this.

Best wishes
Jens

P.S. I did the necessary paperwork (copyright assignment) for Emacs.

>From 6584a78c350016e39c199bb61d203bc12c0c4c53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jens=20Lechtenb=C3=B6rger?= 
Date: Fri, 22 Sep 2017 11:30:13 +0200
Subject: [PATCH] ox-publish.el: Fix regexp `match' to be non-nil

* lisp/ox-publish.el (org-publish-get-base-files): Make sure `match'
is a string (not nil) before calling `directory-files-recursively'.
---
 lisp/ox-publish.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index 753176b..b592bc9 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -435,8 +435,9 @@ This splices all the components into the list."
   (let* ((base-dir (file-name-as-directory
 		(org-publish-property :base-directory project)))
 	 (extension (or (org-publish-property :base-extension project) "org"))
-	 (match (and (not (eq extension 'any))
-		 (concat "^[^\\.].*\\.\\(" extension "\\)$")))
+	 (match (or (and (not (eq extension 'any))
+			 (concat "^[^\\.].*\\.\\(" extension "\\)$"))
+		""))
 	 (base-files
 	  (cl-remove-if #'file-directory-p
 			(if (org-publish-property :recursive project)
-- 
2.1.4