Re: [O] [html-export question] location with JS.

[Christian Moe]

It still works fine for me in Firefox with the added title and text,
zooming in and out (except when the window becomes seriously too small,
and the year jumps up on top of the other one, but that, I think, has to
be expected).

A different problem is that the script only picks out every other
bol-year DIV, as you will soon see if you add more entries with boxes on
the left. The reason is that getElementsByClassName returns a live
HTMLCollection that updates according to the document order of the
elements even as the script changes that order. To loop through them,
try simply

var e = elements[0]; // instead of var e = elements[i];

Yours,
Christian

Rasmus writes:

 Hi Christian,

 Christian Moe m...@christianmoe.com writes:

 The issue is
 that the javascript that I use absolute position in pixels, and the
 browser doesn't update the location when zooming...

 Any ideas on how to solve this?

 Which browser? It seems to work well with zooming in Firefox and Safari,
 so I'd say you're doing something right and the browser's doing
 something wrong.

 For a moment I hoped it was just a bug in the larger stylesheet(!).
 Unfortunately, I think the nice behavior you saw was 'cause my example was
 too minimal...  Try the attached file which has a title.  I definitely see
 it here, zooming in and out, especially when the window ain't to large...

 BTW: I tested using Firefox and Gnome Web.

 (As you can guess from my attitude, though, I'm not a professional web
 developer.)

 As you can /see/, me neither...

 Thanks,
 Rasmus

Re: [O] mailto link with a subject and a content

[Christian Moe]

Hi,

This works fine for me with mu4e as the mail client. It's not guaranteed
to work with every client, but it can be a solution for personal
use. It's not necessarily the best solution.

The general syntax is mailto:address?subject=textbody=text

Some applications even allow adding attachments the same way
(...attachment=...), but mu4e doesn't seem to.

If you keep everything on one line and in a bracketed link, you don't
even have to worry about replacing spaces with %20:

[[mailto:w...@where.org?subject=Some wordsbody=Some more words]]

But it's probably recommendable to URL-encode spaces and punctuation,
and I find it's necessary if you have newlines. You can use the
url-encode-url function for this.

So the OP's example would be:

[[mailto:sub...@bugs.debian.org?subject=%20My%20problem%20with%20hkl...body=Package:%20hkl%0AVersion:%20@VERSION@%0A%0AI%20found%20this%20problem%20in%20hkl...]]

(The brackets are needed if you actually want to keep the trailing dots.)

Yours,
Christian

Eric Abrahamsen writes:

 PICCA Frederic-Emmanuel frederic-emmanuel.pi...@synchrotron-soleil.fr
 writes:

 Hello, I would like to create a link (exported as html) which allow to 
 prefill the content of the emai when we click on it.

 Something like

To: sub...@bugs.debian.org
Subject: My problem with hkl...

Package: hkl
Version: @VERSION@

I found this problem in hkl...

 Is it possible to do this kind of things with org-mode ?

 I think mailto: link syntax comes with GET-style parameters that allow
 prefilling of some headers, ie
 mailto:some...@address.com?subject=BugReport;, but that's pretty
 limited. John's right that if what you want is the above, you should
 probably just write some function to do it.

 Incidentally, when I just tried to test the above, org would only send
 the link to Conkeror, instead of opening in Gnus. Dunno what's going on
 there.

 Eric

Re: [O] exporting zotxt or orgref links to HTML and ODF

[Christian Moe]

Matt Price writes:

 My question: does anyone yet have a workflow that lets them export directly
 to HTML or ODT?

Hi, Matt,

Yes, now I have not just a workflow, but a code solution for
Org/Zotero/ODT export that has been tried and tested for a while. It now
supports multiple references in one citation, prefixes, suffixes,
locators, and year-only citations, and produces 'live' Zotero refmarks
in ODT, so you can do all the changes you want in LibreOffice
afterward. It also does some very limited but useful things for html
(DOI links and links that will work on Wordpress blogs with Katie
Seaborn's ZotPress extension).

It depends on Eric Hetzner's excellent zotero-plain and org-zotero
packages, and hence on the MozRepl extension on the Firefox side, though
you can use the ODT export functionality itself without those
dependencies.

I haven't yet announced it on the list, for three reasons. 1) Not very
polished. There's some messy code, a poor man's user interface, and no
editing support for multiple citations (but support for exporting
them!). 2) It's part of a more ambitious project I set myself for an
all-round citation system that I never got on with. 3) It uses this cool
idea I had for how to use citation links differently, but it imposes
certain syntax conventions on the user, and they may yet change in
backward-incompatible ways if I develop this further.

If this sounds interesting, I can post the code here 'as is' for you to
try out, but I'd better update the docs first, which could take a day or
two.

