Re: [O] Capture Bug?

[Adam Porter]

Nick Dokos  writes:

> That's not going to work: unquoting[fn:1] evaluates the unquoted
> element during the setting of org-capture-templates. That would have
> the effect of evaluating the function call when the setq is evaluated,
> whereas the intent here is to evaluate the function call *much* later,
> when the capture is initiated.

Yes, I think you're right. Thanks, Nick.  :)

Re: [O] Feedback on changes to org-id

[Adam Porter]

Aaron Ecay  writes:

> The API has the following two functions already:
> - org-id-find-file-for: id -> file-name
> - org-id-find-id-in-file: id file -> position
>
> Imagine I add to this API org-id-find-marker: id -> marker.  Then I
> think we can deprecate (and eventually delete) org-id-find, since all its
> uses can be replaced by some combination of the other 3 functions.  (We
> could also keep it as a convenience function wrapping the other 3, but
> it hardly seems worth it: the marker case just adds the overhead of
> another funcall, whereas a significant proportion of the non-marker
> calls in the codebase actually only care about the file name, so it is a
> waste of effort to calculate the buffer position only to throw it away.)

Personally, I wish org-id-find would not be removed, because I use it in
org-bookmark-heading, e.g.:

https://github.com/alphapapa/org-bookmark-heading/blob/master/org-bookmark-heading.el#L126

On the other hand, maybe this is a good time to see about getting
org-bookmark-heading into org itself, in which case whoever changes the
API would be responsible for updating it... ;)  WDYT?

Re: [O] How to use org mode shell with ssh?

[William Denton]

On 22 September 2016, Xi Shen wrote:


#+BEGIN_SRC sh :dir /sshx:openwrt:/mnt/sda1
ls -al
#+END_SRC


Just use ssh, not sshx, and it should work.

Bill
--
William Denton :: Toronto, Canada :: https://www.miskatonic.org/
Caveat lector.

[O] apply attr_html to a whole figure?

[Matt Price]

When exporting images with captions, ox-html currently creates a strucuture
like this:





Figure 1: "test"


(I've tried setting org-html-html5-fancy" to t, but for whatever reason
this doesn't result in the useo f the  tag. I tried with emacs -q
with no luck).

I would like to be able to give an additional class to the enclosing .  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 can't query for attributes.

I really appreciate any ideas! Thanks,
Matt

Re: [O] Dynamic tangle target?

[Charles C. Berry]

On Wed, 21 Sep 2016, Philip Hudson wrote:


AFAICT :tangle takes only "yes", "no", or a literal pathname.


Stuff like

   :tangle (my-lisp-function arg1 arg2)

will work.


How
might I dynamically generate a pathname for :tangle? I suppose what I
want is some kind of escape syntax for eval'ing a Lisp form, like
maybe:

   :tangle %(my-dynamic-filename-generator)


Try this:

#+BEGIN_SRC R :tangle (concat "my-" "file" ".R")
abs <- def
#+END_SRC

just as an example.

BTW, org-babel-view-src-block-info (C-c C-v C-i) will show you what header 
args evaluate as without the need to eval or tangle them.


HTH,

Chuck

[O] How to use org mode shell with ssh?

[Xi Shen]

Hi,

I tried this block

#+BEGIN_SRC sh :dir /sshx:openwrt:/mnt/sda1
ls -al
#+END_SRC

But I got

byte-code: Method `sshx' should specify both encoding and decoding command
or an scp program

But I could not find a way to define the encoding/decoding command...
-- 


Thanks,
David S.

[O] Babel Export - Getting asked for coding system

[David A. Gershman]

I have a block of Perl using the GD library to generate a PNG:

#+BEGIN_SRC perl : results output :file output.png :exports results
  # code to generate png
  print $image -> png();
#+END_SRC

When I export, I get a buffer with the raw PNG data and the question (in the 
mini-buffer):

Select coding system (default raw-text):

Hitting enter will then continue as expected.

Is there a way to specify just dumping the result out to the file without 
asking the question?  Adding 'raw' to ":results" doesn't do it.

--dag
-- 
David A. Gershman, CISSP
dagersh...@dagertech.net

Re: [O] Feedback on changes to org-id

[Aaron Ecay]

Hi Nicolas,

Thanks for your feedback.  I am almost done incorporating it into the
patch.  I have only two further questions.

2016ko irailak 3an, Nicolas Goaziou-ek idatzi zuen:

[...]

>> 4. A similar issue arises for org-id-find.  I would like it to always
>> return a marker, rather than having an argument switch between a
>> marker and a cons of filename and position.  (There are functions
>> which return the filename or position individually, so returning both
>> as a cons is useless from an API point of view).  There’s no good way
>> to detect the old calling convention, however, so I think I have to
>> introduce a new name.  (My draft patch is written instead with hard
>> breakage, but stability of API is important so I will change
>> that...)
> 
> Please don't make that change. A marker is pointless if the file is not
> currently associated to any buffer. In that case (file-name . postition)
> cons cell is a valuable return value.

The API has the following two functions already:
- org-id-find-file-for: id -> file-name
- org-id-find-id-in-file: id file -> position

Imagine I add to this API org-id-find-marker: id -> marker.  Then I
think we can deprecate (and eventually delete) org-id-find, since all its
uses can be replaced by some combination of the other 3 functions.  (We
could also keep it as a convenience function wrapping the other 3, but
it hardly seems worth it: the marker case just adds the overhead of
another funcall, whereas a significant proportion of the non-marker
calls in the codebase actually only care about the file name, so it is a
waste of effort to calculate the buffer position only to throw it away.)

WDYT?

> 
> You can also remove `org-id-track-globally'. "org-id.el" is useless if
> it is set to nil anyway, since CUSTOM_ID does a better job in this
> case.

I think this would imply writing the ID database to ‘org-id-locations-file’
under certain circumstances without asking/letting the user approve this
action.  Is that OK?  (I am not bothered by it, FWIW).

If it’s not acceptable, perhaps this variable should be replaced by a
new defcustom ‘org-id-write-database’ which would control only the
writing of the DB to disk (but unlike the existing implementation would
not turn off the ID tracking code paths within the emacs session).

