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

2021-04-20 Thread 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

2021-04-20 Thread 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

2021-02-13 Thread 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

2021-02-12 Thread 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

2021-02-12 Thread 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

2021-01-14 Thread 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

2021-01-10 Thread 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

2021-01-03 Thread 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

2021-01-03 Thread 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

2021-01-03 Thread 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

2020-12-20 Thread 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

2020-12-16 Thread 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

2020-12-15 Thread 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

2020-12-14 Thread 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

2020-10-10 Thread 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

2020-09-28 Thread 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

2020-09-27 Thread 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

2020-09-27 Thread 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

2020-09-18 Thread 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

2020-09-17 Thread 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?)

2020-09-15 Thread 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?

2020-09-15 Thread 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?

2020-09-15 Thread 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?

2020-06-07 Thread 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/...

2020-05-24 Thread 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/...

2020-05-21 Thread 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/...

2020-05-21 Thread 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?

2020-02-17 Thread 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?

2020-02-16 Thread 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?

2020-02-14 Thread 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?

2020-02-14 Thread 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?

2020-02-14 Thread 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

2019-12-02 Thread 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

2019-12-02 Thread 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

2019-12-01 Thread 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?

2019-10-13 Thread 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?

2019-10-08 Thread 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?

2019-09-21 Thread 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?

2019-09-21 Thread 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

2019-07-26 Thread 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

2019-07-26 Thread 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

2019-07-25 Thread 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

2019-03-01 Thread 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

2019-03-01 Thread 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

2019-02-27 Thread 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

2019-02-27 Thread 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?

2019-02-09 Thread 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?

2019-02-08 Thread 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?

2019-02-08 Thread 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?

2019-02-08 Thread 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?

2019-02-08 Thread 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

2019-01-19 Thread 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

2019-01-19 Thread 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?

2018-12-14 Thread 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

2018-12-11 Thread 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

2018-12-11 Thread 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

2018-12-08 Thread 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

2018-12-08 Thread 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

2018-12-04 Thread 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

2018-12-02 Thread 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

2018-12-02 Thread 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

2018-12-02 Thread 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

2018-10-31 Thread 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

2018-06-13 Thread 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

2018-02-13 Thread 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

2018-02-13 Thread 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

2017-11-23 Thread 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

2017-11-19 Thread 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

2017-11-17 Thread 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

2017-11-16 Thread 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

2017-09-22 Thread 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



[O] Announce: Audio presentations with reveal.js from Org mode

2017-09-13 Thread Jens Lechtenboerger
Hi there,

you may be aware of Org-Reveal [1] to generate reveal.js [2]
presentations, which are HTML presentations, from Org mode.
I extended Org-Reveal to generate presentations with embedded audio
and bundled that along with some reveal.js plugins and necessary
configuration in the GitLab repository emacs-reveal [3].  Sample
presentations are available at [4].

I use the result for talks and teaching and believe it to be
particularly well-suited for presentations in the spirit of Open
Educational Resources (OER) [5], for the following reasons:
- Self-contained presentations, usable on lots of (including mobile
  and offline) devices with free software
- Separation of layout and content for ease of creation
- Text format for diff and merge for ease of collaboration

I hope this to be useful for your talks or teaching as well.
Feedback is highly appreciated.

Best wishes
Jens

[1] https://github.com/yjwen/org-reveal/
[2] http://lab.hakim.se/reveal-js/
[3] https://gitlab.com/oer/emacs-reveal
[4] https://oer.gitlab.io/OS/
[5] https://en.wikipedia.org/wiki/Open_educational_resources