Yours,
Christian


 I've just tried using zotxt again (
 https://bitbucket.org/egh/zotxt-emacs/overview[1] -- first time in a while);
 it is remarkably easy to use in Org itself.  By default, though, the links
 simply aren't handled in the HTML and ODT exports, and so the cites will be
 completely absent.

 Here is the text inserted by zotxt for a single citation:

 

 [[zotero://select/items/0_TI27HJ5I][Suchman, Lucy. “Subject Objects.”
 Feminist Theory 12, no. 2 (August 1, 2011): 119–45.
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xml.[2]]]
 ---

 In HTML, I would like to replace this with something like this:

 (a href=#BibSuchman2011Suchman 2011/a)

 and then have Org generate a bibligraphy somewhere, a bit like org-ref
 seems to do, It would be nice if I could steal the styles from somehwere,
 the way org-ref seems to do.

 For ODT it seems a little more complicated. Here is the rather lengthy
 equivalent that Zotero itself produces for my default style (Chicago) in
 Libreoffice:
 ---
 text:note text:id=ftn0
 text:note-class=footnotetext:note-citation1/text:note-citationtext:note-bodytext:p
 text:style-name=Footnotetext:reference-mark-start
 text:name=ZOTERO_ITEM CSL_CITATION
 {quot;citationIDquot;:quot;5xzXuF2Iquot;,quot;propertiesquot;:{quot;formattedCitationquot;:quot;{\\rtf
 Lucy Suchman, \\uc0\\u8220{}Subject Objects,\\uc0\\u8221{} \\i Feminist
 Theory\\i0{} 12, no. 2 (August 1, 2011): 119\\uc0\\u8211{}45,
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xml.[3]}quot;,quot;plainCitationquot;:quot;Lucy
 Suchman, “Subject Objects,” Feminist Theory 12, no. 2 (August 1, 2011):
 119–45,
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xml.quot;[4]
 },quot;citationItemsquot;:[{quot;idquot;:149,quot;urisquot;:[quot;
 http://zotero.org/users/20/items/TI27HJ5Iquot;[5]],quot;uriquot;:[quot;
 http://zotero.org/users/20/items/TI27HJ5Iquot;[6]],quot;itemDataquot;:{quot;idquot;:149,quot;typequot;:quot;article-journalquot;,quot;titlequot;:quot;Subject
 objectsquot;,quot;container-titlequot;:quot;Feminist
 Theoryquot;,quot;pagequot;:quot;119-145quot;,quot;volumequot;:quot;12quot;,quot;issuequot;:quot;2quot;,quot;URLquot;:quot;
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xmlquot[7]
 ;,quot;ISSNquot;:quot;14647001quot;,quot;authorquot;:[{quot;familyquot;:quot;Suchmanquot;,quot;givenquot;:quot;Lucyquot;}],quot;issuedquot;:{quot;date-partsquot;:[[quot;2011quot;,8,1]]}}}],quot;schemaquot;:quot;
 https://github.com/citation-style-language/schema/raw/master/csl-citation.jsonquot;[8]}
 RNDuhNYYpC1hN/text:span text:style-name=T3Lucy Suchman, “Subject
 Objects,” /text:spantext:span text:style-name=T4Feminist
 Theory/text:spantext:span text:style-name=T5 12, no. 2 (August 1,
 2011): 119–45,
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xml.[9]/text:spantext:reference-mark-end
 text:name=ZOTERO_ITEM CSL_CITATION
 {quot;citationIDquot;:quot;5xzXuF2Iquot;,quot;propertiesquot;:{quot;formattedCitationquot;:quot;{\\rtf
 Lucy Suchman, \\uc0\\u8220{}Subject Objects,\\uc0\\u8221{} \\i Feminist
 Theory\\i0{} 12, no. 2 (August 1, 2011): 119\\uc0\\u8211{}45,
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xml.[10]}quot;,quot;plainCitationquot;:quot;Lucy
 Suchman, “Subject Objects,” Feminist Theory 12, no. 2 (August 1, 2011):
 119–45,
 

Re: [O] exporting zotxt or orgref links to HTML and ODF

[Christian Moe]

Well, color me embarrassed. I never even noticed the switch to
zotxt. And I never tried with Standalone either. Just tinkered happily
away with Eric's excellent old solution and Firefox. Maybe I should check
out both before posting an obsolute solution with unnecessary
dependencies...

Will report back in a little while.

Yours,
Christian

Matt Price writes:

 Christian,

 I would love to see this.  I am using Erik's rewritten
 zotero-plain/org-zotero (zotxt-emacs); it works fine with
 zotero-standalone, so MozRepl not required, I don't think.  I'm not sure if
 the link syntax is still the same as in the original versions.

 So yes, please do send the code if you are willing.  If you have hints
 about the more ambitious citation system, I and I'm sure others would love
 to see them.

 thanks,
 Matt


 On Tue, Jan 27, 2015 at 4:18 AM, Christian Moe m...@christianmoe.com
 wrote:


 Matt Price writes:

  My question: does anyone yet have a workflow that lets them export
 directly
  to HTML or ODT?

 Hi, Matt,

 Yes, now I have not just a workflow, but a code solution for
 Org/Zotero/ODT export that has been tried and tested for a while. It now
 supports multiple references in one citation, prefixes, suffixes,
 locators, and year-only citations, and produces 'live' Zotero refmarks
 in ODT, so you can do all the changes you want in LibreOffice
 afterward. It also does some very limited but useful things for html
 (DOI links and links that will work on Wordpress blogs with Katie
 Seaborn's ZotPress extension).

 It depends on Eric Hetzner's excellent zotero-plain and org-zotero
 packages, and hence on the MozRepl extension on the Firefox side, though
 you can use the ODT export functionality itself without those
 dependencies.

 I haven't yet announced it on the list, for three reasons. 1) Not very
 polished. There's some messy code, a poor man's user interface, and no
 editing support for multiple citations (but support for exporting
 them!). 2) It's part of a more ambitious project I set myself for an
 all-round citation system that I never got on with. 3) It uses this cool
 idea I had for how to use citation links differently, but it imposes
 certain syntax conventions on the user, and they may yet change in
 backward-incompatible ways if I develop this further.

 If this sounds interesting, I can post the code here 'as is' for you to
 try out, but I'd better update the docs first, which could take a day or
 two.

 Yours,
 Christian


  I've just tried using zotxt again (
  https://bitbucket.org/egh/zotxt-emacs/overview -- first time in a
 while);
  it is remarkably easy to use in Org itself.  By default, though, the
 links
  simply aren't handled in the HTML and ODT exports, and so the cites will
 be
  completely absent.
 
  Here is the text inserted by zotxt for a single citation:
 
  
 
  [[zotero://select/items/0_TI27HJ5I][Suchman, Lucy. “Subject Objects.”
  Feminist Theory 12, no. 2 (August 1, 2011): 119–45.
 
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xml.
 ]]
  ---
 
  In HTML, I would like to replace this with something like this:
 
  (a href=#BibSuchman2011Suchman 2011/a)
 
  and then have Org generate a bibligraphy somewhere, a bit like org-ref
  seems to do, It would be nice if I could steal the styles from somehwere,
  the way org-ref seems to do.
 
  For ODT it seems a little more complicated. Here is the rather lengthy
  equivalent that Zotero itself produces for my default style (Chicago) in
  Libreoffice:
  ---
  text:note text:id=ftn0
 
 text:note-class=footnotetext:note-citation1/text:note-citationtext:note-bodytext:p
  text:style-name=Footnotetext:reference-mark-start
  text:name=ZOTERO_ITEM CSL_CITATION
 
 {quot;citationIDquot;:quot;5xzXuF2Iquot;,quot;propertiesquot;:{quot;formattedCitationquot;:quot;{\\rtf
  Lucy Suchman, \\uc0\\u8220{}Subject Objects,\\uc0\\u8221{} \\i Feminist
  Theory\\i0{} 12, no. 2 (August 1, 2011): 119\\uc0\\u8211{}45,
 
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xml.}quot
 ;,quot;plainCitationquot;:quot;Lucy
  Suchman, “Subject Objects,” Feminist Theory 12, no. 2 (August 1, 2011):
  119–45,
 
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xml.quot
 ;
  },quot;citationItemsquot;:[{quot;idquot;:149,quot;urisquot;:[quot;
  http://zotero.org/users/20/items/TI27HJ5Iquot;],quot;uriquot;:[quot;
  http://zotero.org/users/20/items/TI27HJ5Iquot;
 ],quot;itemDataquot;:{quot;idquot;:149,quot;typequot;:quot;article-journalquot;,quot;titlequot;:quot;Subject
  objectsquot;,quot;container-titlequot;:quot;Feminist
 
 Theoryquot;,quot;pagequot;:quot;119-145quot;,quot;volumequot;:quot;12quot;,quot;issuequot;:quot;2quot;,quot;URLquot;:quot;
 
 http://resolver.scholarsportal.info/resolve/14647001/v12i0002/119_so.xmlquot
 
 ;,quot;ISSNquot;:quot;14647001quot;,quot;authorquot;:[{quot;familyquot;:quot;Suchmanquot;,quot;givenquot;:quot;Lucyquot;}],quot;issuedquot;:{quot

Re: [O] exporting zotxt or orgref links to HTML and ODF

[Christian Moe]

Matt Price writes:

 On Tue, Jan 27, 2015 at 8:30 AM, Rasmus ras...@gmx.us wrote:

 Hi,

 Christian Moe m...@christianmoe.com writes:

Actually, Rasmus wrote the following, not I.

 IMO we /need/ to add proper citation support to Org, preferably with a
 real syntax rather than these link-solutions and with good backend
 support (bibtex  Zotero for starters, I guess).

 #+begin_rant

 The current state is a mess and not portable.  E.g. there's at least two
 Zotero projects, there's John Kitchin's code, there's ox-bibtex.el (which
 IMO is not suitable for complicated citation requirements), plus everyone
 and their mother's have got custom citation links in their config via
 custom org link types...

 /Proper/ citation support (not links) is, IMO, the last thing that is
 missing for good academic publishing support.

But I don't necessarily disagree. I just figure I might try to prototype
the solutions I'd like to see toward the day someone steps up to the bat and
implements them in core with native syntax.

Yours,
Christian

Re: [O] exporting zotxt or orgref links to HTML and ODF

[Christian Moe]

Richard Lawrence writes:

 It looks to me like Pandoc has a quite general solution, and it also
 looks like Org could use Pandoc's citation syntax as-is.  I would
 suggest borrowing this syntax as a starting point for building citation
 support into Org.

It's been years since I looked at Pandoc, and I think they've added some
functionality since then. Prefix, locator, suffix, and multiple
references in one human-readable citation: Great! And /much/ nicer to
look at than latex \cite commands with their frankly bizarre placement
of locators etc.

 Blah blah [see @doe99, pp. 33-35; also @smith04, ch. 1].

In my current homebrewn solution for Zotero, I have tried to do
something similarly readable using Org link syntax (sorry, Rasmus!) with
the database entry ID as link target, and parsing the description part
for prefix/author-date/locator/suffix, but with a slightly different
syntax than Pandoc uses. In my solution the above would be:

Blah blah [[zotero:0_A43F89;0_E25CB3][(see: Doe 1999: p.33-35; also:
Smith 2004: ch. 1)]].

 A minus sign (-) before the @ will suppress mention of the author in the
 citation. This can be useful when the author is already mentioned in the
 text:

 Smith says blah [-@smith04].

In my current Zotero solution:

Smith says blah [[zotero:0_E25CB3][(2004)]].

 Does anyone have citation needs that this syntax doesn't cover?

It's great, as long as your database uses mnemonic citekeys like
doe99. Zotero doesn't, but uses keys that are meaningless to humans,
like 0_A43F89.  Unfortunately [see @0_A43F89, p. 5] wouldn't look nearly
as nice as [see @doe99, p.5], and it wouldn't help you remember what you
referenced.

I think the typical workflow combining Zotero with Pandoc is to export a
BibTex file from Zotero and reference the BibTex citekeys from
there. I could live with that much of the time.

But that workflow doesn't help with something I often want to do, which
is to export to ODT and have 'live' Zotero citations that I can continue
to work with in LibreOffice.

 Using this syntax would also have the advantage that Pandoc can already
 parse it, which would reduce friction for Org users who convert their
 documents with Pandoc (and Pandoc users who need to deal with Org
 inputs).  Since this seems like a significant contingent of Org users,
 that's something to consider.

That's a good point. OTOH, don't Org users convert their documents with
Pandoc mostly because cross-backend citation support is lacking? 

 The bigger question is whether, in addition to a citation *syntax*, it
 would be a lot of work to add support for the various citation database
 formats, as well as the various output styles, and which ones to
 support.

Possibly more work if it's worth if we adopt Pandoc syntax,
since Pandoc-citeproc seems to handle nearly everything that is based on
plain text.

To truly support citations natively, we'd essentially have to implement
something like citeproc in elisp. Not that I haven't been thinking about
that...

Yours,
Christian

Re: [O] ODT export: Issues with `org-export-footnote-first-reference-p'

[Christian Moe]

Hi,

Thanks for this. You have

  [fn:1] footdef1[fn:2]

  [fn:2] footdef2

What do you expect to see in ODT? Presumably not a footnote in a
footnote, since LibreOffice doesn't allow you to place one.

An ODT cross-reference to the footnote? That makes sense, but should
that be achieved by footnoting inside a footnote, or is the appropriate
thing to do to use a dedicated target and link?

  [fn:1] footdef1, see also [[thatotherfootnote]].

  [fn:2] thatotherfootnotefootdef2

That seems to works nicely e.g. in HTML export.

But I get an error message when I try it in ODT export (OpenDocument
export failed: number-or-marker-p, nil -- can't be more detailed at the
moment because my debugger doesn't seem to work correctly).

So either way, there seems to be something that needs fixing.

Yours,
Christian


Vaidheeswaran writes:

 The attached file, when exported to ODT fails to open in LibreOffice
 exporter.  The reason failure is that the exported __XML__ file has
 nested footnote definiton i.e., a footnote definition within a
 footnote definiton.  In concrete terms, there is some confusion wrt
 the return value of `org-export-footnote-first-reference-p'.

 (Hint: Start with `org-odt-footnote-reference'.  If my hunch is right,
 the `org-export-data' invocation there may also need a fix).

 I will be happy to circulate a patch to ox-odt.el.

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Christian Moe]

Also, Zotero items are typically identified by [library-ID]_[item-key]
hashes with an underscore separator.

Christian

Rasmus writes:

 Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes:

 I am complaining about how org-element.el behaves.

 This [cite:@adler_how_1972] becomes this:

 Oh, you are right.  _ is only allowed as the first character, as you
 probably saw.  See http://permalink.gmane.org/gmane.emacs.orgmode/95609.
 I would tend to agree that this is problematic, but _ is itself
 problematic since it's the subscription character...  From
 http://permalink.gmane.org/gmane.emacs.orgmode/95631 I gather that key
 support is modeled after Pandoc, but AFAIK Pandoc *does* support _ as part
 of the key cf. http://pandoc.org/README.html#citations.

 So yeah, I agree with you.

 –Rasmus

[O] [ODT][BUG] Custom link types in ODT footnotes

[Christian Moe]

Hi,

custom link types created with org-add-link-type seem to no longer work
in ODT footnotes. 

The expected output of the below example is for the bbdb link to be
replaced with /nil/ (I don't have Stallman in my address book) and for
SCREAMING LINK to be upcased if you've executed the source block. This
works in both body text and footnote for HTML export, but only in body
text, not footnote, for ODT. 

--- Example: 

#+title: Test of custom link types in footnotes

This is a bbdb:R.*Stallman link.[fn:1] 

#+begin_src emacs-lisp
  (org-add-link-type scream nil
 (lambda (path desc format)
   (upcase desc)))
#+end_src

This is a silly [[scream:234][screaming link]] for testing.[fn:2]

* Footnotes

[fn:1] This is a bbdb:R.*Stallman link in a footnote.

[fn:2] This is a silly [[scream:234][screaming link]] in a footnote.



Yours,
Christian

Re: [O] [ODT][BUG] Custom link types in ODT footnotes

[Christian Moe]

Hi,

I confirm it's fixed. Thanks! That was fast.

Yours,
Christian

Nicolas Goaziou writes:

 Hello,

 Christian Moe m...@christianmoe.com writes:

 custom link types created with org-add-link-type seem to no longer work
 in ODT footnotes. 

 The expected output of the below example is for the bbdb link to be
 replaced with /nil/ (I don't have Stallman in my address book) and for
 SCREAMING LINK to be upcased if you've executed the source block. This
 works in both body text and footnote for HTML export, but only in body
 text, not footnote, for ODT. 

 --- Example: 

 #+title: Test of custom link types in footnotes

 This is a bbdb:R.*Stallman link.[fn:1] 

 #+begin_src emacs-lisp
   (org-add-link-type scream nil
  (lambda (path desc format)
(upcase desc)))
 #+end_src

 This is a silly [[scream:234][screaming link]] for testing.[fn:2]

 * Footnotes

 [fn:1] This is a bbdb:R.*Stallman link in a footnote.

 [fn:2] This is a silly [[scream:234][screaming link]] in a footnote.

 

 This should be fixed. Thank you.


 Regards,

Re: [O] Continuing a numbered list

[Christian Moe]

DJ writes:

 I know how to get multiple paragraphs in one numbered list item. But how 
 can I stick a table in the middle of my multiple-paragraph list item 
 without terminating the list?

Try simply indenting the table. For aesthetics/reaability I like it to
line up with the list-item paragraph, but you should be OK as long as it
starts in any column to the right of the list item number.

Yours,
Christian

Re: [O] Numbering only *some* subheadings?

[Christian Moe]

You can do the opposite and number only the topmost headings, e.g. with

#+OPTIONS: num:1

but I don't think Org has a way to number only sub-headings. In HTML
export, you can get there with CSS hacks. For the exact example you
gave,

#+HTML_HEAD: style.section-number-2 {display: none;}/style

should hide heading numbering for the top heading level (add
more CSS if you have more heading levels). It won't fix the TOC, though;
with numbered headline export, the numbers are hardcoded in the TOC.

You could export without heading numbering, and add numbering to both
headlines and TOC items with CSS, but it's more involved. Again, for
your simple example you could do something like this.

#+OPTIONS: num:nil
#+HTML_HEAD: styleh3::before {counter-increment: subheadnum; 
#+HTML_HEAD:content: counter(subheadnum) . }
#+HTML_HEAD:h2 {counter-reset: subheadnum}
#+HTML_HEAD:#text-table-of-contents ul ul {list-style-type: 
decimal}/style

Yours,
Christian



Matt Price writes:

 I would like to number only a single subset of subheadings in an html
 export, so that, e.g.,

 * Introduction
 lorem ipsum
 * Coiurse Requirements
 lorem ipsum
 * Course Outline
 ** Introduction
 some long multi paragraph text.
 ** Origins of the French Revolution
 more text. Readings.
 ** Liberty, Equality, Fraternity?
 ... etc

 becomes:

 Introduction

 Course Requirements

 Course Outline

 1. Introduction
 bla bla bla
 2. Origins of hte French Revolution
 bla bla bla.
 Readings:  bla bla bla
 3. Liberty, Eaquality, Fraternity

 ... etc

 Is this possible? Anyone have a suggestion?

 Thanks as always,
 Matt

Re: [O] No ODT Export

[Christian Moe]

SabreWolfy writes:

 I'm using Org 8.2.4. C-c C-e does not offer any ODT export. Where should I
 start looking to solve this?

It's not included among export backends by default.

Adding

(add-to-list 'org-export-backends 'odt)

should do the trick.

Yours,
Christian

Re: [O] New maintainance team

[Christian Moe]

Thanks and a big hand of applause to all of you, and to Nicolas, for
making Org-mode keep on rockin'.

Yours,
Christian


Bastien writes:

 Hi all,

 thanks for the quick answers on helping me with the maintaince.

 Here is the new maintainance team:

   Kyle Meyer will watch Emacs development and merge changes there into
   the local Org repository.
   
   Elwood151 will be the contact for people who want to contribute and
   have their keys added to the server.
   
   Robert Klein will help maintaining the orgmode.org server and keep
   an eye on the Worg publishing process.
   
   Rasmus will handle the merge from Org into Emacs after each release.
   
 I will continue to release Org for now.

 THANKS a lot to everyone!

 I'm really glad we can move forward like this.

Re: [O] HTML Export, CSS Styling

[Christian Moe]

Hi,

See the first paragraph of the section Quoting HTML tags in the
manual.

In your example, you could do:

This is the paragraph body that will allow *bold* or /italic/ or
even _underline_, but what if I want only @@html:span style=color:
red;@@THIS@@html:/span@@ word to have styling?  Such as making
it red to indicate importance?

For repeat use and/or export of special styling to other backends than
ODT, you may want to simplify things a bit with macros.

Use e.g. this in the document head:

#+MACRO: red @@html:span style=color: red;@@$1@@html:/span@@

(reload the document or do C-c C-c on the above line to make Org notice
you've added it). Then you can do 

I want not only {{{red(THIS)}}} word to have styling, but
{{{red(THESE\, TOO)}}}.

Note that commas separate arguments to macros, so you need to
backslash-escape any commas appearing in the styled text, as in the
above example.

Going further, you can use a macro with two arguments to have a choice
of colors:

#+MACRO: color @@html:span style=color: $1;@@$2@@html:/span@@
   
I want {{{color(red, THIS)}}} word to be colored red, but
{{{color(green, THIS ONE)}}}? to be green.

where the first argument (before the unescaped comma) is a color keyword
or code CSS can recognize.

(As an alternative to macros, some people define their own link types
with concomitant export functions just for styling text and hiding all
the necessary brackets out of sight. Requires elisp, offends purist
views of what links should mean, and is bad for document
portability. Originally my idea, I'm afraid.)

Hope this helps,

Christian

David A. Gershman writes:

 I've been reading all evening about HTML exporting, style sheets, etc. 
 Maybe I've been inundated with information, but I haven't been able to
 determine an answer to my question: can text in the middle of a
 paragraph by styled?  For example:

 * Heading 1
This is the paragraph body that will allow *bold*
or /italic/ or even _underline_, but what if I want
only THIS word to have styling?  Such as making it
red to indicate importance?


 I'm working on lecture notes and I was planning on a span/span tag
 so I can set the color and, ultimately, a 'title' attribute for a
 definition when hovered.  However, I'm only finding the #+HTML feature
 within org which seems to need to be on a line of its own.  Howver, the
 export would convert:

   This is the paragraph body that will allow *bold*
or /italic/ or even _underline_, but what if I want
only
 #+HTML: span.THIS/span
word to have...

 to 3 different paragraphs:

This is the paragraph body that will allow *bold*
or /italic/ or even _underline_, but what if I want
only
THIS
word to have...

 Am I missing something or is in-line styling just not a feature within
 Org (yet?)?

 Thanks!

 --David

Re: [O] prompt for deadline in capture template?

[Christian Moe]

Matt Lundin writes:

>> Xebar Saram writes:
>>
>>> Hi guys
>>>
>>> i looked in the capture docu but couldn't seem to find it. anyone knows how
>>> to prompt for deadline in capture template?
>
> If you want to do it more pragmatically, you could use something like
> this (adjust the template as needed).
>
> (add-to-list 'org-capture-templates
>  '("d" "Deadline" entry
>(file "~/org/inbox.org")
>"* %^{Headline}\n DEADLINE: %^t"))
>
> See (info "(org) Template expansion")

My template for work projects includes this fragment:

"* TODO %^{Title} %^g\n SCHEDULED: %^{Scheduled to begin}t DEADLINE:
%^{Deadline}T\n [...]"

Note the t's after the prompts, asking specifically for the date (t) to
start work and and date + time (T) for the deadline.

Yours,
Christian

Re: [O] subject tree listing from publish

[Christian Moe]

For a listing by a hierarchy of subject, I think the index system does
what you want and is the only approach that does what you want out of
the box. But if I understand correctly, you already have an index, and
want this to be a separate listing?

Yours,
Christian


Greg O'Keefe writes:

> Hi,
>
> I keep a directory of notes as .org files, and use publish to generate
> .html from them.  This produces sitemap.html - a table of the #+TITLEs, and
> theindex.html built from #+INDEX entries I have added.
>
> I would like a third summary .html page which lists the notes organised in
> a tree by subject classification, where the subject classification is
> something like the ACM Computing Subject Classification or the Dewey
> Decimal system, or some cut-down version of these.
>
> The result would look a bit like this, where the _underlined_ items are
> links to notes.
>
> Information Technology
> Software and its Engineering
> Modelling Languages
> _Dynamic Logic for UML Sequence Diagrams_
> Computing Methodologies
> Knowledge Representation
> _Translating ACL to FOL_
>
> Reading the  manual, it looks like I could use TAGS to give the notes
> subjects, and use these to do searches over the whole project in emacs.
> This, and the way theindex.html is produced by including a simple looking
> theindex.inc text file makes me think that the solution may not be very
> hard. However, my lisp is very weak :-(
>
> Any suggestions or code most welcome!
>
> Cheers,
>
> Greg

[O] Update hangs on compiling org-timer.el

[Christian Moe]

Hi,

Anyone else seeing this?

I'm trying to update Org for the first time in ages, using "make
update2" on Mac OS X 10.6.8. (No, haven't upgraded that for a while,
either.)

The process gets as far as "Compiling path/to/lisp/org-timer.el" and
hangs there until I kill it.

Yours,
Christian

Re: [O] small caps

[Christian Moe]

Thomas S. Dye writes:

> Sorry, I forgot to give an example.  I use it like this [[sc:ad][AD]].
>
> The advantage of a link over a macro is that the link should export
> correctly to both LaTeX and HTML.
>
> If you intend to export to a single backend, then Nicolas' suggestion to
> use a macro is simpler.

Though you could support multiple backends with a macro, too, you just
need to use lots of @'s. E.g.:


#+MACRO: sc @@latex:\textsc{$1}html:$1@@

Already in 400 {{{sc(bc)}}}, the Greeks...


That's for a quick example; better to use  or
something and put the CSS in a separate stylesheet, of course.

Yours,
Christian

Re: [O] Show first leaf heading on startup

[Christian Moe]

You could set a VISIBILITY property manually, but that solution of
course is not robust to changes in outline and does not automatically
carry over to other documents.

[[info:org#Initial visibility]]

Yours,
Christian

Shankar Rao writes:

> How can I make it so that on startup, only the content of the first "leaf"
> heading is revealed, so that the document looks like:
>
> * Heading A
> ** Subheading AA
> *** Subsubheading AAA
> Stuff about topic AAA
> *** Subsubheading AAB ...
> ** Subheading AB ...
> * Heading B ...
>
> Shankar Rao

Re: [O] convert a simple list of lines each to a orgmode header

[Christian Moe]

> Xebar Saram  writes:
>
>> Hi all
>>
>> im looking for a simple way toconvert a simple list of lines (i can
>> mark it first if needed) each to a orgmode header anyone has such a
>> way?
>>
>
> Maybe I'm missing something, but can't you just add asterisks in front
> of each line? Maybe with a keyboard macro? Or even a sed script?
>
> There's a reason that org files are plain text.
>
> Nick

Mark the region and do `C-c *'?

Yours,
Christian

Re: [O] Add custom CSS class to code section?

[Christian Moe]

Hi,

#+BEGIN_foo
#+BEGIN_SRC R 
  system.time( result <- doSomething() )
#+END_SRC
#+END_foo

will wrap your code section in a  element.

Yours,
Christian

Williams, Ken writes:

> Hi,
>
> In http://orgmode.org/manual/CSS-support.html , I can see how to style 
> Org-Mode's existing CSS classes in my exported HTML document.  What I can’t 
> see is how to add a custom class to a code section, something like this:
>
> #+BEGIN_SRC R :class foo
> system.time( result <- doSomething() )
> #+END_SRC
>
> I want this because I’m trying to style some code blocks differently than 
> others – specifically, I want some to be default-collapsed in my HTML output, 
> and some to be default-expanded.
>
> *Ideally* this would actually be controlled by highjacking the existing 
> ":exports" header argument, but I don’t know how to do that either.
>
> Any tips?
>
>  -Ken
>
>
> 
>
> CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the 
> intended recipient(s) and may contain confidential and privileged 
> information. Any unauthorized review, use, disclosure or distribution of any 
> kind is strictly prohibited. If you are not the intended recipient, please 
> contact the sender via reply e-mail and destroy all copies of the original 
> message. Thank you.

Re: [O] Open Peer-Review Reproducible Publication with Org and GRASS

[Christian Moe]

This is really interesting on several levels. Thanks for posting.

Yours,
Christian

Ken Mankoff writes:

> Hi Org and GRASS lists,
>
> I just wanted to let these two lists know that I've just posted a paper 
> written in Org and using GRASS (text-mode) and Python for the analysis. My 
> goal was to create not just an open access publication, but a fully 
> reproducible publication. This is an early announcement, and the paper may 
> not pass peer review.
>
> The Supplemental Material is the Org file with all the code to generate the 
> document, beginning with downloading the 3rd party data that is input to our 
> analysis, the GRASS code to perform the analysis, and the Python code to 
> regenerate the figures.
>
> I don't think I did a great job on the reproducible part because I have a 
> highly customized .emacs, etc. All the information necessary to replicate the 
> work should be in the Supplemental Material, but it might not be easy to do 
> so. Anyway, I think it is a step in the right direction.
>
> To make it easier to reproduce... including my emacs.org seems overkill. 
> Including a Virtual Machine that contains everything, including my 
> ~/.emacs.d/ and all the software and data seems like the right thing to do, 
> but journals don't want to host a 20 GB VM with the publication.
>
> Thanks to people on these two lists who have developed the software and 
> helped me use it.
>
>-k.
>
> http://www.the-cryosphere-discuss.net/tc-2016-113/

Re: [O] Filling a list of dates in a spreadsheet

[Christian Moe]

Hi,

S- (Shift-Return) is your friend. After you've entered the first
two dates, move down to the third row (which needs to be empty), and hit
S-. You can continue pressing S- without moving down a row
each time.

Yours,
Christian



Cameron Horsburgh writes:

> Hi folks,
>
> I'm putting together a spreadsheet in org-mode. This is the general format:
>
> |--+---+|
> | Date | Field One | Field Two  |
> |--+---+|
> | [2016-02-07 Sun] |   ||
> | [2016-02-14 Sun] |   ||
> | [A few lines]|   ||
> | [A few more lines]   |   ||
> | [2016-12-25 Sun] |   ||
> |--+---++
>
> The date column needs to have a list of dates for every Sunday this year.
> In a traditional spreadsheet program there would be a function to 'fill'
> the series of dates automatically. I can't see anything in org-mode that
> would do this. Am I missing something, or will I just have to do it
> manually?
>
> Thanks!
>
> Cameron Horsburgh

Re: [O] Numbered list counting down?

[Christian Moe]

Hi,

This will work:

1.  [@3] Third
2.  [@2] Second
3.  [@1] First

Yours,
Christian

Peter Davis writes:

> I'm trying to create a numbered list where the numbers count down 
> instead of up. As I understand this: 
> , the following should work:
>
> 
> * Countdown list
>
>   [@3] Third
>   [@2] Second
>   [@1] First
> 
>
> But in fact, I just get a paragraph like with all the list elements run 
> together.
>
> Am I misunderstanding this?
>
> Thanks,
> -pd

Re: [O] make test is failing? [ob-fortran stuff]

[Christian Moe]

I always fail the Fortran tests too, on Mac OS X 10.6.8, though
supposedly there's a Fortran interpreter in there somewhere.

Yours,
Christian

Kaushal Modi writes:

> Hi all,
>
> I cloned a fresh copy of org-mode and ran "make test" for the first time.
>
> The following are failing:
>
> 3 unexpected results:
>FAILED  ob-fortran/list-matrix-from-table1
>FAILED  ob-fortran/list-matrix-from-table2
>FAILED  ob-fortran/list-var-from-table
>
> Is it known? Or it's failing just for me?
>
> I am running Emacs version: GNU Emacs 25.0.91.1 (x86_64-unknown-linux-gnu,
> GTK+ Version 2.24.23) of 2016-02-21, built using commit
> e19c1c301700430ae428f40c2a364671f5d50dcf.
>
>
> --
> Kaushal Modi

Re: [O] Spreadsheet: Conditionally apply formula to cell?

[Christian Moe]

Hi,

Yes, there is. See the manual on logical operations in "Formula syntax
for Calc", which gives an example for almost exactly the same thing.

 | 1 | 2 | 13 |
 |   |   ||
 #+TBLFM: $3=if("$1" == "nan" || "$2" == "nan", string(""), $1+$2+10);E

Yours,
Christian

Loris Bennett writes:

> Hi,
>
> If I have
>
> | 1 | 2 | 13 |
> |   |   | 10 |
> #+TBLFM: $3=$1+$2+10
>
> is there a way to suppress calculation of column 3 if, as in row 2, the
> entry in column 1 is empty?
>
> Cheers,
>
> Loris

Re: [O] How to do proper folding and semantic markup

[Christian Moe]

Eduardo Mercovich writes:
>
> ... place the abstract and #+LATEX: commands for frontmatter before the
> first exported headline, e.g.,
> #+BEGIN_abstract
>   [Abstract here]
> #+END_abstract

Originally my fault for pointing out that this was possible (for latex
and html backends, anyway) without any special abstract handling. :-)

https://lists.gnu.org/archive/html/emacs-orgmode/2010-11/msg00046.html

> The question is: how do I use the 1st header (keeping it's folding and
> referencing in org) while at the same time expressing that it is an
> abstract?

One can fold a block manually. However, it won't be automatically folded
when a file is opened or when when cycling the whole buffer through
folding states with C-u TAB. If these matter to you (I gather that you
have to write long abstracts), you may need to use the ignore trick
Thomas Dye referred to.

You can name a block and reference it by name.

#+name: theabstract
#+begin_abstract
  ...
#+end_abstract

See [[theabstract][the abstract]].

> How (if) can be done not only before the ToC, LoF and LoT but
> after them? 

You can control placement with a #+TOC: line. Do you need to do
something more?

An OS X upgrade just nuked my unix toolchains, including latex, so I
haven't checked how things work there.

Yours,
Christian

[O] Test failures on update

[Christian Moe]

Hi,

I just updated to the current 8.3.4 after a system upgrade (Mac OS X
10.11, fresh Emacs 24.5.1 installed via Homebrew).

When trying to =make up2=, I got 79 "unexpected" failures. About the
same as I recall from some months back, but far more than I used to. Are
other people getting this many test failures? Are other Mac users?

Some of these involve ob-fortran. They've never ever worked on my sysem,
and I've wondered how to turn them off, anyway, so that's OK. Some of
them may be about unix tools that were lost in the OS upgrade (though I
had similar results before the upgrade), or Mac idiosyncracies to do
with shells and paths. Others look more worrisome.

I attach the list of failures, in case maintainers find it useful. Let
me know if you need other information (that I can provide by following
simple instructions).

Yours,
Christian


#+begin_example
Ran 619 tests, 540 results as expected, 79 unexpected (2016-04-06 12:44:45+0200)
8 expected failures

79 unexpected results:
   FAILED  ob-C/inhomogeneous_table
   FAILED  ob-C/integer-var
   FAILED  ob-C/list-list-var
   FAILED  ob-C/list-var
   FAILED  ob-C/preprocessor
   FAILED  ob-C/simple-program
   FAILED  ob-C/string-var
   FAILED  ob-C/table
   FAILED  ob-C/two-integer-var
   FAILED  ob-C/vector-var
   FAILED  ob-awk/input-none
   FAILED  ob-awk/input-src-block-1
   FAILED  ob-awk/input-src-block-2
   FAILED  ob-awk/tabular-input
   FAILED  ob-emacs-lisp/commented-last-block-line
   FAILED  ob-emacs-lisp/commented-last-block-line-no-var
   FAILED  ob-emacs-lisp/commented-last-block-line-with-var
   FAILED  ob-exp/exports-inline
   FAILED  ob-exp/exports-inline-code
   FAILED  ob-exp/noweb-no-export-and-exports-both
   FAILED  ob-exp/noweb-strip-export-ensure-strips
   FAILED  ob-exp/use-case-of-reading-entry-properties
   FAILED  ob-fortran/character-var
   FAILED  ob-fortran/command-arguments
   FAILED  ob-fortran/fortran-var-program
   FAILED  ob-fortran/input-var
   FAILED  ob-fortran/list-matrix-from-table1
   FAILED  ob-fortran/list-matrix-from-table2
   FAILED  ob-fortran/list-var
   FAILED  ob-fortran/list-var-from-table
   FAILED  ob-fortran/preprocessor-var
   FAILED  ob-fortran/simple-program
   FAILED  ob-shell/bash-uses-arrays
   FAILED  ob-shell/bash-uses-assoc-arrays
   FAILED  ob-shell/generic-uses-no-arrays
   FAILED  ob-shell/generic-uses-no-assoc-arrays
   FAILED  ob-tangle/comment-links-at-left-margin
   FAILED  ob-tangle/comment-links-numbering
   FAILED  ob-tangle/continued-code-blocks-w-noweb-ref
   FAILED  ob-tangle/jump-to-org
   FAILED  test-ob-lob/do-not-eval-lob-lines-in-example-blocks-on-export
   FAILED  test-ob-python/colnames-nil-header-argument
   FAILED  test-ob-python/colnames-no-header-argument
   FAILED  test-ob-python/colnames-no-header-argument-again
   FAILED  test-ob-python/colnames-yes-header-argument
   FAILED  test-ob-python/colnames-yes-header-argument-again
   FAILED  test-ob-shell/dont-error-on-empty-results
   FAILED  test-ob-shell/session
   FAILED  test-ob/combining-scalar-and-raw-result-types
   FAILED  test-ob/commented-last-block-line-no-var
   FAILED  test-ob/commented-last-block-line-with-var
   FAILED  test-ob/elisp-in-header-arguments
   FAILED  test-ob/indented-cached-org-bracket-link
   FAILED  test-ob/inline-src_blk-default-results-replace-line-1
   FAILED  test-ob/just-one-results-block
   FAILED  test-ob/multi-line-header-arguments
   FAILED  test-ob/org-babel-remove-result--results-default
   FAILED  test-ob/org-babel-results-indented-wrap
   FAILED  test-ob/parse-header-args
   FAILED  test-ob/parse-header-args2
   FAILED  test-ob/simple-named-code-block
   FAILED  test-ob/simple-variable-resolution
   FAILED  test-ob/specific-colnames
   FAILED  test-org-element/link-parser
   FAILED  test-org-export/expand-include
   FAILED  test-org-export/output-file-name
   FAILED  test-org-src/blank-line-block
   FAILED  test-org-table/org-at-TBLFM-p
   FAILED  test-org-table/org-table-TBLFM-begin
   FAILED  test-org-table/org-table-TBLFM-begin-for-multiple-TBLFM-lines
   FAILED  test-org-table/org-table-TBLFM-begin-for-pultiple-TBLFM-lines-blocks
   FAILED  test-org-table/org-table-calc-current-TBLFM
   FAILED  
test-org-table/org-table-calc-current-TBLFM-when-stop-because-of-error
   FAILED  test-org/entry-properties
   FAILED  test-org/open-at-point-in-comment
   FAILED  test-org/open-at-point-in-keyword
   FAILED  test-org/open-at-point-in-property
   FAILED  test-org/open-at-point/info
   FAILED  test-org/open-at-point/inline-image
#+end_example

Re: [O] [BUG] Capture template table line specification

[Christian Moe]

Hello,

Yes, apologies. Here's a fairly minimal example. In making it, I
discovered that capture works until I add the table-formula line. With
the formula, it fails as described below.

Yours,
Christian

#+title: Capture test


#+begin_src emacs-lisp
(setq org-capture-templates
   '(("x" "exercise" table-line 
	  (file+headline "~/org/capture-test.org" "Exercise")
	  "| %u | %^{Laps} | %^{Time} | 0 |" 
	  :table-line-pos "II-1")))
#+end_src


* Exercise

| Date | Laps | Time | Laptime |
|--+--+--+-|
| [2016-04-09 Sat] |2 |   67 |33.5 |
| [2016-04-11 Mon] |1 |   32 |  32 |
| [2016-04-13 Wed] |2 |   65 |32.5 |
|--+--+--+-|
|  |  |  | 0/0 |
#+TBLFM: $4=$3/$2


Nicolas Goaziou writes:

> Hello,
>
> Christian Moe <m...@christianmoe.com> writes:
>
>> Another odd problems after updating to Emacs 24.5 and Org
>> 8.3.4:
>>
>> I have a capture template that puts the captured info into a table line
>> before the second horizontal line of the table.
>>
>> Capture fails with this message:
>>
>> Capture template `x': Invalid table line specification "II-1"
>>
>> Far as I can tell from the manual, the specification is exactly right,
>> and it has always worked before.
>
> Could you share the template with an Org document to test it on?
>
> Thank you.
>
> Regards,

Re: [O] export to odt is not per default in the export menu

[Christian Moe]

This question pops up fairly often. I suggest that ODT should be
provided out of the box. It is clearly in demand. It meets the needs of
a whole segment of users that need to work with office software. Sure,
nothing prevents them from using it by adding a brief line to their init
file. But why not advertise it? It's a major feature and it works well.

Yours,
Christian

Eric Abrahamsen writes:

> Uwe Brauer  writes:
>
>> Hi
>>
>> When I use org-export-dispatch, then a list of possible formats pop up
>> but odt is not among them. Only if I explicitly call
>> org-odt-export-to-odt
>>
>> once, then this command pops up in the list. How
>> can I change this behaviour and have the odt export function in the
>> list??
>
> Somewhere in your init files, put (require 'ox-odt). Then it will always
> be available. Take a look at the other ox-* files, many of them are
> useful enough to always load by default.
>
> E

Re: [O] export to odt is not per default in the export menu

[Christian Moe]

>>> FWIW, I also think this would be a good thing to load by default.
>>
>> Done.
>
> Thanks very much, Nicolas!

+1!

Yours,
Christian

[O] [BUG] Capture template table line specification

[Christian Moe]

Hi again,

Another odd problems after updating to Emacs 24.5 and Org
8.3.4:

I have a capture template that puts the captured info into a table line
before the second horizontal line of the table.

Capture fails with this message:

Capture template `x': Invalid table line specification "II-1"

Far as I can tell from the manual, the specification is exactly right,
and it has always worked before.

Yours,
Christian

[O] [BUG] Failure to run sh source block

[Christian Moe]

I've hit a couple of odd problems after updating to Emacs 24.5 and Org
8.3.4 (freshly pulled). 

Trying to run a simple shell source block, e.g.

#+begin_src sh
  pwd
#+end_src

fails with this error:

org-babel-variable-assignments:sh: Symbol's function definition is void:
org-babel-get-header


Yours,
Christian

Re: [O] seeking advice on use of drawers vs blocks

[Christian Moe]

Hi,

The syntax document is at http://orgmode.org/worg/dev/org-syntax.html.
It defines drawers as a "greater element", and says that greater
elements may contain other greater elements. Exporting a sample block
wrapped in a drawer works fine with the d:t option. Other complications
may arise, though...

Yours,
Christian

Christian Wittern writes:

> Dear Christian,
> Thank you for your feedback.
> On 2016-04-05 16:54, Christian Moe wrote:
>> On the third hand, have you considered wrapping a block in a drawer?
> No, I had not considered this.  Let me play around with that idea for a
> while. Is this syntactically allowed? I remember there was a document
> discussed a while ago that would define org syntax, but I can't remember now
> where this document is.  Does anybody remember?
>
> All the best,
>
> Christian

Re: [O] OT: two interesting articles about (non-)reproducible research

[Christian Moe]

Rafael Laboissière writes:

> * Nick Dokos  [2016-04-08 14:54]:
(...)
>> 538.com has published a couple of interesting articles on some poli-sci 
>> research:
>>
>>  
>> http://fivethirtyeight.com/features/how-two-grad-students-uncovered-michael-lacour-fraud-and-a-way-to-change-opinions-on-transgender-rights/#ss-1
(...)
>>  
>> http://fivethirtyeight.com/datalab/as-a-major-retraction-shows-were-all-vulnerable-to-faked-data/
(...)

> Ironically, the results "found" in the retreated paper by LaCour & Green 
> (2014) have been recently replicated by Broockman & Kalla (2016):
>
> http://www.sciencemag.org/news/2016/04/talking-people-about-gay-and-transgender-issues-can-change-their-prejudices

Partly replicated, according to the above links. Amazing effect of
canvassing against prejudice, yes; dependence on canvasser belonging to
victimized group, no.

Anyway, very interesting stuff that I'd have missed if not for the posts
here, OT or not. Thanks!

Yours,
Christian   

Re: [O] seeking advice on use of drawers vs blocks

[Christian Moe]

Hi,

Mandoku looks very nice -- an inspiration.

I don't really know enough about what your users do or how you want to
process the blocks to venture an opinion. On the one hand, for the sake
of simplicity and continuity for your users (to say nothing of
aesthetics), I'd say keep the drawer format, and add what functionality
you need to add by defining further conventions and writing code to
process drawer contents. Org blocks are many wonderful things, but
unobtrusive they're not, and they look quite intimidating when you start
adding header lines and parameters. On the other hand, when Org already
has these powerful blocks, it does seem a bit wasteful to reinvent the
wheel, as well as less portable.

On the third hand, have you considered wrapping a block in a drawer? It
would only look worse after you've opened it, and you could provide a
template for insertion so users don't have to remember where all the
colons and pluses go. If you only need the added metadata/functionality
for some annotations, and not always, that might be a solution.

Yours,
Christian Moe

Christian Wittern writes:

> Dear Orgmoders,
>
> Today I would like to poll the collective wisdom of the Orgmode user
> community about a design question I have.
>
> Since discovering org-mode more than 9.5 years ago (yeah! ), it has
> transformed my life almost as much, maybe even more than Emacs itself.
> Among other things, for work I have developed a package called Mandoku,
> which uses the org-mode format to deal with (classical) Chinese text.  For
> those interested, a description of this format, which is 99% org-mode is
> here[1].
>
> Now, as described at the very end of that page, I allow users to maintain
> annotations to things on the previous line of text in drawers. I then have
> scripts to collect these annotations and do various interesting things with
> them.  Now, since I started doing this some 6+ years ago, the org-mode
> syntax has seen some changes and especially blocks seem much more advanced
> now. I would like to have more expressive power concerning the content of
> the annotations, so I am considering switching to a block format for these
> annotations (or more likely for the time being, supporting both). This would
> give me more metadata and control over the content, because I can have
> header lines etc. However, my audience is somewhat non-technical and they
> concentrate on reading the texts, so the intrusion has to be minimal.
> Currently I handle that with the drawers being mostly folded and only
> expanded on demand with a  key on the line as usual, that is also the
> reason to use a short word for the drawer, which is the only thing seen in
> the folded state.
>
> So this does not work so nicely with blocks, especially if the header line
> expands.  Ideally I would even like to avoid seeing the header line in
> folded state and just have an icon in the margin to indicate that there is
> an annotation.  Does anybody know how this can be done? Has anybody done
> something similar?
>
> Apart from that, I wonder if there are other things to consider in the
> question: Should I move to block syntax rather than staying with drawers?
>
> Any and all comments appreciated,
>
> Christian Wittern
>
>
>
> [1] http://www.mandoku.org/mandoku-format-en.html

Re: [O] [BUG] Capture template table line specification

[Christian Moe]

Nicolas Goaziou writes:

> Fixed. Thank you.

Confirmed! Thank you.

Yours,
Christian

Re: [O] Row reference for :table-line-pos in a capture template.

[Christian Moe]

Hello,

Nicolas just fixed a bug related to this. If you can pull the latest
version, try and see if it works now.

Yours,
Christian

leho.y...@gmail.com writes:

> hello,
> I'm trying to use :table-line-pos in a capture template.
> I want add new line just after the third hline in the table. 
> I try "III" "III+" "III+1" "4"... Any ideas?
>
> this is the line in my org-capture-templates :
> ("X" "Test" table-line (file+headline
> "/media/yann/crypt/gtd/collecte/projets/test.org" "table") "| | | | |%t
> | |" :table-line-pos "4")
>
> and this is my files test.org :
>
> * table
> |---++---+-++---|
> |   |  Somme | Objet |  Compte | Date   |   |
> |---++---+-++---|
> | _ |  Total |   | ||   |
> | # | 140.00 |   | ||   |
> |---++---+-++---|
> |   | 60 | test2 |  03 | <2016-04-13 mer.>  |   |
> |   | 50 | test  | 12040538001 | <2016-03-12 sam.>  |   |
> |   | 10 | 10|13221312 | <2016-02-11 jeu.>  |   |
> |---++---+-++---|
> #+TBLFM:$Total=vsum(@III..@);%.2f 
>
> Thank you.
> Regards,
>
> Yann

Re: [O] verse (was: orgmode aquivalent of hfill?)

[Christian Moe]

Uwe Brauer writes:

> It seems that the verse environment does what I want, it is however
> exported in a ugly font (type writer), how can I change that font.

See the manual, section 12.9.4 "Applying custom styles".

Yours,
Christian

Re: [O] Patch: default CSS class for SVG images in HTML export

[Christian Moe]

Jarmo Hurri writes:

> If this patch is ok, then what is missing are the default CSS settings
> for the new class org-svg in constant org-html-style-default. I simply
> did not know what to put there. The manual says that this constant has
> basic settings for _all_ defined CSS entities. Either defaults need to
> be set for the new class, or the text in the manual needs to be
> changed. Or we have to accept that the manual is not logically
> coherent. :-)

Logically, no settings could be the default settings, couldn't they?
:-)

Perhaps a percentage width, maybe 80% or 90% to scale all SVGs to fit
neatly inside their container?

Yours,
Christian

Re: [O] Babel CALL no longer produces HTML output

[Christian Moe]

Jarmo Hurri writes:

>> Try:
>>
>> #+CALL: rekursio-pystyviivat[:noweb yes]() :results export html
>
> Greetings Christian,
>
> for some reason that did not improve the end result.

Sorry, I had that solution freshly in mind from a different problem
(involving #+INCLUDE, not #+CALL), and typed without thinking. I see
Charles Berry had the right answer.

Yours,
Christian

Re: [O] Request: change SVG embedding in exported HTML

[Christian Moe]

I disagree. A switch to  for SVG export (1) is not necessary for
scaling, and (2) would disable other useful features that are presently
available out of the box.

(1) It *is* a bit easier to scale SVG with  in HTML. But you *can*
scale SVG with  by putting the  in a container  and
scaling the container width and height.

This is actually simple with Org, which natively wraps the  in a
 tag, and passes any attributes to the latter.  To
scale an arbitrary image.svg e.g. to 100px width, try:

  #+attr_html: :width 100px
  [[path/to/image.svg]]

Alternatively, you can use #+attr_html to set an id on the figure ,
and style it with CSS.

(2) You can also do other things with  that you cannot with
, like manipulating the SVG with Javascript and styling it with an
external stylesheet (linked from the SVG, not the web page).

Raw SVG in the exported HTML is a third option that is very plain-texty
and supports all the mentioned features, but it tends to bloat files,
and doesn't encourage caching and re-using of an image across web pages.

To sum up,  makes the most common task simpler (scaling the
graphic), but at the cost of features such as interactive animated
graphics, which are possible with  or SVG islands.

Yours,
Christian

Scott Randby writes:

> On 07/23/2016 08:53 AM, Jarmo Hurri wrote:
>> 
>> Greetings.
>> 
>> Request: An SVG file embedded in exported HTML should be embedded using
>> the  tag instead of .
>
> I second this request. Right now, I use HTML code for SVG images, and
> I'd rather use Org markup instead.
>
> Scott Randby
>
>> 
>> Short reasoning: The displayed size of the SVG image can not be
>> controlled from outside the SVG file when embedded using , but
>> size can be controlled when embedded using .
>> 
>> Here is the longer explanation.
>> 
>> The HTML exporter currently embeds SVG as an object. Here is an example
>> of the HTML produced by the exporter:
>> 
>> 
>> 
>> Sorry, your browser does not support SVG.
>> 
>> 
>> 
>> I have in the past couple of days found out that there is a serious
>> disadvantage to this: the displayed size of the resulting web page image
>> can not be controlled in any reasonable manner; see, for example
>> 
>> https://css-tricks.com/scale-svg/
>> 
>> However, the size _can_ be controlled if embedding is done with an
>> . For example, the exported code above could be
>> 
>> 
>> 
>> 
>> 
>> I have included 'class="org-svg"' above so that embedded SVG images can
>> then be distinguished from other images in CSS files. For example, the
>> following CSS then sets the width of SVG images to be 80% of the width
>> of the viewport.
>> 
>> .org-svg
>> {
>> width: 80vw;
>> }
>> 
>> Current embedding using  has a nice textual fallback property
>> for browsers not capable of SVG (I have no idea if this support is
>> necessary nowadays). If need be, such fallback could also be added to
>> embedding using . See
>> 
>> http://www.w3schools.com/jsref/event_onerror.asp
>> 
>> Jarmo
>> 
>> 
>> 

Re: [O] Scaling HTML-exported SVG

[Christian Moe]

Jarmo Hurri writes:

> Greetings.
>
> Does anyone have any idea of how to scale an SVG figure produced by Org
> (Asymptote)? The exported HTML is
>
> 
> 
> Sorry, your browser does not support SVG.
> 
> 

(Suggested an answer on another thread. For completeness:)

You can scale the SVG by scaling the  element's container,
i.e. the  with class "figure". Setting attributes on the image link
with #+attr_html as usual should work, because they are passed to the
figure container rather than to the .

Either:

  #+attr_html: :width 200px
  [[path/to/image.svg]]


or:

  #+html_head_extra: #svgfig {width: 200px; }

  #+attr_html: :id svgfig
  [[path/to/image.svg]]

For this to work, the SVG needs to be written to be scalable (with
viewport set etc.).

Yours,
Christian

Re: [O] Request: change SVG embedding in exported HTML

[Christian Moe]

I also disagree with myself :-)  -- I wrote:

> To sum up,  makes the most common task simpler (scaling the
> graphic),

but the Org example I included seems to show that  can be just
as simple from Org. Forgot to edit the conclusion.

cm

Re: [O] Scaling HTML-exported SVG

[Christian Moe]

Jarmo Hurri writes:

> The method you suggested above - setting id - works (all tests done in
> Chrome).

Mine are in Firefox. 

> But setting id-values is cumbersome, because you need to do it
> for every file.
> It is also possible to set a CSS class similarly, that is, modifying
> your example above,
>
> #+html_head_extra: .svgfig {width: 200px; }
>
> #+attr_html: :class svgfig
> [[path/to/image.svg]]
>
> This also works and is better, because then it is possible to set a
> common class for all SVG figures, and handle them with a single CSS
> rule.

Sure, if they should mostly be scaled to the same size. I just didn't
make that assumption.

> Better, but not yet perfect, because I still need to add a
> attr_html to every SVG figure.

> But there seems to be a way around this. With the last approach the
> generated HTML looks something like
>
> 

Indeed. Now I'm confused, because this example seems to mean I got
several things wrong earlier today. First, it seems one *can* scale an
SVG image by setting attributes on the  element, not just by
scaling the container element as I thought. At least in FF and
Chrome. And second, Org passes attributes from #+attr_html to the
 element, not to the container  as I wrote, though I could
have sworn that was what I saw when I tested today. On that note, I
think I'll go to bed... But first:

> Why don't we just set a common class for all SVG-images in an HTML
> export by default? Then we could still use an  to embed it, and
> control its size from CSS.

> It seems to me that this solves the problem, and requires an extremely
> small change.

Me too. At least, I cannot think of any obvious disadvantages, and it
could be helpful if you want all or most of your SVGs to be scaled to
the same size (or otherwise styled the same way). Particularly if you
need to distinguish them from  tags embedding other media, like
videos.

(If you're *not* using  for anything beside SVGs, or at least
not in  environments, you could just style objects,
couldn't you?  e.g.:

  object { width: 200px; }

or slightly safer

  .figure object { width: 200px; }

But I agree that an explicit 'svg' class could be better.)

Yours,
Christian

Re: [O] Request: change SVG embedding in exported HTML

[Christian Moe]

Scott Randby writes:

>>   #+attr_html: :width 100px
>>   [[path/to/image.svg]]
>
> It has been awhile since I tried to scale an SVG image using Org markup,
> but I recall trying what you suggest and it didn't work. I will try
> again when I have some time and report the results to this list.

I think I've been there, too, in the past. But it Works for me with Org
8.3.4 in Firefox, and Jarmo Hurri now reports it working in Chrome (see
the thread "Scaling HTML-exported SVG").  It seems I got some details
wrong about *how* it works, though.

Yours,
Christian

Re: [O] verse

[Christian Moe]

Uwe Brauer writes:

>>> It seems that the verse environment does what I want, it is however
>>> exported in a ugly font (type writer), how can I change that font.
>
>> See the manual, section 12.9.4 "Applying custom styles".
>
> That section is a very general one, I cannot find anything about the
> verse environment and its setting.

The section is general because it tells you how to style *everything*,
including, but not limited to, verse environments. When exporting to ODT
you don't set fonts for particular environments in Org-mode. Rather, you
use an application like LibreOffice to modify and save a stylesheet, and
tell Org-mode what stylesheet to apply to exported ODT.

Export a document to ODT with the ugly verse environment, then either
locate the 'OrgVerse' style in the LibreOffice 'Stylist' and edit it
there, or simply right-click on a verse and choose 'Edit Paragraph
Style' from the menu. Choose a different font. Change any other styles
(e.g. headings) as you like. Save the modified document in a convenient
place, then use it as an Org ODT styles file as described in the manual.

Yours,
Christian

Re: [O] Tuning the layout of published html

[Christian Moe]

Hi,

No need for derived backends.

You could just add both the title bar and the navigation bar in the HTML
preamble to each page, and position the different parts as needed with
CSS.

If you're using Org's publishing function, define a :html-preamble in
org-publish-project-alist. 

Yours,
Christian


Jarmo Hurri writes:

> Greetings.
>
> I am writing teaching material (for programming) using Org. All the
> material (text, figures, code, program outputs) are written using Org
> and Babel-supported languages. Publishing to html works just fine. What
> I would like to do, however, is to add some layout structure to the
> produced html.
>
> More specifically, I would like to add, on all pages, a navigation bar
> on the left-hand side and a title bar with no functionality on the top
> of each page.
>
> What options do I have to accomplish this? Searches led me to "derived
> backends," but they sound like an overkill for a task that is this
> simple. Or?
>
> Jarmo

Re: [O] Tuning the layout of published html

[Christian Moe]

Jarmo Hurri writes:

>> and position the different parts as needed with CSS.
>
> This is where I don't know what exactly is going to happen. Org writes
> quite a bit of CSS in each exported HTML file. If I add in, say, a
> vertical navigation bar, how am I going to control its placement with
> respect to everything else that is already in the CSS?

Say you put the navbar at the end of the HTML preamble and give it a
#navbar id (). Org already gives the main content a
#content id. Then this should be all the CSS you need to get started:

#navbar { float: left;
  ...loads more CSS here...
  }
#content { float: left;
   ...and more CSS here...
   }

Yours,
Christian

Re: [O] Importing ODT/libreoffice into Org

[Christian Moe]

Eric Abrahamsen writes:

> I just had to convert a 200+ page document to Org by hand: searching
> for italics worked, but not replace.

Looks like pandoc is the way to go, I'll have to try it.

Still, Search/Replace for italics in LibreOffice ought to work. Try this
recipe:

1) Edit -> Find / Replace -> More options: check the box for "regular
   expressions".
2) On "Search for", type "(.*)" (without the quotes, with the parens).
3) With the cursor still on the "Search for" box, click on "Format" and
   select "Italics".
4) As a replacement, type: "/$1/" (for Org).
5) Replace all.

Annoyingly, there seems to be no way to write a macro for this in
LibreOffice, as formating attributes on search/replace isn't part of the
API. (If anyone has information to the contrary, please let me know.)

Yours,
Christian

Re: [O] odt macro export

[Christian Moe]

Ken Mankoff writes:

> This works:
>
> #+BEGIN_ODT
> 
> This paragraph is specially formatted and uses bold text.
> 
> #+END_ODT
>
> But this does not. Should it?
>
> #+MACRO: BEGIN_RC @@odt:@@
> #+MACRO: END_RC @@odt:@@
> {{{BEGIN_RC}}}
> This paragraph is specially formatted and uses bold text.
> {{{END_RC}}}

You can analyze the problem by examining the content.xml part of the ODT
document. (On my system, simply opening the ODT file in Emacs reveals
the unzipped files in dired; your settings may vary.)

In this case, your source is already treated as a block and wrapped in a
 element, so macro expansion results in a  illegally wrapped in a
:

#+begin_example
  
  
  This paragraph is specially formatted and uses bold text.
  
  
#+end_example

This makes it different to style a paragraph block with macros. You
could add closing and opening tags to the macros, but that would result
in empty paragraphs (double spacing) on either side.

However, following the example in the Info, you could create a bold
character style, and use the inline  instead of the block
 in your macro. Actually, my version of LibreOffice has a "Bold"
character style pre-defined, so I can just do this:

#+begin_example
  #+MACRO: BEGIN_RC @@odt:@@
  #+MACRO: END_RC @@odt:@@

  {{{BEGIN_RC}}}This paragraph is specially formatted and uses bold 
text.{{{END_RC}}}
#+end_example

This should solve your use case. It does not provide a convenient method
if you want to affect paragraph-style properties rather than
character-style ones, though.

Yours,
Christian

Re: [O] Babel CALL no longer produces HTML output

[Christian Moe]

>   #+CALL: rekursio-pystyviivat[:noweb yes]() :results html

HTML blocks have been replaced with EXPORT blocks in recent Org. For
good reasons, I presume, but it takes some getting used to.

Try:

#+CALL: rekursio-pystyviivat[:noweb yes]() :results export html

Yours,
Christian

Re: [O] [Ann] Tool to hack time

[Christian Moe]

Here I was, hoping it was a tool to *actually* hack time.

You know, M-x tardis-mode.

:-)

Yours,
Christian



Marco Wahl writes:

> Dear Orgers,
>
> https://gitlab.com/marcowahl/hack-time is a little tool to forge the
> `current-time' in Emacs.  This allows to mark todo-items done
> conveniently at another date.
>
> Maybe you want to play with that time forgery.
>
> Comments welcome, as always.
>
>
> Best regards
>
>Marco

[O] [DOCS] Re: Making DocBook xml books from org mode?

[Christian Moe]

Peter Davis writes:

>  3. The direct route from org to DocBook xml seems to be missing.

It's gone extinct, but there is a fossil record of it in the online
manual:

  http://orgmode.org/guide/DocBook-export.html

It's not linked to from the TOC, but turned up in a DuckDuckGo
search. It should probably be carefully excavated and placed in the
Museum of Paleorgology.

Yours,
Christian

Re: [O] apply attr_html to a whole figure?

[Christian Moe]

I don't think Org syntax provides any way to do this at present, but
ignore the rest of this message if anyone knows better.

Possible workarounds:

1. Wrap your figure in a #+BEGIN_ADDITIONALCLASS...#+END_ADDITIONALCLASS
block, to wrap the div.figure in a div.additionalclass. Not exactly what
you wanted, and a pain in the neck if you have many such figures, but
gives you enough to work with in CSS.

2. Add javascript to move the extra class attribute from the img to
the containing div. 

3. Write an export filter.

Yours,
Christian


Matt Price writes:

> When exporting images with captions, ox-html currently creates a strucuture 
> like this:
>
>
> div class=figure
> pimg src=./images/hlevel.png 
> alt=hlevel.png
> /p
> pspan class=figure-numberFigure 1:/span 
> test/p
> /div
>
> (Ive tried setting org-html-html5-fancy to t, but for whatever 
> reason this doesnt result in the useo f the figure tag. I tried 
> with emacs -q with no luck).
>
> I would like to be able to give an additional class to the enclosing div 
> class=figure. Any idea how i might be able to do that? As far 
> as I can see, org-html--wrap-image does not have access to the org link 
> element and so cant query for attributes. 
>
> I really appreciate any ideas! Thanks,
> Matt
>
>  

Re: [O] Inline HTML?

[Christian Moe]

David A. Gershman writes:


> My org file has:
>
> This is line one.
> This is line two.
>
> but the HTML export makes them different paragraphs...

Does it? If they're not separated by a blank line, the exporter should run them
together into one paragraph. Mine does.

> However, a separate portion of my file has a long line and I
> do /not/ want a new paragraph, just to force a :

Quoting HTML is one solution (as you've already discovered), but more
simply, you could do:

  
  This long line starts here \\
  and continues here.


Yours,
Christian

Re: [O] ODT export

[Christian Moe]

Haven't done this in a while, but I just tested, and ODT custom style files
work fine for me under Org 8.3.4. (Note: I haven't pulled the latest Org
changes; waiting for another package to catch up.)

I've never know this to fail as such. I did have a problem for a while
using .odt files as stylesheets on Mac under Snow Leopard, which
apparently didn't get the command Org used to unzip the ODT file and
extract the style document. I never found the fix, so for a while I
worked around it by extracting the style .xml manually and referenced that file
instead. Now everything seems to be working as it should, though.

Yours,
Christian

Eduardo Mercovich writes:

> Hi Philip.
>
>>> First time out, very disappointing and confusing results.
>>> Having created a styled example.odt file as per instructions in the 
>>> manual...
>>> [...]
>>> (info "(org) Applying custom styles")
>> Sanity check: anyone able to confirm they've done this successfully?
>
> I did it, but a looong time ago. I don't remember how to and since those
> times, I had a new machine and reinstalled emacs/org-mode from zero to
> make it clean, sorry I can't help.
>
> The good news is that -at least in some previous past- it worked. :)
>
> Best...

Re: [O] Remove Org from Emacs repository?

[Christian Moe]

+1.

(= Keep it in.)

Yours,
Christian

Carsten Dominik writes:

> Dear all,
>
> I'd hate to see Org removed from Emacs.  It took a lot of work to get it
> in, and I believe that the vast majority of Emacs users does not install
> packages.  For a newbie to get to Emacs and to be able to open a .org file
> is a big plus.  So my vote goes toward keeping it in.
>
> Carsten
>
> On Sun, Dec 18, 2016 at 10:22 AM,  wrote:
>
>> 2 cents from me...
>>
>> Besides I continuously see many users praising Emacs just for Org
>> presence (they even may be completely non-technical users), I'm
>> personally think Org may be removed from Emacs distribution because:
>>
>> 1) all Reuben's argument seems sane;
>> 2) there are situations when someone wants particular version of Org,
>>and it may be not tne one bundled with Emacs. In this case someone
>>should perform extra steps to ensure things are going the right way.
>>When Org will be available only from ELPA, it will be SPOT for such
>> cases.
>>
>> Reuben Thomas  writes:
>>
>> > Now that Emacs has had package.el for some years, and Org is installable
>> > directly from GNU ELPA, would it be a good idea to remove Org from
>> Emacs's
>> > source repository?
>> >
>> > The current situation is left over from before Emacs had package.el, and
>> I
>> > see no compelling reason to keep it. Org is too big and distinct to be
>> > swallowed by Emacs; it doesn't make much sense to keep its current
>> half-in,
>> > half-out state; so logically it seems sensible to take it out.
>> >
>> > I am asking this question from an Org point of view; I will ask the Emacs
>> > maintainers separately for their perspective.
>> >
>> > I think it would benefit Emacs too, as there would be less code to
>> maintain
>> > (even though Org is quasi-external at present, it still has to build
>> > successfully as part of an Emacs build), and the Emacs distribution would
>> > be slimmer for non-Org users.
>> >
>> > Of course, Emacs "distributions" would still be able to include Org
>> > out-of-the box if they wished.
>> >
>> > --
>> > http://rrt.sc3d.org
>>

Re: [O] Reproducing a table

[Christian Moe]

You can simplify it even further to

#+begin_src elisp :var data=my-table :hlines yes
  data  
#+end_src

which is sane enough for me.

To get simpler than that, I think you need #+INCLUDE and a separate
file.

I can't tell from the example why you need to define it in one place and
reproduce it in another, though, instead of just giving it a name right
where you want it to appear. (One situation where it would be helpful,
obviously, is if you want the same table to appear in multiple documents
that you export from the same .org file.)

Yours,
Christian


Jarmo Hurri writes:

> Greetings (again).
>
> What is the smartest way to reproduce a table without defining the table
> as an Org source block (constraint explained below).
>
> I can do the following, but it doesn't seem very sane (need to use elisp
> or some other language just to funnel the table).
>
> # -
> * define table
>   #+name: my-table
>   | row 1 | 1 | 2 |
>   | row 2 | 3 | 4 |
>   |---+---+---|
>   |   | col 1 | col 2 |
> * reproduce entire table
>   I need to be able to reproduce the entire table in my document
>   #+BEGIN_SRC elisp :var data=my-table :hlines yes
>   (print data)
>   #+END_SRC
>
>   #+RESULTS:
>   | row 1 | 1 | 2 |
>   | row 2 | 3 | 4 |
>   |---+---+---|
>   |   | col 1 | col 2 |
> * reproduce only data
>   I also need to be able to pass only the data to functions
>   #+BEGIN_SRC elisp :var data=my-table[0:1,1:2]
>   (print data)
>   #+END_SRC
>
>   #+RESULTS:
>   | 1 | 2 |
>   | 3 | 4 |
> # -
>
> The reason I can _not_ define the table as an Org source block is the
> second example. I need to pass parts of the table as data to functions,
> and constructs like my-table()[0:1,1:2] don't work. (At least I have not
> been able to get them to work.)
>
> Jarmo

Re: [O] Reproducing a table

[Christian Moe]

Jarmo Hurri writes:

> In some earlier version of Org the following
> used to work:
>
>   #+name: my-table
>   | row 1 | 1 | 2 |
>   | row 2 | 3 | 4 |
>   |---+---+---|
>   |   | col 1 | col 2 |
>
>   #+call: my-table() :hlines yes
>
> That is, in the past the table name used to sort of define a function
> which could then be called to reproduce the table. But this produced
> errors in the current version, so I started to figure out ways to
> achieve the same end result.

I see! I had no idea that this was possible, but it does indeed work for
me (I'm still on version 8.3.4).

Yours,
Christian

Re: [O] make test is failing? [ob-fortran stuff]

[Christian Moe]

I see. Thanks.

Yours,
Christian

Kaushal Modi writes:

> Turns out the Fortran compiler binary gfortran is part of GCC. Those
> fortran tests fail for GCC 4.4.7 but not when using GCC 6.1.0.
>
> On Tue, Feb 23, 2016 at 3:59 AM Christian Moe <m...@christianmoe.com> wrote:
>
>>
>> I always fail the Fortran tests too, on Mac OS X 10.6.8, though
>> supposedly there's a Fortran interpreter in there somewhere.
>>
>> Yours,
>> Christian
>>
>> Kaushal Modi writes:
>>
>> > Hi all,
>> >
>> > I cloned a fresh copy of org-mode and ran "make test" for the first time.
>> >
>> > The following are failing:
>> >
>> > 3 unexpected results:
>> >FAILED  ob-fortran/list-matrix-from-table1
>> >FAILED  ob-fortran/list-matrix-from-table2
>> >FAILED  ob-fortran/list-var-from-table
>> >
>> > Is it known? Or it's failing just for me?
>> >
>> > I am running Emacs version: GNU Emacs 25.0.91.1
>> (x86_64-unknown-linux-gnu,
>> > GTK+ Version 2.24.23) of 2016-02-21, built using commit
>> > e19c1c301700430ae428f40c2a364671f5d50dcf.
>> >
>> >
>> > --
>> > Kaushal Modi
>>
>> --
>
> Kaushal Modi

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Christian Moe]

So, user feedback: I'm fine with not enabling by default.

I don't use any of these, but it sounds like the new default expansion
mechanism Nicolas mentioned might suit me if I ever switch from my
homemade insert-block function (which does prompts and regions).

Yours,
Christian

Bastien writes:

> Hi Nicolas,
>
> Nicolas Goaziou  writes:
>
>> You disagreed with me in the first place with commit 71ad7b1. It was my
>> original intent to not load Org Tempo by default.
>
> Sorry if I missed the statement where you explicitely said you thought
> org-tempo should not be enabled by default, I thought it was just an
> oversight and I didn't realize I was in a disagreement with you when I
> pushed this commit -- if I thought so, I'd write to you on the list to
> raise the topic instead of forcing a change through a commit.
>
> Again, I may be wrong in thinking disabling this will cause trouble to
> many users.  Let's just take a moment to see what users think.
>
> Thanks,

Re: [O] Org citations, CSL and citeproc-el

[Christian Moe]

This is exciting news, and I look forward to trying it out.

Regarding syntax:

1. A couple of years back, there was an active discussion on this list to
flesh out a native citation syntax for Org. I fell off the discussion,
but I think it resulted in a non-link-based, feature-rich syntax spec,
but not much code to make use of it. Perhaps someone could comment?

2. Not many people liked my proposal: a link-based syntax similar to yours
but also including author and date in the link description. The idea was
to have descriptions that are both (1) human-readable even though the
citekeys are hidden away in the link path and (2) machine-readable to
determine the form of the citation (parenthetical or not, date-only or
not, etc.). I have used one to work with Zotero, and have a simple
parser for it, if you're interested in pursuing something similar.

Yours,
Christian

Simonyi András writes:

> Dear List Members,
>
> a few days ago I've released the first public version of citeproc-el
> (https://github.com/andras-simonyi/citeproc-el), a CSL 1.01 citation
> processor library for Emacs. Since the main motivation of my work was to
> contribute to org-mode's citation rendering I also implemented a "proof
> of concept" add-on to org-ref that uses citeproc-el to render org-ref
> citation links for non-LaTeX (and optionally even LaTeX) export backends
> (see https://github.com/andras-simonyi/citeproc-orgref).
>
> Both packages are in a relatively early stage of their development so
> I'd be grateful to receive any feedback on them. In particular, in
> citeproc-orgref I had to abuse the cite link descriptions to an even
> greater degree than they were by org-ref to accommodate the full CSL
> representation of citations (citations consist of cites and each cite
> can have a prefix, postfix and a locator). The resulting link syntax is
> rather cumbersome so I'd like to ask your opinion about introducing an
> alternative org-mode citation syntax that handles all of these elements.
> One option would be to use something very similar to pandoc's citation
> syntax (which I tried to follow as much as possible in the cite link
> descriptions of citeproc-orgref).
>
> A more general question I'd like to raise how (or whether) you see
> citeproc-el's (and CSL's) potential place in the org-mode ecosystem.
> There are a lot of directions which the further development could take
> (BibLaTeX support, citeproc-YAML bibliographies, CSL editing and CSL
> extensions etc.) and I'd be grateful to receive your input on which ones
> I should focus on.
>
> thanks in advance & best wishes,
>
> András Simonyi

[O] org-adapt-indentation 'content (was Re: [RFC] Moving "manual.org" into core)

[Christian Moe]

Nicolas Goaziou writes:

> Bastien Guerry  writes:
>
>> I've added (org-list-description-max-indent . 5)
>
> OK.
>
>> Me too, for the same argument.  But this points to a strong limitation
>> to `org-adapt-indentation' for which I'd like to propose this change.
>>
>>(setq org-adapt-indentation t) => current behavior
>>  (setq org-adapt-indentation nil) => current behavior
>> (setq org-adapt-indentation 'content) => only adapt content's
>>  indentation, not that of the property drawer.
>
> I proposed this very change some years ago, but it didn't get much
> traction and wasn't implemented in the end.

FWIW, I'd like this.

Yours,
Christian

Re: [O] [RFC] Moving "manual.org" into core

[Christian Moe]

Bastien Guerry writes:

> Hi Nicolas,
>
>> "manual.org" was updated a month ago, and, so far, nobody complained
>> about it. So, I think it's a good time to discuss about what could be
>> done next.
>
> Having the manual in .org is a great achievement, congrats to anyone
> who worked on this titanic task!

+1 !!

Yours,
Christian

Re: [O] Structured links to headings with endless depth

[Christian Moe]

ST writes:

> Adding an extra <> is not an option, as it will make the text
> less readable, and there is no need in this, as the headings tree
> structure is already there:

Adding targets, CUSTOM_IDs or IDs are all options. You may not like them.

> * 1
> ** 1
> ** 2
> *** 1
>
> Why should I turn it into the following
>
> * 1
> ** 1
> ** 2
> *** 1
> <<1>>

With a fixed structure, you wouldn't; you'd use e.g. <<1:2:1>>.

> and then link with [[file:1]]?!... This both:
> a) adds unnecessary information into the text making it less readable

Let's not exaggerate the readability cost. And it does add information.

> b) those who read the org file as simple text without the ability to
> click the link will not know where it goes... while the link
> [[file:1:2:1]] makes it quite clear even without clicking it.

But so does the link [[1:2:1]] to the target <<1:2:1>>.

also, c): Adding a target like <<1:2:1>> to a section preserves
information about the location of that section in the source document if
you later cut that part out and insert it somewhere else. This
information is not contained in your headlines.

> Example use case: scriptures with well known structure, e.g. the Bible.

Fair enough.

But typical Org use will quickly break links like that, since Org shines
as an organizer for drafting and easily restructuring text. I don't
think Org needs a link type that would encourage people to make easily
breakable links.

I acknowledge that a separate target or CUSTOM_ID for every verse in the
Bible seems a bit heavy; if that's what you need, it might be better
solved by a custom link type.

Yours,
Christian

>
> On Mon, 2018-03-12 at 10:29 +, Eric S Fraga wrote:
>> On Monday, 12 Mar 2018 at 12:09, ST wrote:
>> > Hi,
>> >
>> > after reading the manual I didn't find a way to construct structured
>> > links referring to headings with endless depth, like:
>>
>> I'm not entirely sure what your use case is but could you use a target,
>> i.e. something like <>, to indicate where you want to link to?
>> Cf. section 4.2 of org manual on internal links.
>>

Re: [O] Should wip-cite branch be merged to master?

[Christian Moe]

I have no opinion on whether it's time for a merge or not, but please
don't wait up for me.

Nicolas Goaziou writes:

> I also remember that Christian Moe suggested an alternate syntax for
> citations. He might want to point out what is missing from @cite syntax
> and if he still prefers his idea.

I did, but my suggestions did not get any traction back when a native
citation syntax was first being discussed on the list. Regrettably, I
have not managed to follow up my proposal properly, then or now -- not
even to the point of updating my own sample code after a Zotero
development broke it last year -- and I probably won't in the
foreseeable near future. So I wouldn't want to hold back a
community-developed solution on account that I had a different idea.

My proposal was for a different approach (parsing a "natural-looking"
citation syntax like (Smith 1990: p.3)), which I thought could be both
more user-friendly and more aesthetically pleasing in plain text.  It
was not for improvements to the @cite syntax, so I don't actually know
what is missing from the latter, if anything. I was very excited about
the citeproc contributon, but I have not found the time to test it out.

Re: [O] [patch] Problems producing TikZ PNGs from LaTeX src blocks (was: Problems producing TikZ PNGs from LaTeX src blocks)

[Christian Moe]

Benjamin Motz writes:

> It seems that the function `org-babel-execute:latex' ignores the
> property :headers under certain circumstances. Therefore the line
> "\usepackage{tikz}" will be missing in your resulting latex document.
>
> The property is not ignored if you also append the property
> ":imagemagick t" to the #+header line. So you can use the following
> header as a fix (for another fix, see below):
>
> #+header: :file "tikzpic.png" :fit yes :results raw file :exports results 
> :headers '("\\usepackage{tikz}") :imagemagick t

Thank you. When I try this workaround, I run into another issue, which
may be local to my setup. When I add the :imagemagick header, Org tries
to generate a PDF.  This gives me a message that the file wasn't
produced, but in fact a PDF with the correct image is produced --
however, it has a temporary file name, not the one I assigned to
it. (The same problem occurs if I try to create file output from this or
any other Babel latex block with a .pdf extension instead of .png.) It
looks like Org for some reason fails to take a last step in the
latex-to-PDF export -- changing the file name and cleaning up temporary
files. Probably as a result of this failure, no PNG is created.

I have also tried to apply your patch, without effect. Maybe I did it
wrong, but it increasingly looks like I have some weird problem with my
setup in addition to the issue you uncovered.

Yours,
Christian Moe

Re: [O] Problems producing TikZ PNGs from LaTeX src blocks

[Christian Moe]

Eric S Fraga writes:

> On Friday, 28 Sep 2018 at 16:37, Christian Moe wrote:
>> Hi, Eric
>>
>> Thanks for looking into this.
>>
>>> | executing Latex code block...
>>> | (Shell command succeeded with no output)
>>> | Code block evaluation complete.
>>
>> executing Latex code block...
>> Code block evaluation complete.
>>
>> Nothing obvious here that I can see.
>
> Well, for some reason my case outputs that extra line about shell command 
> succeeding...

Yes, that may be where the problem lies. I also have a problem
outputting PDFs instead of PNGs with the same setup (just changing .png
extension to .pdf). This gives me a message that the file wasn't
produced, but in fact a PDF with the correct image is produced --
however, it has a temporary file name, not the one I assigned to it.

> Have you tried with emacs -Q to make sure it's not a configuration error?

I should probably try this with a minimal init file (need one loading latex as a
babel language and probably a few other things). Didn't get around to that.

> I do have
>
>   (add-to-list 'org-latex-packages-alist '("" "tikz"))
>
> in my configuration so maybe that's the key even though you are specifying 
> that this package should be included in the babel header spec.

I have tried this without success. Also tried adding the LATEX_HEADERS
keyword to the document. Doesn't solve the problem, but changes the
output from an image of the code to an empty image.

Yours,
Christian

[O] Fwd: Re: Problems producing TikZ PNGs from LaTeX src blocks

[Christian Moe]

(Forgot to copy this to the list, sorry)

> Hi, Eric
>
> Thanks for looking into this.
>
>> This works for me, cutting and pasting exactly what you have posted into a 
>> small org file.
>>
>> Output from my *Messages* buffer:
>> ,
>> | Wrote /tmp/x.org
>> | org-babel-exp process latex at position 128...
>> | Evaluate this latex code block on your system? (y or n) y
>> | executing Latex code block...
>> | (Shell command succeeded with no output)
>> | Code block evaluation complete.
>> | Local Ispell dictionary set to british
>> | Saving file /tmp/x.tex...
>> `
>> when I export to LaTeX.  What does your message log say?
>
> org-babel-exp process latex at position 148...
> executing Latex code block...
> Code block evaluation complete.
> Saving file /home/cm/Pro/CiP/latex-babel-test.tex...
> Wrote /home/cm/Pro/CiP/latex-babel-test.tex
> Processing LaTeX file latex-babel-test.tex...
> PDF file produced.
> Running evince /home/cm/Pro/CiP/latex-babel-test.pdf...done
>
> Nothing obvious here that I can see.
>
>> Finally, what version of org are you using?  (maybe should have asked this 
>> first...)
>
> I'm on 9.1.14 (2018-09-24) via ELPA.
>
> Yours,
> Christian

Re: [O] letterhead and signature in odt export

[Christian Moe]

You should be able to make a letterhead template by placing the
letterhead in the header, saving it as an ODT styles file and
specifically referencing any images in a list in the ODT_STYLES_FILE
header. See the manual 12.12.5, "Applying custom styles".

When I try it, though, Org fails to parse the odt_styles_file list.

I attach my test files - I'd be obliged if someone else could take a
look, maybe it's just my setup.

Yours,
Christian

#+title: ODT styles test
#+ODT_STYLES_FILE: ("odt-test-styles.odt" ("styles.xml" "Pictures/120100A200B0A7D655E3F0A97ECF.png"))



Place this Org file in the same directory as the
accompanying file odt-test-styles.odt and export it to ODT.

Expected result: the exported document has a picture of the Org
unicorn in the header.

What I see:

  OpenDocument export failed: Invalid specification of styles.xml
  file: "(\"odt-test-styles.odt\" (\"styles.xml\"
  \"Pictures/120100A200B0A7D655E3F0A97ECF.png\"))"

  Use M-x make-directory RET RET to create the directory and its
  parents

The ODT_STYLES_FILE option is set correctly according to
[[info:org#Applying%20custom%20styles][info:org#Applying custom styles]] (info "org#Applying custom styles").
It references another ODT document providing the custom styles to
apply to this document, including an image to be used in the header.

However, it seems the value of ODT_STYLES_FILE is not being parsed
correctly as a list.



odt-test-styles.odt
Description: application/vnd.oasis.opendocument.text



Matt Price writes:

> in North America it's letter-of-reference season for professors, and I am
> writing a lot of them. These are some of the only documents I still compose
> in libreoffice, because I need to use a letterhead that contains both image
> and text, and I need to insert a .png of my signature near the bottom.  I
> would much prefer to compose these letter in org and them export. In order
> to so I would need to preserve the letterhead and the signature somehow.
> Both these sections in my current letters occur within the
> 
> 
>
> section which I guess is always replaced by org on export.  My immediate
> question: Is there a way to preserve some of these contents? More
> generally: do people have template files they are very satisfied with? I
> would be happy to go straight to pdf via latex, if it were easy to
> accomplish the same effect that way I don't use latex at all myself so it
> might not be so easy for me :-/.
>
> For completeness, here is the xml for my letterhead (sorry it's rather
> long):
>
> -
>  text:display-outline-level="2" text:separation-character="."
> text:name="Illustration"/> text:display-outline-level="2" text:separation-character="."
> text:name="Table"/> text:separation-character="." text:name="Text"/> text:display-outline-level="0" text:name="Drawing"/> text:display-outline-level="0" text:name="Figure"/> text:display-outline-level="2" text:separation-character="."
> text:name="Equation"/> text:separation-character="."
> text:name="Listing"/> text:outline-level="1"/> table:style-name="Table1"> table:style-name="Table1.A"/> table:style-name="Table1.B"/> table:style-name="Table1.1"> office:value-type="string"> draw:style-name="fr1" draw:name="Image1" text:anchor-type="as-char"
> svg:width="1.857cm" svg:height="3.025cm" draw:z-index="0"> xlink:href="Pictures/100041D61B2F2FDA8AF7D675B9CA7740.wmf"
> xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"
> loext:mime-type="image/x-wmf"/> xlink:href="Pictures/1201010701CF636AB597708AB63A.png"
> xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"
> loext:mime-type="image/png"/> table:style-name="Table1.A1" office:value-type="string"> text:style-name="P5">University of
> Toronto
>  text:style-name="P5">dept. of
> history
>  text:style-name="T5">Rm-2074 sidney smith, 100 st. george street, TORONTO,
> ONTARIO M5S 3G3 CANADA text:style-name="P4">Telephone 416-978-3363
> Fax 416-978-4810
>  text:style-name="P7" text:outline-level="1"> text:name="org54567cc"/>
> --
>
> and here is my signature:
>
> 
>  text:display-outline-level="2" text:separation-character="."
> text:name="Illustration"/> text:display-outline-level="2" text:separation-character="."
> text:name="Table"/> text:separation-character="." text:name="Text"/> text:display-outline-level="0" text:name="Drawing"/> text:display-outline-level="0" text:name="Figure"/> text:display-outline-level="2" text:separation-character="."
> text:name="Equation"/> text:separation-character="."
> text:name="Listing"/> text:outline-level="1"/> table:style-name="Table1"> table:style-name="Table1.A"/> table:style-name="Table1.B"/> table:style-name="Table1.1"> office:value-type="string"> draw:style-name="fr1" draw:name="Image1" text:anchor-type="as-char"
> svg:width="1.857cm" svg:height="3.025cm" draw:z-index="0"> xlink:href="Pictures/100041D61B2F2FDA8AF7D675B9CA7740.wmf"
> xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"

[O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

Hi,

It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
option as a list, as in this example from the manual
([[info:org#Applying custom styles]]):

  #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))

This is needed if you want a complex style with e.g. an image in the
header.

Exporting this causes an "Invalid specification of styles.xml file"
error on my recent ELPA version. The problem seems to be that the option
is treated as a string and never tested to see if it contains a list.

To reproduce the problem, place the attached documents
odt-styles-test.org and odt-test-styles.odt in the same directory, then
export odt-styles-test.org to ODT. The result should have a unicorn in
the letterhead.

The below quick-and-dirty patch seems to fix it, but I'm sure there's a
better approach.

*** /home/cm/.emacs.d/elpa/org-20180924/ox-odt.el   2018-09-27 
13:38:07.644922989 +0200
--- /home/cm/Downloads/ox-odt.el2018-10-30 21:18:44.827975243 +0100
***
*** 1360,1365 
--- 1360,1368 
(let* ((styles-file (plist-get info :odt-styles-file))
 (styles-file (and (org-string-nw-p styles-file)
   (org-trim styles-file)))
+;; Try reading it as a list
+(styles-expr (car (read-from-string styles-file)))
+(styles-file (if (listp styles-expr) styles-expr styles-file)
 ;; Non-availability of styles.xml is not a critical
 ;; error. For now, throw an error.
 (styles-file (or styles-file

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

Sorry, forgot to attach the test files.

#+title: ODT styles test
#+ODT_STYLES_FILE: ("odt-test-styles.odt" ("styles.xml" "Pictures/120100A200B0A7D655E3F0A97ECF.png"))



Place this Org file in the same directory as the
accompanying file odt-test-styles.odt and export it to ODT.

Expected result: the exported document has a picture of the Org
unicorn in the header.

The ODT_STYLES_FILE option is set correctly according to
[[info:org#Applying%20custom%20styles][info:org#Applying custom styles]]. It references another ODT document
providing the custom styles to apply to this document, including an
image to be used in the header.


odt-test-styles.odt
Description: application/vnd.oasis.opendocument.text

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

Thanks, Nicolas!

I'll test on my end when it shows up in ELPA.

Yours,
Christian

Nicolas Goaziou writes:

> Hello,
>
> Christian Moe  writes:
>
>> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
>> option as a list, as in this example from the manual
>> ([[info:org#Applying custom styles]]):
>>
>>   #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>>
>> This is needed if you want a complex style with e.g. an image in the
>> header.
>>
>> Exporting this causes an "Invalid specification of styles.xml file"
>> error on my recent ELPA version. The problem seems to be that the option
>> is treated as a string and never tested to see if it contains a list.
>>
>> To reproduce the problem, place the attached documents
>> odt-styles-test.org and odt-test-styles.odt in the same directory, then
>> export odt-styles-test.org to ODT. The result should have a unicorn in
>> the letterhead.
>>
>> The below quick-and-dirty patch seems to fix it, but I'm sure there's a
>> better approach.
>
> Thank you. I applied your patch with an additional check: the value should
> be enclosed within round brackets.
>
> Regards,

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

Nicolas, Lennart, cc: Charles Celerier,

Below, Lennart points out another issue with ODT_STYLES_FILE, a silent
change in syntax not reflected in the manual: quotation marks are no
longer needed around simple file paths.

I think this change was introduced by the below commit, which stopped
reading the string as a Lisp expression, and therefore at the same time
broke the option of providing a list for #+ODT_STYLES_FILE. My patch
last week fixed the list problem, but left the other change
intact. (Sorry for not doing the research.)

We could either update the manual and announce the syntax change, or
revert ox-odt-template to before the below patch to bring the code back
in conformity with the manual. I don't have a strong opinion one way or
the other. I like the change (never liked those quotation marks), but
it's backwards-incompatible, and the old code looks cleaner than my fix.

Yours,
Christian


commit 30498ef932bc35c26e3e58278f4987a67480b446
Author: Charles Celerier 
Date:   Sat Jul 28 17:09:16 2018 -0400

ox-odt: Fix `org-odt-template' styles file retrieval

* lisp/ox-odt.el (org-odt-template): Fix `org-odt-template' styles
  file retrieval.

TINYCHANGE

Signed-off-by: Charles Celerier 

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index a1145a9..74d811d 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -1359,11 +1359,10 @@ original parsed data.  INFO is a plist holding export 
options."
   ;; Write styles file.
   (let* ((styles-file (plist-get info :odt-styles-file))
 (styles-file (and (org-string-nw-p styles-file)
-  (read (org-trim styles-file
+  (org-trim styles-file)))
 ;; Non-availability of styles.xml is not a critical
 ;; error. For now, throw an error.
 (styles-file (or styles-file
- (plist-get info :odt-styles-file)
  (expand-file-name "OrgOdtStyles.xml"
org-odt-styles-dir)
  (error "org-odt: Missing styles file?"




L.C. Karssen writes:

> On 06-11-18 16:35, Christian Moe wrote:
>>
>> I believe the need to use quotation marks around the style file name was
>> removed at some point
>
> I didn't know that. I had a quick look at the changes to ox-odt.el for
> the last few months, but it doesn't seem to be mentioned in any of the
> commit messages. Or was this a more global change?
>
> Does this also count for the regular #+INCLUDE: statement? I just tested
> it and for #+INCLUDE: it seems to work both with and without quotes
> (although the manual uses quotes).
>
>
> Best,
>
> Lennart.
>
>> , and the manual is out of date. Instead of
>>
>>  #+ODT_STYLES_FILE: "template.ott"
>>
>> the manual ought now to read:
>>
>>  #+ODT_STYLES_FILE: template.ott
>>
>> Yours,
>> Christian
>>
>> L.C. Karssen writes:
>>
>>> Hi list,
>>>
>>> Not sure if this is related (or fixed with the aforementioned patch)
>>> because I'm not using a list for the ODT style file.
>>>
>>> Today, after upgrading from Org 9.1.13 (actually installed from melpa on
>>> 20180625) to melpa version 20181105 exporting to ODT stopped working. In
>>> my org file the style file name was enclosed in double quotes (as
>>> specified in the manual [1]):
>>>
>>> #+ODT_STYLES_FILE: "template.ott"
>>>
>>> The error message is:
>>>
>>> OpenDocument export failed: Invalid specification of styles.xml file:
>>> "\"template.ott\""
>>>
>>> Removing the quotes fixes the export to ODT.
>>>
>>>
>>> Best regards,
>>>
>>> Lennart.
>>>
>>> [1] https://orgmode.org/org.html#Applying-custom-styles
>>>
>>>
>>> On 05-11-18 09:49, Christian Moe wrote:
>>>>
>>>> Thanks, Nicolas!
>>>>
>>>> I'll test on my end when it shows up in ELPA.
>>>>
>>>> Yours,
>>>> Christian
>>>>
>>>> Nicolas Goaziou writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> Christian Moe  writes:
>>>>>
>>>>>> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
>>>>>> option as a list, as in this example from the manual
>>>>>> ([[info:org#Applying custom styles]]):
>>>>>>
>>>>>>   #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>>>>>>
>>>>>> This is needed

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

I believe the need to use quotation marks around the style file name was
removed at some point, and the manual is out of date. Instead of

 #+ODT_STYLES_FILE: "template.ott"

the manual ought now to read:

 #+ODT_STYLES_FILE: template.ott

Yours,
Christian

L.C. Karssen writes:

> Hi list,
>
> Not sure if this is related (or fixed with the aforementioned patch)
> because I'm not using a list for the ODT style file.
>
> Today, after upgrading from Org 9.1.13 (actually installed from melpa on
> 20180625) to melpa version 20181105 exporting to ODT stopped working. In
> my org file the style file name was enclosed in double quotes (as
> specified in the manual [1]):
>
> #+ODT_STYLES_FILE: "template.ott"
>
> The error message is:
>
> OpenDocument export failed: Invalid specification of styles.xml file:
> "\"template.ott\""
>
> Removing the quotes fixes the export to ODT.
>
>
> Best regards,
>
> Lennart.
>
> [1] https://orgmode.org/org.html#Applying-custom-styles
>
>
> On 05-11-18 09:49, Christian Moe wrote:
>>
>> Thanks, Nicolas!
>>
>> I'll test on my end when it shows up in ELPA.
>>
>> Yours,
>> Christian
>>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>> Christian Moe  writes:
>>>
>>>> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
>>>> option as a list, as in this example from the manual
>>>> ([[info:org#Applying custom styles]]):
>>>>
>>>>   #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>>>>
>>>> This is needed if you want a complex style with e.g. an image in the
>>>> header.
>>>>
>>>> Exporting this causes an "Invalid specification of styles.xml file"
>>>> error on my recent ELPA version. The problem seems to be that the option
>>>> is treated as a string and never tested to see if it contains a list.
>>>>
>>>> To reproduce the problem, place the attached documents
>>>> odt-styles-test.org and odt-test-styles.odt in the same directory, then
>>>> export odt-styles-test.org to ODT. The result should have a unicorn in
>>>> the letterhead.
>>>>
>>>> The below quick-and-dirty patch seems to fix it, but I'm sure there's a
>>>> better approach.
>>>
>>> Thank you. I applied your patch with an additional check: the value should
>>> be enclosed within round brackets.
>>>
>>> Regards,
>>
>>

[O] Problems producing TikZ PNGs from LaTeX src blocks

[Christian Moe]

Hi,

I am trying to generate a PNG file with a TikZ picture from a LaTeX src
block, looking at instructions here:
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html

I try this:

#+header: :file "tikzpic.png" :fit yes :results raw file :exports results 
:headers '("\\usepackage{tikz}")
#+begin_src latex
  \begin{tikzpicture}
   \draw [fill=green] (0,4) -- (3,0) -- (-3,0) -- cycle;
  \end{tikzpicture}
#+end_src

Expected result: A tikzpic.png image of a green triangle.

Actual result: A tikzpic.png image (attached) that only shows the line
of TikZ code. It seems that the :headers argument isn't working.

If I add a #+LATEX_HEADER: \usepackage{tikz} line to my document, I can
export latex blocks as well as latex src blocks as drawings within an
exported PDF. But exporting the image as a PNG file continues to fail
(in this case, for some reason, the above src block results in an empty
image, no longer showing either the code or the intended picture).

What might I be missing?

Yours,
Christian

Re: [Idea] Org Collections

[Christian Moe]

+1, that is: This is an interesting idea, there have been times when I
might have found something like this handy, and I might well use if it's
developed, though I'm not sure if it will ease my cognitive load or add
to it. :-) 

Yours,
Christian Moe

Gustav Wikström writes:

[...]
 
>
>  ORG MODE: COLLECTIONS/PROJECTS
>
> Gustav Wikström
> 
>
[...]

Re: Need Guidance in developing and generating code using org-mode

[Christian Moe]

Hi, Kokou,

Adding to what Leslie Watter writes:

>>- Under Register, and Login heading, How do i generate html forms
>>which will post entries to specific destinations? and also generate code
>>for capturing the data?
>>
>> To use forms, you'll probably will use raw HTML:
>
> https://orgmode.org/manual/Quoting-HTML-tags.html#Quoting-HTML-tags
>

And for capturing the data, you will of course need to provide scripts
on a server as targets for the html forms.

Org is great for quick writing and exporting to HTML. It can also be
used to publish whole static websites and blogs. Some people use a
combination of Org and other static blogging tools, like Jekyll, which
adds some helpful functionality.

However, if you want to dynamically serve pages only to logged-in users,
Org-mode may not be the tool you are looking for. You may want to look
at blogging platforms or content management systems. (If you like
writing in Org, you can still use it for drafting.)

Yours,
Christian

Re: Exporting comments to comments?

[Christian Moe]

I use a rather complex comment macro to make ODT annotations without
introducing unwanted paragraph breaks.

I'm not sure what the Markdown comment syntax is. But e.g. for HTML, the
macro could be defined as simply as:

#+MACRO: comment @@html:@@

Then you can write things like

  This is a sentence with a comment.{{{comment(This is the comment.)}}}
  This is another sentence.

and get comments in the exported HTML. It's ugly, and any commas within
the comment text must be backslash-escaped, but it works, and could be
adapted for Markdown.

HTH,
Christian

Allen S. Rout writes:

> I'd like to write an org-mode document, export it to markdown, and have
> comments exist in the markdown.
>
>
> I feel like I'm thinking about the process incorrectly, and it's hard to
> search around because the discussions around 'org-mode comments' focus
> on org data for which authors would like to _prevent_ export.
>
> I saw some old conversations about making links to the hacked-in
> comment: URI scheme, but that seemed quite hackish indeed.
>
> I thought about making a block of a 'comment' type, but of course all
> the workflow for that is, again, focused on either preventing its export
> in the first place, or making sure that it's exported in a visible
> manner in the output.  ("I want to print the comments in my LaTeX..").
>
>
> So... am I missing something obvious?  Anyone else trying something similar?
>
>
> - Allen S. Rout

Re: I'm slowly coming back

[Christian Moe]

Important work! Stay safe.

Christian

Bastien writes:

> Dear all,
>
> my day job is to work for the open data public agency in France.
>
> I have been drown under a massive workload in the last four weeks,
> due to the COVID-19 crisis.
>
> I am slowly freeing more time and I'll be back at reading the list
> on a regular basis at the end of week 16.
>
> Thanks,

Re: org2blog: get horizontal scrollbar on code examples?

[Christian Moe]

Try adding

 .org-src-container .src { overflow: auto; white-space: nowrap }

to the CSS, e.g.:

  #+html_head_extra: .org-src-container .src { overflow: auto; 
white-space: nowrap }

Cheers,
Christian

Steinar Bang writes:

> Does anyone know of a way to get horizontal scrollbars on code examples,
> instead of line breaks?
>
> I try to make code examples as horizontally compact, but sometimes
> that's not enough, see e.g. some maven  elements here, and
> the maven command line examples:
>  
> https://steinar.bang.priv.no/2020/03/30/how-to-get-test-coverage-back-in-sonarcloud-maven-builds/

Re: org-tables with monetary amounts

[Christian Moe]

Hi, Derek,

Very useful, thanks!

Yours,
Christian

Derek Feichtinger writes:

> Hi,
>
> On Mon, Oct 12 2020, Eric S Fraga  wrote:
>
>> On Monday, 12 Oct 2020 at 10:22, Christian Moe wrote:
>>> I think I was thinking about adding mode flags for unit computations,
>>> like in the imagined example above (`$3=$2+$1;u'), similar to what has
>>> been done for duration computations.
>>
>> This would be very useful, actually.  I use embedded calc all the time
>> with units; being able to use some of the same expressions in a table
>> would be highly welcome.
>
> The functions that one can use in calc formulas can be extended using
> the 'defmath' lisp command. I paste here from my notes (not about
> monetary units, but easily adapted):
>
> +++
> Defining a new calc function for unit conversion with defmath
> #+BEGIN_SRC emacs-lisp
> (defmath uconv (expr target-units  pure)
>   (math-convert-units expr target-units pure))
> #+END_SRC
>
> #+RESULTS:
> : calcFunc-uconv
>
> | km | ft   |
> |+--|
> | 2.5 km | 8202.0997 ft |
> #+TBLFM: $2=uconv($1, ft)
>
> Using the units from the table header (if the 3rd arg is given to
> uconv, the output is stripped of the unit):
>
> |  km |ft |
> |-+---|
> | 2.5 | 8202.0997 |
> #+TBLFM: $2 = uconv($1 * @<$1, @<$2, t)
>
> The standard calc function usimplify also works for this use
> case:
>
> |  km |ft |
> |-+---|
> | 2.5 | 8202.0997 |
> #+TBLFM: $2 = usimplify($1 * @<$1 / @<$2)
>
> A lisp equivalent of the above
> #+begin_src elisp
> (calc-eval "usimplify(2.5 km / ft)")
> #+end_src
>
> #+RESULTS:
> : 8202.09973753
>
> Let's define a function that converts to base units
> #+begin_src elisp
>   (defmath ustd (expr) (math-simplify-units (math-to-standard-units expr 
> nil)))
> #+end_src
>
> #+RESULTS:
> : calcFunc-ustd
>
> | distance | time   | speed   | std unit speed   | speed in ft/s|
> |--++-+--+--|
> | 3 km | 2.5 hr | 1.2 km / hr | 0. m / s | 1.0936133 ft / s |
> #+TBLFM: @2$3=$1/$2::@2$4=ustd($3)::@2$5=uconv($-1, ft/s)
> 

Re: org-tables with monetary amounts

[Christian Moe]

Hi, Daniele,

Good that it's working for you. I'll try to explain the unclear parts.

Daniele Nicolodi writes:

> On 24/09/2020 11:17, Christian Moe wrote:
>
>> Now, with the Calc command to simplify units, you can add dollars to
>> euros and get the result in whichever currency comes first in the
>> algebraic expression
>>
>>   | 3 USD | 4 EUR | 6.58 EUR |
>>   #+tblfm: $3=usimplify($2+$1)
>>
>>   | 3 USD | 4 EUR | 7.6511628 USD |
>>   #+tblfm: $3=usimplify($1+$2)
>
> Having to explicitly use usimplify() is a bit too verbose. It would be
> ideal if this could be somehow be implicit.

Yes, or at least with a less obtrusive syntax, like a mode flag,
something like

  $3=$2+$1;u

(here using "u" for "units" -- unfortunately, capital "U" is already
taken)

>> I don't use this functionality, so I don't have answers to all the
>> questions you'll now have -- including how to get the desired precision
>> without lopping off the currency unit in the last example!
>
> Having the desired fixed precision is quite important for this to be
> useful. In y recent tests I had to drop the units (currencies) to
> achieve this. It would be nice to find a way to avoid it.

[...]

>> Apart from `usimplify', most Calc functions on units appear (?) to be
>> missing corresponding algebraic versions that you can use in Calc
>> expressions in Org tables, which limits the usefulness.

I may be missing something, but it looks like handy Calc commands like
simple unit conversion currently can't be used in an Org spreadsheet,
making Calc units less useful in the spreadsheet. And that this is due
to a lacuna in Calc, not in Org.

When using Calc directly, there are two ways to enter calculations. The
default is reverse Polish notation on the stack (like an old HP
calculator), with various keys bound to all the available commands. The
alternative is algebraic notation.

For example, the command for square root is `calc-sqrt', entered with
the `Q' key. To get the square root of two, you would enter `2 Q' or `2
RET Q'. The corresponding function to use in algebraic notation is
`sqrt'. To use it, you would press apostrophe for algebraic notation,
and enter `sqrt(2) RET'.

But while all Calc commands have keys assigned, it seems not all have
corresponding algebraic notation (?). The Calc manual says that the
command `u s' (`calc-simplify-units') has the algebraic expression
`usimplify'. But it does not list such expressions for other handy Calc
commands, like the `u c' (`calc-convert-units') command, the `u r'
(`calc-remove-units') command or the `u x' (`calc-extract-units')
command.

The Org spreadsheet can also use Lisp formulas, so I've tried to use
calc-simplify-units directly, but this leads to #ERROR.


>> Org tables don't seem to have any specific formula syntax for leveraging
>> Calc unit operations apart from what happens to work out of the
>> box. This might be an area for improvement, though I'm not sure what to
>> ask for.

I think I was thinking about adding mode flags for unit computations,
like in the imagined example above (`$3=$2+$1;u'), similar to what has
been done for duration computations. See the manual, 3.5.2 Formula
syntax for Calc. Might be useful, but I'm not sure how to specify a
request.

> I don't understand what you mean in the two paragraphs above. Can you
> please clarify, maybe with examples?

Hope this helps.

Yours,
Christian

Re: org-tables with monetary amounts

[Christian Moe]

Hi,

Parsing numbers followed by currencies is sort of supported already
through Calc's operations on units. (Calc is the built-in emacs
calculator that powers the spreadsheet function of Org tables). I
haven't used this or explored it much, but my impression is that it
could be made more useful than it currently is. Here are a couple of
things you can do fairly easily.

If you're only working with one currency and just want it to show up
automatically, the following calculation will give you 59.97 USD in the
third column right out of the box, without even requiring you to define
it as a unit first.

  | 50 USD | 8.97 USD | 59.97 USD   |
  #+TBLFM: $3=$1+$2

Adding undefined currencies together will result in an expression like
"3 USD + 4 EUR". However, if you define the currencies as units based on
exchange rates, you can get conversion as part of arithmetic operations.

E.g. in Calc,
- put `1' on top of the stack
- then do `u d EUR' to define the euro as your unit currency (for
example)
- then define e.g. US dollars: Today's rate is 1 USD = 0.86 EUR.
- hit apostrophe to enter algebraic mode and enter `0.86 EUR'
  (today's rate: 1 USD = 0.86 EUR)
- now do `u d USD' to define the rate

Now, with the Calc command to simplify units, you can add dollars to
euros and get the result in whichever currency comes first in the
algebraic expression

  | 3 USD | 4 EUR | 6.58 EUR |
  #+tblfm: $3=usimplify($2+$1)

  | 3 USD | 4 EUR | 7.6511628 USD |
  #+tblfm: $3=usimplify($1+$2)

I don't use this functionality, so I don't have answers to all the
questions you'll now have -- including how to get the desired precision
without lopping off the currency unit in the last example!

There are ways to enter user-defined units permanently. But exchange
rates change, so to use this functionality on a daily basis, you'll want
to have some kind of function to pull exchange rates and update the
currency unit definitions in the Calc init file.

Apart from `usimplify', most Calc functions on units appear (?) to be
missing corresponding algebraic versions that you can use in Calc
expressions in Org tables, which limits the usefulness.

Org tables don't seem to have any specific formula syntax for leveraging
Calc unit operations apart from what happens to work out of the
box. This might be an area for improvement, though I'm not sure what to
ask for.

Yours,
Christian

Daniele Nicolodi writes:

> Hello,
>
> I often use org-tables to work with monetary amounts. It would be very
> nice to have a couple of functionalities common in this domain:
>
> - fixed precision arithmetic, namely derive the precision of the results
> from the precision of the arguments (I think that calc can do this),
>
> - support for parsing numbers followed by currencies,
>
> - correct alignment for monetary values.
>
> I had a quick look around, but I haven't found anything that implements
> those things. Has anyone some secret code that they would like to share?
>
> Thank you!
>
> Cheers,
> Dan

Re: Help: how to extend org-mode markup?

[Christian Moe]

Hello,

In your example, `:next:' is a tag. Tags and keywords are different
entities.
https://orgmode.org/worg/dev/org-syntax.html

You should be able to do what you want by customizing `org-tag-faces'.

Yours,
Christian 

Pierre-Henry F. writes:

> Hello,
>
> I would like to extend the org-mode markup.
>
> For example, I would like to change the face of a keyword, say: :next: .
>
> Whenever :next: is displayed from an org-mode buffer, it should show up in 
> using an arbitrary face.
>
> I tried this:
>
> (defun org-add-my-extra-markup ()
> (add-to-list 'org-font-lock-extra-keywords
> '("[^\\w]\\(:next:\\)[^\\w]"
> (1 font-lock-warning-face t
>
> (add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-markup)
>
> But it does not work.
>
> So: how to extend org-mode markup?
>
> Many thanks,
> PHF

Re: Help: how to extend org-mode markup?

[Christian Moe]

Please disregard my response. I misunderstood both your intention and
the use of font-lock keywords. Sorry for the noise. :-(

Yours,
Christian

Pierre-Henry F. writes:

> Thank you very much for your replies.
>
> Here is the use case:
>
> |---+|
> | something | :next: |
> |---+|
>
> I would like :next: to show up using an arbitrary face.
>
>
> As suggested by Ihor, I tried:
>
> (font-lock-add-keywords 'org-mode
>   '(("\\W\\(:next:\\)\\W" 1 font-lock-warning-face prepend)))
>
> in my init.el
>
> It does not work either.
>
>
> @Christian yes, it's the same syntax as tags, I would like to extend it 
> eventually.
>
>
> Thanks,
> PHF
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, September 25, 2020 9:26 AM, Ihor Radchenko  
> wrote:
>
>> > (add-to-list 'org-font-lock-extra-keywords
>>
>> It is internal variable. You should not use it.
>>
>> Simply use font-lock-add-keywords instead.
>>
>> Best,
>> Ihor
>>
>> "Pierre-Henry F." cont...@phfrohring.com writes:
>>
>> > Hello,
>> > I would like to extend the org-mode markup.
>> > For example, I would like to change the face of a keyword, say: :next: .
>> > Whenever :next: is displayed from an org-mode buffer, it should show up in 
>> > using an arbitrary face.
>> > I tried this:
>> > (defun org-add-my-extra-markup ()
>> > (add-to-list 'org-font-lock-extra-keywords
>> > '("[^\\w]\\(:next:\\)[^\\w]"
>> > (1 font-lock-warning-face t
>> > (add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-markup)
>> > But it does not work.
>> > So: how to extend org-mode markup?
>> > Many thanks,
>> > PHF

Re: Local variables insecurities - Re: One vs many directories

[Christian Moe]

Located Eric's message and can confirm the same for mu4e (no query about
setting/evaluating anything upon opening the message).

cm

Eric S Fraga writes:

> On Wednesday, 25 Nov 2020 at 15:38, Jean Louis wrote:
>> I have not configured anything. In fact I have opened the email and I
>> was surprised that I am getting those dialogues to execute local
>> variables.
>
> Very strange.  It was my email that instigated this part of the
> thread.  I can view my email and I do not get asked to set any locate
> variables or, in this case, evaluate the elisp expression.  Out of
> curiosity, what mail reader did you use that actually interprets file
> local variables?  Gnus article view does not.

Re: [PATCH] org-table: Add mode flag to enable Calc units simplification mode

[Christian Moe]

Great! Thanks for following through on this, Dan!

Yours,
Christian

Kyle Meyer writes:

> Daniele Nicolodi writes:
>
>> Thank you for the review, Kyle.
>>
>> Another updated patch set is attached.
>
> Thank you for the update.
>
> Applied, tweaking the manual entry to use "a unit" rather than "an
> unit".
>
> 1:  bd7e16ca2 = 1:  bd7e16ca2 org-table: Remove unused org-tbl-calc-modes 
> variable declaration
> 2:  abd994943 = 2:  abd994943 org-table: Simplify mode string parsing
> 3:  cb77e7a46 ! 3:  15469774d org-table: Add mode flag to enable Calc units 
> simplification mode
> @@ doc/org-manual.org: *** Formula syntax for Calc
>  +- =u= ::
>  +
>  +  Units simplification mode of Calc.  Calc is also a symbolic
> -+  calculator and is capable of working with values having an unit,
> -+  represented with numerals followed by an unit string in Org table
> ++  calculator and is capable of working with values having a unit,
> ++  represented with numerals followed by a unit string in Org table
>  +  cells.  This mode instructs Calc to simplify the units in the
>  +  computed expression before returning the result.
>  +

Re: Tables: missing multi-col/row syntax

[Christian Moe]

+1 for enabling table-cell merges in export. I imagine this would be a
tricky job for developers, but it would relieve me as a user of much
repeated fiddling with exported drafts.

+1 for doing it without adding clutter to the table syntax, but
specifying merges on a separate line like formulas, like Tom's

  #+TBLCELLMERGE: @2..3$1

(amended here to use the established '..' rather than hyphen for range)

Though if we do add such a line, we might also think of a more general
solution that could over time be extended with additional formatting
options, e.g. something like

  #+TBLSTYLE: @2..3$1='(:merge t)::@4$1='(:bgcolor yellow :color red)

But obviously that could open a can of worms, aka potentially endless
feature requests requiring different implementations for each backend.

Yours,
Christian



Tom Gillespie writes:

> Any support for something like this would need to retain backward
> compatibility as well to avoid older versions reformatting the tables
> due to e.g. the presence of a double pipe. I also think that extending
> the table syntax in ways that makes it more complex than it already
> is, will be a non-starter. Thus, an alternate but more likely approach
> would be to allow specification of what cells to merge outside the
> table as is done for formulas. It is not elegant, but it would be a
> layer on top of existing syntax, and it would allow the fundamental
> structure of the table to remain the same -- rows of cells. For
> example #+TBLCELLMERGE: @2-3$1 or something like that. Thoughts?
> Tom
>
> On Mon, Nov 2, 2020 at 1:37 PM TEC  wrote:
>>
>> Hi all,
>>
>> This is a pretty major 'feature request', but I think also an
>> important
>> one.
>>
>> When developing large tables, it can often be /necessary/ to start
>> using
>> multi-column/row cells for clarity, and sensible exporting
>> results.
>>
>> As far as I am aware, in Org does not currently have any
>> multi-col/row
>> syntax. The only viable method seems to be re-implementing the
>> table
>> using export blocks in every backend you may want to export to (in
>> my
>> case, usually TeX + HTML). This is clumsy, difficult to work with,
>> and
>> could be avoided should org gain support for multi-col/row syntax.
>>
>> I appreciate that this would constitute a major change both the
>> Org's
>> syntax and the codebase, but I believe such a change is warranted
>> by the
>> advantages it would provide.
>>
>> Both how this can be implemented while minimising/eliminating the
>> chance
>> of breaking well-formed current table elements, and what syntax
>> may be
>> both acceptable and seem sensible to use.
>>
>> I would anticipate such a feature working by designating two
>> characters
>> to indicate "add row" and "add column". For example "|" and "-".
>> These
>> characters would take affect when /immediately following/ (no
>> space) a
>> cell separator ("|"), and designate the dimensions of the top
>> right cell.
>>
>> Example:
>> | a | b | c |
>> |---+---+---|
>> | a | - | | |
>> | - | b | . |
>> | . | | | c |
>>
>> Would be interpreted just as any current table is.
>>
>> However,
>>
>> | hello | there | you  |
>> |---+---+--|
>> || two column   | cell |
>>
>> Contains a 2x1 cell.
>>
>> | a little | test |
>> |--+--|
>> |- hello   | hi   |
>> | two row  | you  |
>>
>> Contains a 1x2 cell. In a more complex example:
>>
>> | a | b | c |
>> |---+---+---|
>> ||-- hi | a |
>> | two x | . |
>> | three | b |
>> | c | - | . |
>>
>> Contains a 2x3 cell.
>>
>> This is just the first syntax that comes to mind, but hopefully
>> the
>> general form of this idea seems viable.
>>
>> All the best,
>>
>> Timothy.
>>

Re: org-critical-edition (a package for philologists and classicists)

[Christian Moe]

Very neat!

Curious about a design choice: If I understand correctly,
org-critical-edition puts the hidden notes in the description and the
visible annotated text in the target of an org link. This is the reverse
of the out-of-the-box link appearance (description visible, target
hidden if description present). Why take the extra trouble to do it this
way?

Yours,
Christian

Juan Manuel Macías writes:

> Hi all,
>
> I have uploaded the (very) initial version of my package
> org-critical-edition:
>
> https://gitlab.com/maciaschain/org-critical-edition
>
> This package lets you prepare a philological critical edition in Org
> Mode. The natural output is LaTeX with the reledmac package
> (https://www.ctan.org/pkg/reledmac).
>
> (For those who are not philologists, this is an example of critical
> edition that I typesetted recently: https://imgur.com/a/drqCib5)
>
> Feedback welcome!
>
> Best regards,
>
> Juan Manuel

Re: publishing: no default publishing function, or symbol is not defined

[Christian Moe]

Hi, Chris,

"Symbol's function definition is void" means there is no such function
defined.

Try org-html-publish-to-html instead.

Yours,
Christian

Christopher W. Ryan via General discussions about Org-mode. writes:

> I'm making my first foray into publishing a project. I'm running GNU
> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>
> I've defined a single project, just to try it out and learn.  Here is
> the relevant portion of my .emacs file
>
>
> ;; Projects and publishing
> ;;
> (setq org-publish-project-alist
>   '(("CaseInvestigationTrainingAndReferenceManual"
>  :base-directory
> "E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/"
>  :publishing-directory
> "E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/StagingArea")))
>
>
> There is one org file in /Sandbox,  called
> WorkAreaForIndexingTrainingAndReferenceManual-7-June.org
>
> (as the filename suggests, I'm mostly interested in learning how to make
> an index).
>
> If I execute C-c C-e P a  whilie in the org file I am trying to publish,
> I get an error message that there is "No publishing function chosen".  I
> thought org-publish-org-to-html was the default, as described here:
>
> https://www.gnu.org/software/emacs/manual/html_node/org/Publishing-action.html
>
> But if I modify the relevant section of my .emacs file like this,
> specifying a publishing action:
>
> ;; Projects and publishing
> ;;
> (setq org-publish-project-alist
>   '(("CaseInvestigationTrainingAndReferenceManual"
>  :base-directory
> "E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/"
>  :publishing-directory
> "E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/StagingArea"
>  :publishing-function org-publish-org-to-html)))
>
> and try again, I get an error message that I can't figure out: "Symbol’s
> function definition is void: org-publish-org-to-html"
>
> Grateful for any guidance.
>
> Thanks.
>
> --Chris Ryan

Re: Cross referencing in Emacs Org mode

[Christian Moe]

Hi,

The question, then, is not if you can have cross-references (as you say,
they work fine), but if they will work with subtree export.

I believe not (but others may have to correct me). Links/refs to parts
of the document outside the exported subtree *will* be broken. The
exporter does not consider other sections of the document and will not
try to resolve how the refs *should* have looked.

If you use custom IDs or dedicated Org targets like <> for the
label and links like [[label1]] for the refs, you *can* manage how
broken links should be handled. `C-h v org-export-with-broken-links' for
details.

Yours,
Christian

Partha Pratim Ghosh writes:

> Dear All,
>
> Is it possible to have cross reference in LaTeX export for Org
> mode. To be specific: I have a org file segmented into sections, say as
> follows:
>
> *** example of Org file, excluding the headers**
>
> * Section 1
>   contains some text, a label [label:label1] and some citation 
> [cite:cite1]
>
> * Section 2
>   contains some text, a label [label:label2] and a reference to label1
>   as [ref:label1], and a reference to a label in Section 3, [ref:label3]
>
> * Section 3
>   contains some text, and label [label:label3]
>
> \printbibliography
>
> 
>
> I did not include the headers where the bibliography files are properly
> added. When I export the full buffer with C-c C-e l o everything runs
> fine. However, whenever I go to Section 2, say and try to export using
> C-c C-e C-s l o (for subtree export only), the bibliography does not
> appear, and the reference to label1 or label3 does not appear.
>
> Is it possible to have the labels properly referenced as well as the
> bibliography printed when subtrees are only exported to pdf?
>
> With my regards and all the very best wishes,
>
> partha

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

Maxim Nikulin writes:

> On 17/05/2021 02:21, Christian Moe wrote:
>> Maxim Nikulin writes:
>>> On 03/05/2021 04:08, Christian Moe wrote:
>> [snip]
>>> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
>>> #'identity _ ",")))
>>>
>>> {{{allargshack(one, two, three)}}}
>>>
>>> I do not know if Eric can swap order of arguments of his credits
>>> macro. Extracting namely last argument requires a bit more lisp code.
>>
>> Yes, I didn't think that far. This would provide a comprehensive
>> backwards-compatible solution to the comma-escaping problem, though
>> perhaps not the most newbie-friendly one. It would also make macros more
>> flexible and powerful in the bargain (I'm sure people will think of
>> other uses for this than commas).
>
> I agree that it would abuse arguments syntax, but I expect that namely
> newbies would not bother since it would "just work":
>
> #+MACRO definition  - $1 ::$_
>
> {{{definition(one, two, three}}}
>
> It is more experienced users who may be confused why it works.


That's not what I was trying to say. I don't think your suggestion
abuses the argument syntax - it would extend it, in a way that is likely
to prove helpful for multiple purposes.

When I said it was probably not the most newbie-friendly solution for
the comma-escaping problem, I thought that it required including a bit
of lisp in their macros to add the commas back in (the mapconcat
expression in your "allargshack" example above).

But if the "definition" macro above "just works", I suppose that in your
solution, the list of arguments $_ would by default expand to the same
string as the mapconcat expression would, i.e. the commas would be added
back in. That makes sense. The mapconcat expression would not even be
needed, then, unless one wants the macro to do anything else than
preserve commas. Or am I misunderstanding something?

Yours,
Christian

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

Maxim Nikulin writes:

> On 03/05/2021 04:08, Christian Moe wrote:
[snip]
>> Something that would help, without adding new syntax, is
>> making macro expansion smart enough to *ignore* separators when the
>> macro definition contains only *one* argument anyway, as in the cases
>> above.
>
> I think, this is an idea of the best approach. Unsure concerning
> precise form. Maybe e.g. "$_" could expand into all arguments greater
> than maximum referenced number. No promise of forward compatibility of
> the following hack since it relies on undocumented implementation
> details.
>
> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
> #'identity _ ",")))
>
> {{{allargshack(one, two, three)}}}
>
> I do not know if Eric can swap order of arguments of his credits
> macro. Extracting namely last argument requires a bit more lisp code.


Yes, I didn't think that far. This would provide a comprehensive
backwards-compatible solution to the comma-escaping problem, though
perhaps not the most newbie-friendly one. It would also make macros more
flexible and powerful in the bargain (I'm sure people will think of
other uses for this than commas).

Yours,
Christian

Re: convert subtree or nested list to table

[Christian Moe]

Hi, Matt,

Here's a version of this with a bit more processing.

Define this somewhere in your document

#+NAME: list2table
#+BEGIN_SRC elisp :var order="columns"
  (let (longest)
(setq data (map 'list 'flatten data))
(setq data (map 'list (lambda (x) (seq-difference x '(unordered ordered))) 
data))
;; Pad out lists to equal length
(setq longest (seq-max (map 'list 'length data)))
(setq data
  (map 'list
   (lambda (l)
 (append l (make-list (- longest (length l)) "")))
 data))
;; Order by columns or rows
(if (string= order "columns")
(apply #'mapcar* #'list data) ; transpose
  data))
#+END_SRC

Here is an example list to try it out with:

#+NAME: testlist
- Letters
  1. a
  2. b
  3. c
- Roman numerals
  1. i
  2. ii
  3. iii
- Greek letters
  1. alpha
  2. beta
  3. gamma

Now you can call the src block, passing the name of the list to the
"data" variable.

#+CALL: list2table(data=testlist)

#+RESULTS:
| Letters | Roman numerals | Greek letters |
| a   | i  | alpha |
| b   | ii | beta  |
| c   | iii| gamma |

The default here is that each top item and its sublist forms a column.

To get rows instead, pass order="rows" (or anything other than
order="columns" really):

#+CALL: list2table(data=testlist, order="rows")

#+RESULTS:
| Letters| a | b| c |
| Roman numerals | i | ii   | iii   |
| Greek letters  | alpha | beta | gamma |

You can use numbered or unnumbered lists. Sublists don't strictly have
to be the same length - the code pads them out to equal length with the
empty string before transposing. However, I would strongly recommend
using numbered sublists of the same length (with blank items as needed),
so you can make sure that items line up correctly.

If you want column headers or rownames, you will need to take care of
that manually before exporting. Using ":colnames yes" will lead to
errors when the source is a list. Might be away to hack org-babel to get
around this but I don't know how. (The only automatic solution I can
think of would be by naming the calls in an unexported section and
referencing them with another layer of calls in the exported section,
using a src block that only passes the data on with :colnames yes. But
that's fiddly.)

Will this work for you?

Yours,
Christian


Matt Price writes:

> I think this is exactly what I want (with just a little moreprocessing).
> Thank you so much for the idea!
>
> I'm having a little bit of trouble getting the same output as you though,
> and I'm wondering if there might be a setting that I need to change.
>
> Here is what I tried, and the result. Do you have an idea of what is going
> wrong here?
>
> Thank you!
>
>
> 
> #+NAME:essay-rubric
> - Category
>   - A
>   - B
>   - C
>   - D
>   - F
> - Writing
>   - great
>   - good
>   - ok
>   - lousy
>   - awful
>
> #+begin_src emacs-lisp :var contents=essay-rubric :results table
> contents
> #+end_src
>
> #+RESULTS:
> #+begin_src emacs-lisp
> | (("Category" |
> #+end_src
> -
> On Wed, Jul 7, 2021 at 6:29 AM tbanelwebmin  wrote:
>
>> Hi Matt
>>
>> Le 05/07/2021 à 21:44, Matt Price a écrit :
>> > I have to write a number of text-heavy documents which need to be
>> > delivered as tables with wrapped paragraphs in most cells. Working
>> > directly in table format is pretty arduous and uncomfortable.  Has
>> > anyone ever written a function to accept a list or subtree as input
>> > and process it into a table?
>> >
>> > If anyone has done something similar, I'd love some tips!
>>
>> Maybe you could use builtin Babel
>> Hereafter you have a starting point
>> - Give a name to your input Org list
>> - Process it with Emacs-Lisp (or whatever language you are comfortable
>> with) to output it as a table
>>
>>
>>  self contained Org Mode example _
>>
>> Example of a named list
>> #+NAME: BBB
>> - abc
>>   + 123
>>   + 456
>> - def
>>   + red
>>   + blue
>> - ghi
>>   + big
>>   + small
>>
>> Example of converting the named list into a table with Emacs-Lisp
>> #+begin_src elisp :var bbb=BBB :results table
>> bbb
>> #+end_src
>>
>> #+RESULTS:
>> | abc | (unordered (123) (456))   |
>> | def | (unordered (red) (blue))  |
>> | ghi | (unordered (big) (small)) |
>> ___
>>
>>
>>

Re: Citations merged!

[Christian Moe]

Wow, congratulations!

Yours,
Christian

Nicolas Goaziou writes:

> Hello,
>
> It took years, but citations are now full part of Org syntax.
>
> Thanks to everyone involved over the time!
>
> Now, it needs to be documented, but that will come a bit later.
>
> Regards,

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

I frequently need to escape commas in macros, which is a bit of a pain
and easy to forget. My most frequent use case is a macro that expands in
ODT export to a margin comment (like #+begin_annotation does, but
without causing a line break). It takes one argument which typically
consists of several lines of text with commas in them. If I forget to
escape a comma, the rest of the comment is silently lost to the reader.

So a backwards-compatible remedy would be nice. Juan's/Nicholas's
solution is smart, but I'm not sure if it's exactly what I've been
waiting for. It saves escaping every comma, but I'd still have to
remember to add the separator character every time I *invoke* a macro,
and remembering is the tricky part. I don't know if you've already
considered the option of instead specifying a different separator in the
macro *definition*, say something like

  #+macro: comment @@html:@@ :sep "&"

Another point: Something that would help, without adding new syntax, is
making macro expansion smart enough to *ignore* separators when the
macro definition contains only *one* argument anyway, as in the cases
above. That behavior would also be safely backwards-compatible, I
think. It would not help with macros with more than one arg, like Juan's
example, but it would solve most of my problems, for example.

Yours,
Christian


Juan Manuel Macías writes:

> Hi all,
>
> Thanks for your comments, Bastien and Nicolas.
>
> I think macros can work out of the box as a perfect 'backend' for those
> LaTeX commands that include at least one argument with textual content.
> In my case they are very useful to 'extend' the markup language. Apart
> from the LaTeX example that I put previously
> (\foreignlanguage{lang}{short-text}), there are commands like
> \textsc{text in small caps}, \textcolor{color}{text}, and so on. When
> one of the arguments consists of textual content, even if it is a short
> text, it can be tedious to escape constantly commas[1]. Anyway, I
> understand that my use case may not be that of the rest of the users,
> and what is a 'problem' for me, it may not be seen as a problem by other
> users; therefore, I fully understand Bastien's warnings about making a
> modification to something that already works fine, and has been working
> fine since always.
>
> Nicolas's suggestion seemed the most reasonable, or the least
> destructive, in the hypothetical scenario that there would be a great
> demand among users of an alternative separator. Now I see unlikely,
> however, that such a demand exists ;-) So, if my use case is a minority,
> of course I agree with give up this proposal...
>
> [1] To mitigate 'comma issue' I wrote a function that escapes commas
> when saving document :-D
>
> Best regards,
>
> Juan Manuel
>
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Bastien  writes:
>>
>>> thank you for the patch.  I understand the general idea, but I think
>>> we should be careful not to overload the macro syntax - escaping the
>>> coma seems okay to me.  I'm closing this suggestion.
>>>
>>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>>> course insist on rejecting it.
>>
>> This is a followup to a previous discussion in this mailing list, in
>> which Juan Manuel explained his use-case for a different argument
>> separator in macros. I noticed then that there was an opening for
>> a backward compatible syntax extension for it. As I was also not certain
>> it would be a good idea overall, I suggested him to start a new, more
>> visible, thread with the proposal, and collect feedback.
>>
>> So, maybe it is a bit early to close it.
>>
>> BTW, I would like to amend the proposed syntax, so as to limit friction
>> with the rest of Org. What would be more reasonable is the following:
>>
>>{{{macroname·(...)}}}
>>
>> where · is either nothing or a _single_ printable non-alphanumeric
>> non-space non-parenthesis character that isn't already meaningful in
>> Org. For example, if for some reason, we limit ourselves to ASCII
>> characters only, the set of allowed separators would be:
>>
>>!   %   &   ,   ;   ?   `
>>
>> So, again, I'm not saying we should do this. TBH, I'm not convinced by
>> the idea of duplicate syntax (comma-escaping and alternate characters)
>> for the same thing. But hard-core macro users may have a word to say
>> about it.
>>
>> WDYT?
>>
>> Regards,

Re: Free up C-c SPC/org-table-blank-field?

[Christian Moe]

Tim Cross writes:

> Eric Abrahamsen  writes:
>
>>> Does it actually need a key binding? I've never used it and just use
>>>  to move to the next field, leaving the field blank.
>>
>> I assume it's meant for blanking a field you've already typed something
>> into. But yes, I can't imagine it's a heavily-used command, and I
>> suspect the C-c  binding is mostly mnemonic: "make this field
>> contain only blanks".
>>
>
> I guess that makes sense, but not convinced the use of a valuable key
> binding is justified given the need. Then again, others probably have
> vastly different use cases to mine.

One can also blank a field by pressing  immediately after tabbing
into it. So C-c  isn't strictly needed.

(Though since you typically discover you want to blank a field only when
you're actually in it, it can help shave a few seconds off your day that
you'd otherwise use to move out of the field you want to blank and tab
back in ... which is how I've done this until now, being unaware of C-c
).

Yours,
Christian