TIA,

-- 
Aaron Ecay

[O] XML dump of org file?

[Norman Walsh]

Hi,

There are various export filters, but I’d like one that just does a
complete, raw dump of the internal memory structure[*]. I could start
with something like the HTML export and work backwards to output other
tag names, but it seems like it should be possible to just dump the
data structure.

My brief couple-of-hours foray into this was unsuccessful. I ran
aground in various places where I couldn’t really grok the structure
well enough to deduce what to output. And possibly where my elisp
coding skills are a little weak.

Before I spend another few evenings poking it with a sharp stick, does
anyone have some code that walks the data structure in a way that will
make it easier? (Or has someone else, *gasp*, solved this exact
problem? :-))

Be seeing you,
  norm

[*] I have really good XML tools for querying, transforming, and
otherwise manipulating the data. I want to start with as near to
perfect fidelity as I can. I don’t have any short term plans to try to
go the other way, but I might eventually.

-- 
Norman Walsh  | When we are tired, we are attacked by
http://nwalsh.com/| ideas we conquered long ago.--Nietzsche


signature.asc
Description: PGP signature

Re: [O] Capture Bug?

[Nick Dokos]

Adam Porter  writes:

> li...@wilkesley.net writes:
>
>> I have a capture template which prompts for a file name and uses this
>> to create a filename with a datestamp:
>>
>> (defun capture-pelican-draft-file (path)
>>   (let ((name (read-string "Name: ")))
>> (expand-file-name (format "%s-%s.org"
>>   (format-time-string "%Y-%m-%d")
>>   name) path)))
>>
>>
>> ("g"
>>"New blog post (ianbarton.net)"
>>plain
>>(file (capture-pelican-draft-file
>> "~/Documents/emacs/web_sites/ianbarton.net/org/_posts"))
>>"#+AUTHOR: Ian Barton\n#+DATE: %u\n#+PROPERTY: MODIFIED:
>> \n#+TITLE\n#+CATEGORY: Blog \n#+PROPERTY: TAGS \n#+PROPERTY: SUMMARY
>> \n#+SETUPFILE: ../setup.org\n\n")
>
> Are you using custom-set-variables to set org-capture-templates?  If
> not, I think you need to unquote capture-pelican-draft-file.

That's not going to work: unquoting[fn:1] evaluates the unquoted
element during the setting of org-capture-templates. That would have
the effect of evaluating the function call when the setq is evaluated,
whereas the intent here is to evaluate the function call *much* later,
when the capture is initiated.


* Footnotes

[fn:1]  ... by which I hope I mean the same thing you do:
using backquote instead of quote in front of the  in

(setq org-capture-templates )

and then using , to unquote some internal elements, allowing their
evaluation and therefore replacing them with the results of the
evaluation in the binding of org-capture-templates.

-- 
Nick

Re: [O] Capture Bug?

[Nicolas Goaziou]

Hello,

li...@wilkesley.net writes:

> commit 5485170263a46fa17db67b0324c4c4e48bcdfe49
> Author: Nicolas Goaziou 
> Date:   Fri Jun 24 01:11:49 2016 +0200
>
> org-capture: Remove forbidden value type from "file" templates
>
Try wrapping `capture-pelican-draft-file' call within a function instead
of putting a raw sexp.

Regards,

-- 
Nicolas Goaziou

Re: [O] [patch] more Beamer properties

[Nicolas Goaziou]

Hello,

Rasmus  writes:

>> I think
>>
>>   #+TITLEGRAPHICS: [[file:link.pdf]]
>>
>> would be cleaner.
>
> I dropped this.  One might need to add attributes to the graphic.  The
> #+titlegraphics approach wouldn’t allow it.

Well, wouldn't the following work?

  #+attr_beamer: :attribute1 value1 :attribute2 value2
  #+TITLEGRAPHICS: [[file:link.pdf]]

> +(:beamer-short-title "SHORT_TITLE" nil nil parse)
> +(:beamer-short-subtitle "SHORT_SUBTITLE" nil nil parse)
> +(:beamer-short-author "SHORT_AUTHOR" nil nil parse)
> +(:beamer-short-date "SHORT_DATE" nil nil parse)
> +(:beamer-institute "INSTITUTE" nil nil parse)
> +(:beamer-short-institute "SHORT_INSTITUTE" nil nil parse)

Per above, would the following be cleaner?

  #+attr_beamer: :short shortdate
  #+date: longdate

Ditto for title, institute, author...

Regards,

-- 
Nicolas Goaziou

Re: [O] Disable org-babel-inline-result-wrap per inline code?

[Adam Porter]

"David A. Gershman"  writes:

> FWIW, Eric had the solution:
>
> #+MACRO: gendate src_perl[:results output raw]{print ($1*5);}

Ah, yes, I tend to forget that :results can take multiple args.

> P.S. I should start a blog with all I learn on this. Someone could
> benefit from my struggles. :)

Yes, you definitely should!

By the way, did you know that your client is sending HTML mail to the
list?

Re: [O] Capture Bug?

[Adam Porter]

li...@wilkesley.net writes:

> the previous commit looks as though it
> might have been the one responsible:
>
> commit 5485170263a46fa17db67b0324c4c4e48bcdfe49
> Author: Nicolas Goaziou 
> Date:   Fri Jun 24 01:11:49 2016 +0200
>
> org-capture: Remove forbidden value type from "file" templates

That definitely sounds relevant!

> I'll try unquoting capture-pelican-draft-file.

Let me know if it works.  I still often get confused when dealing with
quoting and unquoting and...

[O] Dynamic tangle target?

[Philip Hudson]

AFAICT :tangle takes only "yes", "no", or a literal pathname. How
might I dynamically generate a pathname for :tangle? I suppose what I
want is some kind of escape syntax for eval'ing a Lisp form, like
maybe:

:tangle %(my-dynamic-filename-generator)

Sorry if I'm missing something basic and obvious; I'm new to tangling.
I've been looking for a few days and found nothing so far, and even
though I'm sure the answer is out there, it seemed like at this point
my best bet is just to ask the ML. Might the answer be something to do
with either declaring a variable or using noweb syntax? I'm pretty
much in the dark here.

-- 
Phil Hudson   http://hudson-it.ddns.net
@UWascalWabbit PGP/GnuPG ID: 0x887DCA63

Re: [O] Something to watch out for when including files

[Eric S Fraga]

On Wednesday, 21 Sep 2016 at 15:22, Giacomo M wrote:
> Lately I like to have headlines for all the logical parts of the 
> document, so also an "Abstract" headline with the abstract block inside. 
> Then I use the tag "ignore" and the org export extra "ignore-headlines" 
> (activated e.g. via "(ox-extras-activate '(ignore-headlines))" if you 
> use org-plus-contrib) to avoid exporting the headlines themselves. This 
> should also avoid the inheritance of tags in the last headline of the 
> include. Not vanilla org, but I find it handy.

This is basically what I do.  I even have (ignored) headlines that have
a content that is simply a @@latex:\newpage@@ directive!

The problem is that if you have a headline that is ignored, the text
that follows essentially belongs to the previous non-ignored
headline.  If that previous headline has been commented out or has been
marked as not to be exported, the text after the ignored headline is
also therefore ignored when it comes to export.

Ignoring headlines is very fragile in the same way as described in my
original post.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa

Re: [O] Capture Bug?

[lists]

On 2016-09-21 12:54, Adam Porter wrote:

li...@wilkesley.net writes:


I have a capture template which prompts for a file name and uses this
to create a filename with a datestamp:

(defun capture-pelican-draft-file (path)
  (let ((name (read-string "Name: ")))
(expand-file-name (format "%s-%s.org"
  (format-time-string "%Y-%m-%d")
  name) path)))


("g"
   "New blog post (ianbarton.net)"
   plain
   (file (capture-pelican-draft-file
"~/Documents/emacs/web_sites/ianbarton.net/org/_posts"))
   "#+AUTHOR: Ian Barton\n#+DATE: %u\n#+PROPERTY: MODIFIED:
\n#+TITLE\n#+CATEGORY: Blog \n#+PROPERTY: TAGS \n#+PROPERTY: SUMMARY
\n#+SETUPFILE: ../setup.org\n\n")


Are you using custom-set-variables to set org-capture-templates?  If
not, I think you need to unquote capture-pelican-draft-file.


On the current git master the function capture-pelican-draft-file

doesn't seem to be evaluated, resulting in a "File name doesn't exist"
error. Doing git bisect seems to point at the commit below:

8860c92f62dac87267416708e81bc8aec026fcc7 is the first bad commit
commit 8860c92f62dac87267416708e81bc8aec026fcc7
Author: Nicolas Goaziou 
Date:   Fri Jun 24 00:55:03 2016 +0200


That commit is about org-babel, which I don't think should have 
anything

to do with org-capture.  But you said you bisected it, so you mean that
before that commit, your code works as-is?


Thanks, I'll redo my bisect. I was being harassed by the dog, so might 
have made a mistake! However, the previous commit looks as though it 
might have been the one responsible:


commit 5485170263a46fa17db67b0324c4c4e48bcdfe49
Author: Nicolas Goaziou 
Date:   Fri Jun 24 01:11:49 2016 +0200

org-capture: Remove forbidden value type from "file" templates

I'll try unquoting capture-pelican-draft-file.

Ian.

Re: [O] [HELP]: How to export top level trees in an org file to corresponding files?

[Pierre Corry]

Well, I ended up with my custom function then...
So case is closed.
Thank for the help anyway!

(defun me/org-map-entries (org-file in-tags func)
  (let* ((tags (if (stringp in-tags)
   (list in-tags)
 in-tags)))

(with-temp-buffer
  (org-mode)
  (insert-file-contents org-file-main)

  ;; Execute func at each heading that matches tags.
  (while (< (point) (point-max))

;; If find a heading...
(and (search-forward-regexp "^\* " nil "end")

 ;; ...that matches the given tags...
 (seq-reduce
  (lambda(a b) (and a b))
  (mapcar
   (lambda (tag)
 (beginning-of-line)
 (search-forward-regexp
  (concat ":" tag ":") (line-end-position) "end"))
   tags)
  t)

 ;; ... then execute given function with cursor at beginning of
 ;; heading.
 (progn
   (beginning-of-line)
   (save-excursion
 (funcall func))
   (end-of-line)))



2016-09-21 12:29 GMT+02:00 Pierre Corry <284a6...@gmail.com>:

> Hi!
>
> Executing the following code should create, for each top level tree in
> your file `~/tmp/file.org`, an other file in `~/tmp` named after the tree
> heading and containing its content.
>
> Problem: it does not work.
>
> The content is not the one expected...
>
> Is it me or the code that is wrong? Both?
> Question on emacs.stackexchange
> 
>
> (require 'ox-publish)
>
> (let ()
>   (with-temp-buffer
> (org-mode)
> (insert-file-contents "~/tmp/file.org")
> (set-mark (point-min))
> (goto-char (point-max))
>
> (org-map-entries
>  (lambda ()
>(let ((entry_id (replace-regexp-in-string " " "_" (downcase
> (nth 4 (org-heading-components))
>  (org-set-property
>   "EXPORT_FILE_NAME"
>   (expand-file-name entry_id "~/tmp")))
>(org-org-export-to-org nil t)
>)
>  nil
>  'region-start-level)))
>
> Content of `file.org`:
>
> * Headline 1
>  :ready:
>
>   Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Praesent
> libero orci,
>   auctor sed, faucibus vestibulum, gravida vitae, arcu. Nunc posuere.
> Suspendisse
>   potenti. Praesent in arcu ac nisl ultricies ultricies. Fusce eros.
> Sed pulvinar
>   vehicula ante. Maecenas urna dolor, egestas vel, tristique et, porta
> eu,
>   leo. Curabitur vitae sem eget arcu laoreet vulputate. Cras orci
> neque, faucibus
>   et, rhoncus ac, venenatis ac, magna. Aenean eu lacus. Aliquam luctus
> facilisis
>   augue. Nullam fringilla consectetuer sapien. Aenean neque augue,
> bibendum a,
>   feugiat id, lobortis vel, nunc. Suspendisse in nibh quis erat
> condimentum
>   pretium. Vestibulum tempor odio et leo. Sed sodales vestibulum
> justo. Cras
>   convallis pellentesque augue. In eu magna. In pede turpis, feugiat
> pulvinar,
>   sodales eget, bibendum consectetuer, magna. Pellentesque vitae augue.
>
>   [[file:data/fool.jpg][Foo]]
>
>
>
> * Headline 2
>  :ready:
>
>   Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Praesent
> libero orci,
>   auctor sed, faucibus vestibulum, gravida vitae, arcu. Nunc posuere.
> Suspendisse
>   potenti. Praesent in arcu ac nisl ultricies ultricies. Fusce eros.
> Sed pulvinar
>   vehicula ante. Maecenas urna dolor, egestas vel, tristique et, porta
> eu,
>   leo. Curabitur vitae sem eget arcu laoreet vulputate. Cras orci
> neque, faucibus
>   et, rhoncus ac, venenatis ac, magna. Aenean eu lacus. Aliquam luctus
> facilisis
>   augue. Nullam fringilla consectetuer sapien. Aenean neque augue,
> bibendum a,
>   feugiat id, lobortis vel, nunc. Suspendisse in nibh quis erat
> condimentum
>   pretium. Vestibulum tempor odio et leo. Sed sodales vestibulum
> justo. Cras
>   convallis pellentesque augue. In eu magna. In pede turpis, feugiat
> pulvinar,
>   sodales eget, bibendum consectetuer, magna. Pellentesque vitae augue.
>
>   [[file:data/fool-2.jpg][Foo2]]
>
>
> Expected result:
>
> `heading_1.org`:
>
> * Headline 1
>  :ready:
>
>   Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Praesent
> libero orci,
>   auctor sed, faucibus vestibulum, gravida vitae, arcu. Nunc posuere.
> Suspendisse
>   potenti. Praesent in arcu ac nisl ultricies ultricies. Fusce eros.
> Sed pulvinar
>   vehicula ante. Maecenas urna dolor, egestas vel, tristique et, porta
> eu,
>   leo. Curabitur vitae sem eget arcu laoreet vulputate. Cras orci
> neque, faucibus
>   et, rhoncus ac, venenatis ac, magna. Aenean eu lacus. Aliquam luctus
> facilisis
>   augue. Nullam fringilla consectetuer sapien. 

Re: [O] Something to watch out for when including files

[Giacomo M]

Il 20/09/2016 17:21, Eric S Fraga ha scritto:

I had a #+include: directive as the first line of the
file which included an org file called preamble.org.  In that preamble
file, the last headline had the tag :noexport:.  It would seem that this
tag is not processed until after the include file has been included.  I
hope that makes sense.  In any case, this means that my abstract was
considered to be part of the noexport headline and was therefore not
exported.


Lately I like to have headlines for all the logical parts of the 
document, so also an "Abstract" headline with the abstract block inside. 
Then I use the tag "ignore" and the org export extra "ignore-headlines" 
(activated e.g. via "(ox-extras-activate '(ignore-headlines))" if you 
use org-plus-contrib) to avoid exporting the headlines themselves. This 
should also avoid the inheritance of tags in the last headline of the 
include. Not vanilla org, but I find it handy.


Giacomo

Re: [O] Disable org-babel-inline-result-wrap per inline code?

[David A. Gershman]

On 09/21/2016 04:49 AM, Adam Porter wrote:
> "David A. Gershman"  writes:
>
>> Given the following line:
>>
>> * Date: src_perl[:results output :exports none]{print 2016;}
>>
>> The result '2016' is surrounded by '=' so that HTML export results in
>>  tags surrounding
>> the '2016'. 
>>
>> According to the manual section 14.5, 'org-babel-inline-result-wrap'
>> defines how the results are wrapped. Executing a (print
>> org-babel-inline-result-wrap), I get:
>>
>> {blank line}
>> =%s=
>> =%s=
>>
>> so I attempted the following:
>>
>> * Date: src_emacs-lisp[:exports none]{(setq
>> org-babel-inline-result-wrap "")} src_perl[:results output :exports
>> none]{print 2016;} src_emacs-lisp[:exports none]{(setq
>> org-babel-inline-result-wrap "=%s=")}
>>
>> in the hopes of temporarily disabling the '=' wrapping. Sadly no luck.
>>
>> I don't want to globally, or even for the whole buffer turn off the
>> '=%s='...just on a case-by-case basis.
> Hi David,
>
> I haven't done anything quite like this in Org before, but I think maybe
> Org macros would do what you need:
>
> http://orgmode.org/manual/Macro-replacement.html
>
> According to that, "Macro expansion takes place during the very
> beginning of the export process."  So it should be easy to write a macro
> that evaluates to a date in the format you need, and it should take
> effect when you export it to HTML.  At least, that's what it sounds like
> to me.  Please let me know what you find out.  :)
>
That's actually how I'm doing it, but I'm not fully up on how macros
work short of just being text replacements.  Currently, at the top of my
file, I have:

#+MACRO: gendate src_perl[:results output]{print ($1*5);}
# Where 'print ($1*5);' will later be replaced with a perl function that
takes the first day of class and an integer
# ex:  /print find_date( '20160926', 6 );/ # 6 = Sixth lecture day,
output: "6, Oct 12, 2016" assuming MW class.

and in the org file, I can have headlines:

* Day {{{gendate(6)}}}
...
* Day {{{gendate(10)}}}

and so on.  During export, the result desired is:

   /Day 6, Oct 12, 2016/
{etc.}

FWIW, Eric had the solution:

#+MACRO: gendate src_perl[:results output _/*raw*/_]{print ($1*5);}

Thank everyone!

--dag

P.S. I should start a blog with all I learn on this.  /Someone/ could
benefit from my struggles. :)

Re: [O] [org-src, patch] colored source blocks

[Aaron Ecay]

Hi Rasmus,

The patch in general LGTM.  One comment/question, though:

2016ko irailak 21an, Rasmus-ek idatzi zuen:

[...]


> +(defcustom org-src-block-faces nil
> +  "Alist of faces to be used for source-block.
> +Each element is a cell of the format
> +
> + (\"language\" FACE-OR-BACKGROUND)
> +
> +Where FACE-OR-BACKGROUND is either a face, an anonymous face, or
> +a string corresponding to a background color.

Why do you support a background color string here?  I think that it’s
easy to specify faces which consist of a background color only both in
lisp [(:background "XXX") vs. "XXX"] and via the customize interface.
So this flexibility seems to just introduce additional complications for
virtually no benefit in usability.  But maybe I’m missing something...?

-- 
Aaron Ecay

Re: [O] Inline HTML?

[David A. Gershman]

On 09/21/2016 12:15 AM, Christian Moe wrote:
> 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.
Yes, you're correct.  My apologies, I misspoke.
>
>> 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
>
Nice!  Thank you!  That's much cleaner!

--dag

Re: [O] Disable org-babel-inline-result-wrap per inline code?

[David A. Gershman]

Perfect!!  Thank you!!

I saw this option in the Manual (14.8.2.2) under /Format/, but it said
it "The results are interpreted asraw Org mode code..." so it didn't
click the results would "left alone".

Thanks again!

On 09/21/2016 12:11 AM, Eric S Fraga wrote:
> On Wednesday, 21 Sep 2016 at 06:07, David A. Gershman wrote:
>> Given the following line:
>>
>> * Date: src_perl[:results output :exports none]{print 2016;}
> How about 
>
> * Date: src_perl[:results output raw]{print 2016;}
>
> ?
>

Re: [O] Disable org-babel-inline-result-wrap per inline code?

[Nick Dokos]

"David A. Gershman"  writes:

> Forgive my several questions/emails.  I'm working on getting lecture
> notes ready for next week and thus am running into several questions
> with Org HTML Export.  Unfortunately, my searches typically result
> in manual page hits, but my problems seem to be a-typical.  So...
>
> Given the following line:
>
> * Date: src_perl[:results output :exports none]{print 2016;}
>
> The result '2016' is surrounded by '=' so that HTML export results
> in  tags surrounding the '2016'. 
>

I think that should be :exports results, not none.

> According to the manual section 14.5, 'org-babel-inline-result-wrap'
> defines how the results are wrapped.  Executing a (print
> org-babel-inline-result-wrap), I get:
>
>     {blank line}
>     =%s=
>     =%s=
>

C-h v org-babel-inline-result-wrap says that it has to have a %s in
it: you can't just set it to "".

> so I attempted the following:
>
>   * Date: src_emacs-lisp[:exports none]{(setq org-babel-inline-result-wrap 
> "")} src_perl[:results output :exports none]{print 2016;} 
> src_emacs-lisp[:exports none]{(setq
> org-babel-inline-result-wrap "=%s=")}
>

OTOH, modifying your attempt a bit to conform to the above did not work for me 
either:

 * Date: src_emacs-lisp[:exports none :results none ]{(setq 
org-babel-inline-result-wrap "%s")} src_perl[:results output :exports 
results]{print 2016;} src_emacs-lisp[:exports none :results  none]{(setq 
org-babel-inline-result-wrap "=%s=")}

still gives me the  tags. When I C-c C-c by hand on the
lisp src blocks, the variable does change value, so I don't understand
why putting the whole thing together does not work.

> in the hopes of temporarily disabling the '=' wrapping.  Sadly no luck.
>
> I don't want to globally, or even for the whole buffer turn off the
> '=%s='...just on a case-by-case basis.
>
> Any ideas?
>
> --dag
>
> P.S.  In reality, 2016 will be replaced with a function call which
> takes an integer and converts it to a full blown date based on a
> starting point.  Thus, the headlines will result in "Date: September
> 20, 2016" where each date is different based on the integer.  This
> will allow me to set the starting date at the top of the .org file
> and all the date-based headlines can be computed.
>

-- 
Nick

Re: [O] Capture with org-directory not working?

[Rainer M Krug]

Adam Porter  writes:

> Rainer Krug  writes:
>
>> But It seems to abusing the basic idea of custom-set-variables as this
>> sounds as if it is used by the customise interface.
>
> What I mean is, you can use the customize interface to store your
> org-capture-templates.  It's already set up for that.  You can either
> edit it through the customize interface, or you can edit it directly in
> the init file and then evaluate the ~(custom-set-variables~ sexp manually.
>

OK - but I prefer to keep my configurations in my .emacs.el file to make
it reproducible.


Thanks,

Rainer

>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Capture Bug?

[Adam Porter]

li...@wilkesley.net writes:

> I have a capture template which prompts for a file name and uses this
> to create a filename with a datestamp:
>
> (defun capture-pelican-draft-file (path)
>   (let ((name (read-string "Name: ")))
> (expand-file-name (format "%s-%s.org"
>   (format-time-string "%Y-%m-%d")
>   name) path)))
>
>
> ("g"
>"New blog post (ianbarton.net)"
>plain
>(file (capture-pelican-draft-file
> "~/Documents/emacs/web_sites/ianbarton.net/org/_posts"))
>"#+AUTHOR: Ian Barton\n#+DATE: %u\n#+PROPERTY: MODIFIED:
> \n#+TITLE\n#+CATEGORY: Blog \n#+PROPERTY: TAGS \n#+PROPERTY: SUMMARY
> \n#+SETUPFILE: ../setup.org\n\n")

Are you using custom-set-variables to set org-capture-templates?  If
not, I think you need to unquote capture-pelican-draft-file.

>> On the current git master the function capture-pelican-draft-file
> doesn't seem to be evaluated, resulting in a "File name doesn't exist"
> error. Doing git bisect seems to point at the commit below:
>
> 8860c92f62dac87267416708e81bc8aec026fcc7 is the first bad commit
> commit 8860c92f62dac87267416708e81bc8aec026fcc7
> Author: Nicolas Goaziou 
> Date:   Fri Jun 24 00:55:03 2016 +0200

That commit is about org-babel, which I don't think should have anything
to do with org-capture.  But you said you bisected it, so you mean that
before that commit, your code works as-is?

Re: [O] Capture with org-directory not working?

[Adam Porter]

Rainer Krug  writes:

> But It seems to abusing the basic idea of custom-set-variables as this
> sounds as if it is used by the customise interface.

What I mean is, you can use the customize interface to store your
org-capture-templates.  It's already set up for that.  You can either
edit it through the customize interface, or you can edit it directly in
the init file and then evaluate the ~(custom-set-variables~ sexp manually.

Re: [O] Disable org-babel-inline-result-wrap per inline code?

[Adam Porter]

"David A. Gershman"  writes:

> Given the following line:
>
> * Date: src_perl[:results output :exports none]{print 2016;}
>
> The result '2016' is surrounded by '=' so that HTML export results in
>  tags surrounding
> the '2016'. 
>
> According to the manual section 14.5, 'org-babel-inline-result-wrap'
> defines how the results are wrapped. Executing a (print
> org-babel-inline-result-wrap), I get:
>
> {blank line}
> =%s=
> =%s=
>
> so I attempted the following:
>
> * Date: src_emacs-lisp[:exports none]{(setq
> org-babel-inline-result-wrap "")} src_perl[:results output :exports
> none]{print 2016;} src_emacs-lisp[:exports none]{(setq
> org-babel-inline-result-wrap "=%s=")}
>
> in the hopes of temporarily disabling the '=' wrapping. Sadly no luck.
>
> I don't want to globally, or even for the whole buffer turn off the
> '=%s='...just on a case-by-case basis.

Hi David,

I haven't done anything quite like this in Org before, but I think maybe
Org macros would do what you need:

http://orgmode.org/manual/Macro-replacement.html

According to that, "Macro expansion takes place during the very
beginning of the export process."  So it should be easy to write a macro
that evaluates to a date in the format you need, and it should take
effect when you export it to HTML.  At least, that's what it sounds like
to me.  Please let me know what you find out.  :)

Re: [O] [patch] more Beamer properties

[Rasmus]

Hi,

Thanks for the suggestions.

Sorry about the slow reply...  I'm lacking time ATM.

I simplified the patch to only add the short version of properties and not
include the titlegraphics.

> I didn't test your patch. However, here are some late comments about
> this suggestion.
>
>> Maybe we can have a titlegraphics like,
>>
>> #+attr_beamer: :titlegraphics t
>> [[file:link.pdf]]
>
> I think
>
>   #+TITLEGRAPHICS: [[file:link.pdf]]
>
> would be cleaner.

I dropped this.  One might need to add attributes to the graphic.  The
#+titlegraphics approach wouldn’t allow it.  I think it’s a problem that
can be pushed down the line.

>>   Plain List
>> @@ -855,21 +866,65 @@ holding export options."
>> (when (integerp sec-num)
>>   (format "\\setcounter{secnumdepth}{%d}\n" sec-num)))
>>   ;; Author.
>> - (let ((author (and (plist-get info :with-author)
>> -(let ((auth (plist-get info :author)))
>> -  (and auth (org-export-data auth info)
>> -   (email (and (plist-get info :with-email)
>> -   (org-export-data (plist-get info :email) info
>> + (let* ((author (and (plist-get info :with-author)
>> + (let ((auth (plist-get info :author)))
>> +   (and auth (org-export-data auth info)
>> +(short-author (and author (plist-get info :short-author)))
>
> Since "short-author" is `parsed', this should be wrapped within
> `org-export-data' somehow. You do it below, but it introduces some code
> duplication.
>
>> +(email (and (plist-get info :with-email)
>> +(org-export-data (plist-get info :email) info)))
>> +)
>
> You left a dangling parenthesis.
>
>> (cond ((and author email (not (string= "" email)))
>> -  (format "\\author{%s\\thanks{%s}}\n" author email))
>> - ((or author email) (format "\\author{%s}\n" (or author email)
>> +  (format "\\author%s{%s\\thanks{%s}}\n"
>> +  (if short-author
>> +  (format "[%s]" (org-export-data short-author info)) 
>> "")
>> +  author email))
>> + ((or author email) (format "\\author%s{%s}\n"
>> +(if short-author
>> +(format "[%s]" (org-export-data 
>> short-author info)) "")
>> +(or author email)
>
> See above. Also, I would move the (format ...) below (or author email)
>
>>   ;; Date.
>> - (let ((date (and (plist-get info :with-date) (org-export-get-date 
>> info
>> -   (format "\\date{%s}\n" (org-export-data date info)))
>> - ;; Title
>> - (format "\\title{%s}\n" title)
>> + (let* ((date (and (plist-get info :with-date) (org-export-get-date 
>> info)))
>> +;; TODO: add optional argument of ‘org-export-get-date’.
>> +(short-date (and date (org-export-data
>> +   (org-export-get-date
>> +(plist-put info :date
>> +   (plist-get info 
>> :beamer-short-date)))
>> +   info
>> +   (format "\\date%s{%s}\n" (if (org-string-nw-p short-date)
>> +(format "[%s]" short-date) "")
>
> I would put the "" below (format "[%s]" short-date): it doesn't make
> clear there is an else branch otherwise.
>
>> +   (org-export-data date info)))
>> + ;; Title.
>> + (let ((short-title (and title
>> + (plist-get info :beamer-short-title
>> +   (format "\\title%s{%s}\n"
>> +   (if short-title (format "[%s]" (org-export-data short-title 
>> info)) "")
>> +   title))
>
> See above.
>
>> + ;; Titlegraphics.
>> + (let ((titlegraphic-link
>> +(org-element-map (plist-get info :parse-tree) 'link
>> +  (lambda (link)
>> +(when (and (org-export-inline-image-p link)
>> +   (plist-get (org-export-read-attribute
>> +   :attr_beamer 
>> (org-export-get-parent-element link))
>> +  :titlegraphic))
>> +  link))
>> +  info t)))

Should all be fixed.

Thanks,
Rasmus

-- 
Human: An animal that complicates things more than strictly necessary
>From 56737ea87fd523d2e88b732af110008b993c7310 Mon Sep 17 00:00:00 2001
From: Rasmus 
Date: Thu, 2 Jun 2016 11:44:56 +0200
Subject: [PATCH 1/2] ox-beamer: Remove customizable subtitle

* lisp/ox-beamer.el (org-beamer-subtitle-format): Remove.
  (:options-alist): Remove :beamer-subtitle-format.
---
 doc/org.texi  |  4 +---
 lisp/ox-beamer.el | 11 ---
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 56779e8..2c9cb64 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -11077,9 +11077,7 @@ can use several @code{#+KEYWORDS} if the 

[O] [org-src, patch] colored source blocks

[Rasmus]

Hi,

As discussed earlier (though I can't find the thread right now) it would
be nice to have colored source blocks not depend on new faces but on a
variable.

This patch does that.

Is that OK to push?

Thanks,
Rasmus

-- 
The right to be left alone is a human right
>From cbac4cfa0655b70c6e1b825a8ba6d538722596b4 Mon Sep 17 00:00:00 2001
From: Rasmus 
Date: Wed, 21 Sep 2016 11:02:49 +0200
Subject: [PATCH] org-src.el: New syntax for source blocks faces

* doc/org.texi (Editing source code): Document changes.
* lisp/org-faces.el (org-block): Update docstring.
(org-src-block-faces): New defcustom for source-block faces.
* lisp/org-src.el (org-src-font-lock-fontify-block): Use
  org-src-block-faces.
* etc/ORG-NEWS: Update NEWS entry.
---
 doc/org.texi  | 17 -
 etc/ORG-NEWS  |  3 ++-
 lisp/org-faces.el | 31 +++
 lisp/org-src.el   | 10 +++---
 4 files changed, 44 insertions(+), 17 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 56779e8..8ab6c21 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14900,21 +14900,20 @@ By default, Org will ask before returning to an open edit buffer.  Set this
 variable to @code{nil} to switch without asking.
 @end table
 
-To turn on native code fontification in the @emph{Org} buffer, configure the
-variable @code{org-src-fontify-natively}.  You can also change the appearance
-of source blocks by customizing the @code{org-block} face or for specific
-languages, by defining @code{org-block-LANGUAGE} faces.  The following
-example shades the background of ``ordinary'' blocks while allowing Emacs
-Lisp source blocks to have a special color.
+To turn on native code fontification in the @emph{Org} buffer, set the
+variable @code{org-src-fontify-natively} to non-@code{nil}.  You can also
+change the appearance of source blocks in general by customizing the
+@code{org-block} face or @code{org-src-block-faces} for specific languages.
+The following example shades the background of ``ordinary'' blocks while
+allowing Emacs Lisp and Python source blocks to have a separate colors.
 @lisp
 (require 'color)
 (set-face-attribute 'org-block nil :background
 (color-darken-name
  (face-attribute 'default :background) 3))
 
-(defface org-block-emacs-lisp
-  '((t (:background "#EEE2FF")))
-  "Face for Emacs Lisp src blocks")
+(setq org-src-block-faces '(("emacs-lisp" (:background "#EEE2FF"))
+("python" "#e5ffb8")))
 @end lisp
 
 @node Exporting code blocks
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9342cb2..eda018f 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -374,7 +374,8 @@ Repeated footnotes are now numbered by referring to a label in the
 first footnote.
 *** The ~org-block~ face is inherited by ~src-blocks~
 This works also when =org-src-fontify-natively= is non-nil.  It is also
-possible to specify per-languages faces.  See the manual for details.
+possible to specify per-languages faces.  See =org-src-block-faces= and
+the manual for details.
 *** Links are now customizable
 Links can now have custom colors, tooltips, keymaps, display behavior,
 etc... Links are now centralized in ~org-link-parameters~.
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 18eae1b..9ff3b2d 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -395,11 +395,34 @@ follows a #+DATE:, #+AUTHOR: or #+EMAIL: keyword."
 
 (defface org-block '((t :inherit shadow))
   "Face text in #+begin ... #+end blocks.
-In addition to this face that take precedence for particular
-languages.  For instance, to change the block face for Emacs-Lisp
-blocks define a `org-block-emacs-lisp' face."
+For source-blocks `org-src-block-faces' takes precedence.
+See also `org-fontify-quote-and-verse-blocks'."
   :group 'org-faces
-  :version "22.1")
+  :version "25.2")
+
+(defcustom org-src-block-faces nil
+  "Alist of faces to be used for source-block.
+Each element is a cell of the format
+
+ (\"language\" FACE-OR-BACKGROUND)
+
+Where FACE-OR-BACKGROUND is either a face, an anonymous face, or
+a string corresponding to a background color.
+
+For instance, the following value would color the background of
+emacs-lisp source blocks and python source blocks in purple and
+green, respectability.
+
+'((\"emacs-lisp\" (:background \"#EEE2FF\"))
+  (\"python\" (:background \"#e5ffb8\"))) "
+  :group 'org-faces
+  :type '(repeat (list (string :tag "language")
+   (choice
+(color :tag "Background color")
+(face :tag "Face")
+(sexp :tag "Anonymous face"
+  :version "25.2"
+  :package-version '(Org . "9.0"))
 
 (defface org-block-begin-line '((t (:inherit org-meta-line)))
   "Face used for the line delimiting the begin of source blocks."
diff --git a/lisp/org-src.el b/lisp/org-src.el
index ab23b4a..f3b092e 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -513,9 +513,13 @@ as 

Re: [O] [RFC] Release Org 9.0 by the end of the next week?

[Rasmus]

Nicolas Goaziou  writes:

> Hello,
>
> Now that Emacs 25.1 is out, I'd like to have Org 9.0 become the new
> stable branch.
>
> Are there outstanding bugs left out? Is there and pending patch
> important enough to block the release?

Oh my, time is flying by.  I still have unfinished patches that I would
like to include, but I don’t I’ll let others decide if it’s worth
including now.

I have the following patches that I could realistically finish soon:

  - source blocks: new syntax for language specific faces
  - ox-html: move title to preamble for more control over layout/final output
  - ox-beamer: more keywords (needs to incorporate Nicolas’ feedback)
  - ox-publish: more flexible sitemap

Rasmus

-- 
Nothing's wrong with an email that ends in a minor key

Re: [O] Disable org-babel-inline-result-wrap per inline code?

[Eric S Fraga]

On Wednesday, 21 Sep 2016 at 06:07, David A. Gershman wrote:
> Given the following line:
>
> * Date: src_perl[:results output :exports none]{print 2016;}

How about 

* Date: src_perl[:results output raw]{print 2016;}

?

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa

[O] Capture Bug?

[lists]

I have a capture template which prompts for a file name and uses this to 
create a filename with a datestamp:


(defun capture-pelican-draft-file (path)
  (let ((name (read-string "Name: ")))
(expand-file-name (format "%s-%s.org"
  (format-time-string "%Y-%m-%d")
  name) path)))


("g"
   "New blog post (ianbarton.net)"
   plain
   (file (capture-pelican-draft-file  
"~/Documents/emacs/web_sites/ianbarton.net/org/_posts"))
   "#+AUTHOR: Ian Barton\n#+DATE: %u\n#+PROPERTY: MODIFIED: 
\n#+TITLE\n#+CATEGORY: Blog \n#+PROPERTY: TAGS \n#+PROPERTY: SUMMARY 
\n#+SETUPFILE: ../setup.org\n\n")



On the current git master the function capture-pelican-draft-file 
doesn't seem to be evaluated, resulting in a "File name doesn't exist" 
error. Doing git bisect seems to point at the commit below:


8860c92f62dac87267416708e81bc8aec026fcc7 is the first bad commit
commit 8860c92f62dac87267416708e81bc8aec026fcc7
Author: Nicolas Goaziou 
Date:   Fri Jun 24 00:55:03 2016 +0200

ob-exp: Small fix

* lisp/ob-exp.el (org-babel-exp-src-block): Use `symbol-name' 
instead of

  `eval' since the argument is a dynamically scoped variable anyhow.

Ian.

Re: [O] Something to watch out for when including files

[Eric S Fraga]

On Tuesday, 20 Sep 2016 at 23:32, Charles C. Berry wrote:
> I find myself in the habit of using inlinetasks tagged noexport for 
> various things and that might serve you in this case. That is, convert the 
> headline section to an inlinetask.

Hi Chuck,

Yes, this would work.  But, in the end, simply removing the section was
sufficient as it really wasn't necessary (and that's why I have
everything under version control... ;-).

> Another possibility is to use something like:
>
> #+header: :exports results :results raw replace
> #+NAME: import-include-dot-org
>
> #+BEGIN_SRC emacs-lisp
>(require 'ox-org)
>(org-export-string-as "#+INCLUDE: include.org" 'org t)
> #+END_SRC
>
> which will strip out headlines tagged with noexport during the babel phase 
> of export (i.e. before parsing).

This is quite ingenious!  I like it.  Don't need it now but worth
keeping note of for the future.  Thanks.

>> I do wonder whether the org export approach (i.e. how it "includes"
>> files) is correct but I can understand why the implementation is the way
>> it is.
>
> I agree about the implementation. Trying to make it smarter is asking for 
> trouble.

Yes, probably.

Thanks again,
eric


-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa

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] Capture with org-directory not working?

[Rainer Krug]

> On 20 Sep 2016, at 19:08, Adam Porter  wrote:
> 
> Rainer Krug  writes:
> 
>> Could you please provide an example? It is not clear to me what you mean - I 
>> prefer simpler!
> 
> Sure, here's an abbreviated example of custom-set-variables from my
> init.el:
> 
> #+BEGIN_SRC elisp
>  (custom-set-variables
>   ;; custom-set-variables was added by Custom.
>   ;; If you edit it by hand, you could mess it up, so be careful.
>   ;; Your init file should contain only one such instance.
>   ;; If there is more than one, they won't work right.
>   '(org-capture-templates
> (quote
>  (("a" "Appointment" entry
>(file+datetree+prompt
> (concat org-directory "/calendar.org")
> "Calendar")
>"* %^{Description} %T %^G
> 
>  %U %?" :clock-in t :clock-resume t)
> #+END_SRC
> 
> The downside is that, if you're editing them in your init file instead
> of through the customize interface, you have to eval the entire
> custom-set-variables to apply changes, which requires a few extra
> keystrokes.
> 
> 

Thanks - I see what you mean. But It seems to abusing the basic idea of 
custom-set-variables as this sounds as if it is used by the customise interface.

So it should be possible to set it using my initial approach?

Rainer


--
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982



signature.asc
Description: Message signed with OpenPGP using GPGMail

[O] Disable org-babel-inline-result-wrap per inline code?

[David A. Gershman]

Forgive my several questions/emails.  I'm working on getting lecture
notes ready for next week and thus am running into several questions
with Org HTML Export.  Unfortunately, my searches typically result in
manual page hits, but my problems seem to be a-typical.  So...

Given the following line:

* Date: src_perl[:results output :exports none]{print 2016;}

The result '2016' is surrounded by '=' so that HTML export results in
 tags surrounding
the '2016'. 

According to the manual section 14.5, 'org-babel-inline-result-wrap'
defines how the results are wrapped.  Executing a /(print
/org-babel-inline-result-wrap), I get:

{blank line}
=%s=
=%s=

so I attempted the following:

  * Date: src_emacs-lisp[:exports none]{(setq
org-babel-inline-result-wrap "")} src_perl[:results output :exports
none]{print 2016;} src_emacs-lisp[:exports none]{(setq
org-babel-inline-result-wrap "=%s=")}

in the hopes of temporarily disabling the '=' wrapping.  Sadly no luck.

I don't want to globally, or even for the whole buffer turn off the
'=%s='...just on a case-by-case basis.

Any ideas?

--dag

P.S.  In reality, 2016 will be replaced with a function call which takes
an integer and converts it to a full blown date based on a starting
point.  Thus, the headlines will result in "Date: September 20, 2016"
where each date is different based on the integer.  This will allow me
to set the starting date at the top of the .org file and all the
date-based headlines can be computed.