Re: Changed list indentation behavior: how to revert?

[T.F. Torrey]

Hello all,

I apologize in advance that this is so long.

I've been following this thread closely, because I've been using Org
mode daily for well over a decade, and this behavior affects me in
several important ways.  I think this summary might be helpful.

Forever, it has been possible to start a heading in Org by typing a
return one or more times, then typing an asterisk and a space and the
heading text.  To add a series of headings, just keep hitting return at
the end of the current one, type an asterisk and a space and the next
one, then repeat.  If you want subheadings, it is as simple as typing
more asterisks.  Easy.

This worked because electric-indent-mode defaulted to off, and although
org-adapt-indentation defaulted to t, it didn't affect this situation.

The default behavior here matters because Org is a killer feature of
Emacs, enticing many people to give it a try, including my nine-year-old
daughter.  For them, it should behave by default the way it looks like
it should.  That means, typing asterisks and text for headings, followed
by returns, and text, and more asterisks, should just work by default.

#+NAME: Old Defaults: electric-indent-mode OFF and org-adapt-indent t
#+begin_example org
,* Testing out Org, type  here once or twice

I get it!  I'll type  once or twice again and start a subheading.

,** Headings are easy!  Now another  or two for subhead content

This is awesome!  It works just as I expect, and I don't have to
memorize a bunch of key chords just to get started.  And folding is
awesome!  I love Org!  I will stick with it and learn it all!
#+end_example

I have probably typed close to a million headings like this all by
myself, and collectively we have probably typed billions or more.

The last release, as everyone knows, turned on electric-indent-mode by
default.  So, right now, typing an Org document with default settings
does not work like it looks like it should.  This is the new experience
for people used to the old defaults, and beginners like my daughter:

#+NAME: New Defaults: electric-indent-mode ON and org-adapt-indent t
#+begin_example org
,* I typed an asterisk for this heading, how about  here once or twice

  Okay.  This is indented.  Since I'm new, I don't realize it isn't
  useful yet, or that it makes a difference at all.  How about a
  subheading?  I'll hit  a couple times, they type two asterisks.

  ,** Is this a subheading? It looks like one.   again here ...

  Okay, the indentation isn't the same, but maybe it's okay?  I
  probably didn't even notice.

  ,*** I think I'm organizing my document with *'s and 's

  I'm going to try folding my stuff, becaue I saw that and it looks
  awesome.

  Wait!  The instructions say  will cycle the folding, but it
  only works on the top level.  What?

  Okay, some searching said I have to modify init, or something, or
  type some weird key combinations.  What?  This looked like it was
  going to be easy.  Nerds are liars.

  I can't figure this out, and I don't have time to mess with this.
  I'm going back to Word.  Maybe I'll try Markdown tomorrow.
#+end_example

For new users, step one is either to start changing default settings,
start learning key chords and/or arcane (to beginners) commands---or go
back to Word or Markdown.

Turning on electric-indent-mode, all by itself, shouldn't break the
useful or customary indentation that the users of Org expect, but it
has.  Instead of starting a new heading by typing  one or more
times, then typing an asterisk and a space and a new heading, a user
has to either hit some control characters with returns, or backspace to
column zero, or something else.

The manual shows heading and body formatting as this:

#+NAME: Org Manual Sample: electric-indent-mode on, org-adapt-indent t
#+begin_example org
,* Top level headline
,** Second level
,*** Third level
some text
,*** Third level
more text
,* Another top level headline
#+end_example

I don't recall ever seeing an Org document in real life with the body
indented at the level of each heading, and I haven't seen anyone argue
for that behavior on this thread.  I've tried it, and the text body
width rapidly becomes too narrow to be useful.  As several people have
noted, even the Org repositories turn this off, which suggests even
the developers don't find it useful.  Why this is set as the default,
I have no idea, but it didn't really matter until now.

An Org document looks like you can create it by typing asterisks,
text, and returns, but you can't, not by default, anyway.

That's the root of the problem: the longstanding default *behavior*
has been changed.  The only people unaffected are people who already
had compensatory settings in their init files.

As far as I can tell, turning on electric-indent-mode by default was
done for no reason other than other Emacs modes have it as a default.

The proper fix for this is one of two choices:

1. If keeping electric-indent-mode on is really important, the easiest
   way to 

[O] Error when applying table formula

[T.F. Torrey]

Hello,

I'm getting a weird error.  When I "make vanilla" from the current git
repo, I don't get the error, so I'm sure it's something I've done, but
I'm not sure what, and my customizations make tracking down the problem
complicated.  I know I can find out the source, but I'm hoping that
someone has an idea that can save me some time.

Then I type C-c C-c on a `#+TBLFM:` line, I get an error.

This weird message appears in the *Warnings* buffer:

Warning (emacs): There is no logger of name 268435455.

I also get this in the *Backtrace* buffer:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p t)
  byte-code("\301\302\303\245\304\"\303\245!\207" [most-positive-fixnum 
truncate log 2 10] 4)
  (defconst math-bignum-digit-length (byte-code 
"\301\302\303\245\304\"\303\245!\207" [most-positive-fixnum truncate log 2 10] 
4) ("/usr/share/emacs/24.5/lisp/calc/calc.elc" . 79936))
  calc-eval(("(8)-1" calc-internal-prec 12 calc-float-format (float 8) 
calc-angle-mode deg calc-prefer-frac nil calc-symbolic-mode nil 
calc-date-format ( "-" MM "-" DD " " Www (" " hh ":" mm)) 
calc-display-working-message t) nil)
  org-table-eval-formula(nil "$1-1" noalign nocst nostore noanalysis)
  org-table-recalculate(t)
  call-interactively(org-table-recalculate)
  org-table-calc-current-TBLFM()
  org-ctrl-c-ctrl-c(nil)
  call-interactively(org-ctrl-c-ctrl-c nil nil)
  command-execute(org-ctrl-c-ctrl-c)

Also, the error appears in all my files, but when I tried to run
org-lint to look for possible problems in a file that might have them,
it simply stops with this message:

Search failed: "^[  ]*#\\+[A-Za-z]+: +setup *$"

Does anyone have any idea what a likely culprit might be?

Emacs  : GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.18.2)
 of 2015-10-24 on x86-grnet-01, modified by Debian
Package: Org-mode version 8.3.3 (release_8.3.3-501-g15d591.dirty @ 
/home/tftorrey/T/hacks/org-mode/lisp/)

Thanks in advance,
Terry

[O] Bug: Column view next allowed value throws error

[T.F. Torrey]

Hello all,

With the most recent Org from git, attempting to change to the next or
previous allowed value in Column View throws an error: Symbol's value as
variable is void: pom

An ECM for the error:

Type =make vanilla= at the command prompt.

Change the scratch buffer to org-mode.

Erase the buffer and paste this instead (not including the #+...EXAMPLE
lines, of course:

#+BEGIN_EXAMPLE
,* Top node for columns view
  :PROPERTIES:
  :COLUMNS: %25ITEM %TAGS %PRIORITY %TODO
  :END:

,** TODO This

,** TODO That
#+END_EXAMPLE

Move the cursor to the second heading.

Press C-c C-x C-c to go to column view.

Move to the P column.

Press n to change the value to the next allowable value.

This error appears:

#+BEGIN_QUOTE
Symbol's value as variable is void: pom
#+END_QUOTE

Performing the same steps but starting with emacs -Q in Debian Testing
produces the expected results, no error.

Emacs : GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.18.2) of
 2015-10-24 on x86-grnet-01, modified by Debian

Package: Org-mode version 8.3.3 (release_8.3.3-470-g3142d1.dirty @
 /home/tftorrey/T/hacks/org-mode/lisp/)

Thanks in advance,
Terry

Re: [O] Bug: org-map-entries seems broken

[T.F. Torrey]

Hello,

Thank you so much for looking into this.

Kyle Meyer  writes:

>> Hello,
>>
>> I have a function that uses org-map-entries to build a list of entries.

[... 6 lines omitted ...]

>
> Things seem to be working on my end.  Both release_8.3.3 and the
> current master (23f31a9) are giving me the same results:

[... 36 lines omitted ...]

The problem, which took me several hours to figure out, was merely a
massive misfire between my keyboard and chair.  I apologize for the
noise.

Best,
Terry

[O] Bug: org-map-entries seems broken

[T.F. Torrey]

Hello,

I have a function that uses org-map-entries to build a list of entries.
It worked until recently.  Now, it fails with simple combinations.  For
instance, 'LEVEL=1' matches what it should, and 'weblog' matches what it
should, but 'LEVEL=1+weblog' does not match the intersecting set, or
anything at all.  Did I miss a change in the syntax, or maybe did a
recent refactoring introduce an error?  Does anyone else use this kind
of matching and have it work?

Emacs  : GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.18.2)
 of 2015-10-24 on x86-grnet-01, modified by Debian
Package: Org-mode version 8.3.3 (release_8.3.3-435-gb78a9b @ 
/home/tftorrey/T/hacks/org-mode/lisp/)

Thanks in advance,

Terry
-- 
T.F. Torrey

[O] Bug: Smart left single quote broken

[T.F. Torrey]

Hello all,

The smart quote code has gotten a little borked, at least in HTML.

This:

#+BEGIN_EXAMPLE
He said, "You should believe me, 'cause it's 'true'."
#+END_EXAMPLE

Exports to this:

#+BEGIN_EXAMPLE

He said, You should believe me, cause its
true.

#+END_EXAMPLE

The quote before "true" should be a left single quote, and it used to be,
like this:

#+BEGIN_EXAMPLE

He said, You should believe me, cause its
true.

#+END_EXAMPLE

I looked at the code, but it has become more convoluted than I can
figure out in the time allotted.  Hopefully the error is obvious to
someone more familiar with it.

Emacs : GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.16.4) of
 2015-06-28 on x86-csail-01, modified by Debian Package: Org-mode
 version 8.3.1 (release_8.3.1-190-g258966 @
 /home/tftorrey/T/org-mode/lisp/)

Best,
Terry
-- 
T.F. Torrey

Re: [O] Bug: Smart left single quote broken

[T.F. Torrey]

> I doubt it is possible to tell that 'cause begins with an apostrophe and 
> not an opening single quote without grammatical analysis. 
 
Indeed. I pointed it out because it was unexpectedly doing the right thing.

Thank you.

T.

Re: [O] Bug: HTML export ignoring CUSTOM_ID properties

[T.F. Torrey]

Hello Nicolas,

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

[... 77 lines omitted ...]

 I hope this clarifies the purpose of the change.

It does.  Thank you very much for taking the time.

[... 41 lines omitted ...]

 Are you still planning on throwing warnings or errors in the event of
 duplicate or invalid CUSTOM_ID's?

 I have implemented something related recently, but I'll comment about
 this in another thread.

I look forward to reading it.

Best,
Terry
-- 
T.F. Torrey

Re: [O] Bug: HTML export ignoring CUSTOM_ID properties

[T.F. Torrey]

Hello Rasmus,

Rasmus ras...@gmx.us writes:

 With the latest from Git master, the HTML export ignores CUSTOM_ID
 properties for subtrees.  I've seen list traffic that the names of the
 export ID's are being changed, but this is not intentional, right?

 It doesn't ignore it, but it is translate to a generic anchor as
 needed.

 Isn't translating it to a generic anchor the same as ignoring it?
 Without a CUSTOM_ID you get a generic anchor.  With a CUSTOM_ID you get
 a generic anchor.

 You click it and it still works.  It's not ignored.  Within the syntax it
 does the right thing.

 Because I know (knew) the id of the section about Clinton, I could link
 to my page from another document outside Org with a link to
 presidents.html#clinton.

 Presumably you could use presidents.org::#clinton still.

Links may work from inside Org, but the original intent of CUSTOM_ID was
to produce a stable ID for the HTML export that could be linked to from
outside Org.  With the changed functionality, all existing links to
presidents.html#clinton are broken, because the usage of CUSTOM_ID has
changed.  Any custom CSS is also broken, for the same reason.

With the new usage, CUSTOM_ID and ID have virtually the same
functionality.

 Notice how my CUSTOM_ID's are no longer ID's at all.  And simply adding
 text- to my CUSTOM_ID's is not an answer.  For one thing, CUSTOM_ID
 exports should not change on the breeze of developer whims.  For
 another, the ID should be attached to the heading, not the body of the
 text; otherwise, a person following the link would have no idea if it
 went to the Clinton section or not.

 Note that this also breaks any CSS styling for the section with the
 CUSTOM_ID (which I also use).  If I used a CUSTOM_ID because wanted a
 swanky background for the heading saying Bill Clinton, the current
 export not only doesn't use that ID, it doesn't encompass the heading
 with his name in.

 I have a half-baked patch that restores the old behavior, but I have to
 think a bit more about it, and I won't have time today.  Nicolas might
 also see it in the coming days.  E.g. ox-latex has org-latex--label.  The
 question is whether there should be a solution in ox or whether each
 backend should have org-BACKEND--label.

As the current state is unusable, there would be no additional harm in
applying your half-baked patch.

 Thus, I think it is a bug, unless there is a better way to allow
 per-section css. I will look at this later unless somebody beets me to it.

 Given the lack of outcry, I may be the only one using CUSTOM_ID's for
 HTML export.  However, if usage is widespread enough and accidental
 duplicates are a problem enough that this needs to be addressed,
 wouldn't it be better for the exporter to simply report duplicate ID's
 as they are found?

 It was changed this week.

Either no one is using it according to its original intended
functionality, no one has republished their HTML documents with the
latest from git, or people have simply not noticed that their links are
broken.

 Finally, given that this doesn't appear to work at all in any form of
 its intended usage, how did this even get committed to master?  Sure,
 code in master may have bugs, but this is more than a bug; this is
 unusable code that breaks code that worked.  Shouldn't it be developed
 on a feature branch or in someone's private repo until it actually
 works?

 Master is where we develop things.

The code on master is *supposed* to work as advertised.  It identifies
itself as 8.3 beta.  Changes that break functionality in exploratory
ways are alpha changes.

 Nicolas made the change and he's off this week.  Feel free to use Org
 8.2.

Ha ha.  There are many tools capable of exporting plain-text documents
to HTML with predictable and stable ID's.  If Org 8.3 is not going to be
one of them, using Org 8.2 is not a solution.

 Unless there is a quick fix that restores external (non-Org-generated)
 links to sections with CUSTOM_ID's, please revert these changes until
 the development reaches a usable state.

 Won't happen.

As you said, they aren't your changes and it isn't your decision.

Best,
Terry
-- 
T.F. Torrey

Re: [O] Bug: HTML export ignoring CUSTOM_ID properties

[T.F. Torrey]

Hello Aaron,

Aaron Ecay aarone...@gmail.com writes:

 You wrote:

 Links may work from inside Org, but the original intent of CUSTOM_ID was
 to produce a stable ID for the HTML export that could be linked to from
 outside Org.

 I think this is true.  Looking at the pages in Worg, for example,
 provides ample evidence of this strategy in action.

If this functionality were not provided by CUSTOM_ID, we would need to
invent a different property to serve the function.

 CUSTOM_ID is also sometimes needed for latex export
 (cf. org-latex-prefer-user-labels).  It is important for IDs to be
 unique, and to conform to certain format restrictions.  What if
 CUSTOM_ID properties were checked for these requirements when exporting,
 raising an error if they are not suitable and otherwise passing through
 to the export output?  This would maintain CUSTOM_ID as an interface to
 labeling systems outside org (latex \ref{}, html #anchor links, ...),
 but would also make export more robust.  It’s also in line with recent
 changes to raise export errors for undefined macros, unresolvable links,
 etc.

This is what I suggested in an earlier e-mail (which was unreasonably
cordial, yet summarily dismissed in a way that made me angry, and which
was sent in response to the summary dismissal of my polite bug report).

Does it warrant an error, though?  I've been using the functionality
extensively for years, and I can remember only one time that I had an
inadvertent problem caused by a duplicate CUSTOM_ID.  A simple warning
would have headed that off.

On the contrary, if the show is going to
stop with an error, I will have to make sure my documents meet someone
else's idea of what is useful.  For instance, many of my documents get
exported together (web pages with #news sections, for instance), and it
would be unnecessarily inconvenient making the CUSTOM_ID unique across
all agenda files.  Someone else, however, might want that.

I'm wondering why this is being addressed at all.  Is this actually a
problem for someone?  Or is this just another attempt to save
hypothetical users' feet?  Or is it just a side-effect of other
refactoring?

Best,
Terry
-- 
T.F. Torrey

Re: [O] Bug: HTML export ignoring CUSTOM_ID properties

[T.F. Torrey]

Hello Nicolas,

First, thank you for your incredible work on Org.  I hope you enjoyed
your days off, but I have to admit that your announcement that you were
taking the week off worried me.  I seem to remember we lost Carsten and
Bastien soon after they took a week off.  When (if?) you finally get
burned out and leave, all Org users will feel the loss.

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 beta is indeed misleading. I suggest to ignore it.

 As Rasmus pointed out, master is where development happens. Some changes
 introduced here may break Org. If one such change makes Org unusable for
 you, you can easily revert Org to an earlier, working, commit, without
 fuss. Of course, we appreciate if you report the problem encountered
 beforehand.

Yes, changes on master can and do occasionally break Org, but they are
*supposed* to work.  You wouldn't leave the spreadsheet functionality in
an unusable state and just tell people to use 8.2.

But yes, it should be a simple matter to revert the commit that caused
the problem for me until the problem can be addressed.  That was the
second thing I looked at.  However, the place where this change happened
is not obvious in the git logs.  I still don't know where it came from.

I did see that most (maybe all) of your changes are accompanied by
tests.  I'm not very familiar with the testing.  Are the tests
restricted to merely checking if the code explodes?  Or is there a
possibility to test whether the code does what it is supposed to do?
Presumably this change that broke functionality passed its tests just
fine.

 Ha ha.  There are many tools capable of exporting plain-text documents
 to HTML with predictable and stable ID's.

 Considering that not any string is eligible as HTML id (e.g., forbidden
 characters), either these tools are putting restrictions on chosen IDs
 or they are lying.

They aren't lying because they don't claim to allow only valid ID's.
They produce valid ID's on their own, but when a user calls for a
specific ID (the {#clinton} construct in Markdown comes to mind), they
just do what the user tells them to do.  Which is a good thing.

I sense there is a difference of philosophy at play here.

In my view, the purpose of tools such as Org that convert documents to
HTML is to do what the user tells them to do, even if that means
creating invalid HTML.  On many occasions in the past, and probably some
in the present and the future, I have used conversion tools to produce
technically invalid HTML as in intermediate format to be further
processed by XSLT to a final product.  A tool that refused to produce
invalid HTML would be no help at all.  In fact, I'm not aware of any
tool that disallows that except maybe for some beginner level things.

On the contrary, the slant of Org's development lately seems to be first
to make sure users don't make any mistakes, and then to follow their
instructions.

 As you said, they aren't your changes and it isn't your decision.

 I overlooked the problem in HTML and made a mistake. It happens, more
 often than I would like. However, you are not required to be obnoxious
 about it. It helps no one.

Your mistakes are very rare, and your work is sincerely appreciated.  I
think your comment about my response is out of context, and I'm not sure
your final statement is true.  My polite comments were summarily
dismissed, but now anyone who depended on CUSTOM_ID has been helped.

 The problem should be fixed in 0449b785b4b58ec16e1aac126634de70eee519a4.
 Thank you for reporting it.

Thank you for your prompt action, but can I ask what you mean by
fixed?  Have you decided to revert CUSTOM_ID to its previous
functionality?  Are you still planning on changing its functionality
and/or meaning?  Are you still planning on throwing warnings or errors in
the event of duplicate or invalid CUSTOM_ID's?

Best,
Terry
-- 
T.F. Torrey

Re: [O] Bug: HTML export ignoring CUSTOM_ID properties

[T.F. Torrey]

Hi Rasmus,

As someone with all my personal and work files in Org, I sincerely
appreciate all the work you do to improve Org.  But...

Rasmus ras...@gmx.us writes:

 With the latest from Git master, the HTML export ignores CUSTOM_ID
 properties for subtrees.  I've seen list traffic that the names of the
 export ID's are being changed, but this is not intentional, right?

 It doesn't ignore it, but it is translate to a generic anchor as
 needed.

Isn't translating it to a generic anchor the same as ignoring it?
Without a CUSTOM_ID you get a generic anchor.  With a CUSTOM_ID you get
a generic anchor.

 Previously, both a generic anchor and the custom_id would be inserted in
 html.  E.g. for a headline with id h1:

 h2 id=h1a id=sec-1 name=sec-1/a

Yes, that was a little clunky, but it did work, and the name attributes
could be suppressed.

 The problem is that we don't know that h1 is unique.

 However, in html custom_id serves as an important measure to facilitate
 css customization, e.g. on a section level-basis.

Yes, the user was responsible for making sure CUSTOM_ID's were unique,
but in practice that never amounted to what could be described as the
problem.

However, CUSTOM_ID's are not just CSS targets, they are link targets.

Consider this typical usage:

I have a page of my favorite presidents:

#+BEGIN_SRC org
* Favorite Presidents

** George Washington
:PROPERTIES:
:CUSTOM_ID: washington
:END:

He was tall.

** Bill Clinton
:PROPERTIES:
:CUSTOM_ID: clinton
:END:

He liked the ladies.
#+END_SRC

Because I know (knew) the id of the section about Clinton, I could link
to my page from another document outside Org with a link to
presidents.html#clinton.

This is how all the links between documents are done on my website, and
it's mostly how internal links in the HTML that becomes e-books is done.

However, with the new export code, many, perhaps all, of my links are
broken, because what comes out of the HTML exporter is this:

#+BEGIN_HTML
div id=outline-container-sec:4 class=outline-2
h2 id=sec:4span class=section-number-21/span Favorite Presidents/h2
div class=outline-text-2 id=text-1
/divdiv id=outline-container-sec:1 class=outline-3
h3 id=sec:1span class=section-number-31.1/span George Washington/h3
div class=outline-text-3 id=text-washington
p
He was tall.
/p
/div
/div

div id=outline-container-sec:2 class=outline-3
h3 id=sec:2span class=section-number-31.2/span Bill Clinton/h3
div class=outline-text-3 id=text-clinton
p
He liked the ladies.
/p
/div
/div
#+END_HTML

Notice how my CUSTOM_ID's are no longer ID's at all.  And simply adding
text- to my CUSTOM_ID's is not an answer.  For one thing, CUSTOM_ID
exports should not change on the breeze of developer whims.  For
another, the ID should be attached to the heading, not the body of the
text; otherwise, a person following the link would have no idea if it
went to the Clinton section or not.

Note that this also breaks any CSS styling for the section with the
CUSTOM_ID (which I also use).  If I used a CUSTOM_ID because wanted a
swanky background for the heading saying Bill Clinton, the current
export not only doesn't use that ID, it doesn't encompass the heading
with his name in.

 Thus, I think it is a bug, unless there is a better way to allow
 per-section css. I will look at this later unless somebody beets me to it.

Given the lack of outcry, I may be the only one using CUSTOM_ID's for
HTML export.  However, if usage is widespread enough and accidental
duplicates are a problem enough that this needs to be addressed,
wouldn't it be better for the exporter to simply report duplicate ID's
as they are found?

Finally, given that this doesn't appear to work at all in any form of
its intended usage, how did this even get committed to master?  Sure,
code in master may have bugs, but this is more than a bug; this is
unusable code that breaks code that worked.  Shouldn't it be developed
on a feature branch or in someone's private repo until it actually
works?

Unless there is a quick fix that restores external (non-Org-generated)
links to sections with CUSTOM_ID's, please revert these changes until
the development reaches a usable state.

All the best,
Terry
-- 
T.F. Torrey

[O] Bug: HTML export ignoring CUSTOM_ID properties

[T.F. Torrey]

Hello list,

With the latest from Git master, the HTML export ignores CUSTOM_ID
properties for subtrees.  I've seen list traffic that the names of the
export ID's are being changed, but this is not intentional, right?

Emacs : GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.5) of
 2015-03-07 on binet, modified by Debian Package: Org-mode version
 8.3beta (release_8.3beta-1045-gd8494b @
 /home/tftorrey/T/org-mode/lisp/)

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello Aaron,

Aaron Ecay aarone...@gmail.com writes:

 Hi Terry,

 2015ko martxoak 10an, T.F. Torrey-ek idatzi zuen:

 Of the things in your list, I think only the NEWS and Changelog are
 absent from the master branch in git.  Lots of us happily use Org master
 from git without them every day.  Do they really need to be done at
 all?

 Many people are very happy not using org at all.  Perhaps we should just
 all quit and find other hobbies.  OTOH, release milestones are important
 to the health of a software project and so yes, really need to be done.

You seem to be arguing with a point I wasn't making.  Release milestones
are fine, but the current plan for doing them is too much work for the
people involved.  Couldn't a simpler way work?

 If Emacs 25 is taking Org out of core, does the code still have to be
 merged into the trunk?

 This is not on the table.  Rather, the (tentative) proposal from the
 emacs side is for some packages to be developed in the GNU ELPA
 repository, and be extracted from there and bundled with emacs release
 tarballs (in addition to being released in ELPA).

 Org is sometimes cited as an example of a package that would benefit from
 this strategy, but there has been no discussion of this from the org
 side, and AFAIK no decision has been made whether we’d take advantage of
 this facility if/when it’s available.

Interesting.

 Exposing new users to the vagaries of the master branch may rather lead
 to atheism.

This sounds like the foot-shooting argument again.  Could one not just
as easily harm one's foot with the master version from git?  Or is the
assumption that only git users are smart enough to wield the power?
Maybe Org is so powerful that it should not be released via by ELPA at
all, for the sake of everyone's appendages.

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

emac...@gmail.com (Richard Y. Kim) writes:

 tftor...@tftorrey.com (T.F. Torrey) writes:

 I wonder how much effort it would take to copy onto my own machine the
 scripts on the server that package the git maint version into an ELPA
 version, and modify them to package master instead.  Probably not much.

 The shell script below is what I use to create my own org-plus-contrib
 ELPA package.

 Rather than relying on elpa.gnu.org, melpa.org, orgmode.org/elpa, etc.,
 I've been creating my own packages over the past year or so.  This way I
 know exactly which packages are installed in not only my emacs, but my
 colleagues who use my packages.  So far this has worked out great for
 me.

Looks excellent.  Thank you!

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Achim Gratz strom...@nexgo.de writes:

 Richard Y. Kim writes:
 # server.mk has the elpaplus makefile target
 echo  include mk/server.mk  Makefile
 […]
 # Undo the change made above
 git checkout Makefile

 You know, local.mk was introduced specifically so you wouldn't have to
 do anything like that.

I did know that.  I remember the massive overhaul of the makefile
system (which, IIRC, you masterminded).

Unfortunately, I am not a makefile guru, so merely knowing that is not
enough.

I wish I had fewer dirty hacks in my life, but I'd rather get something
done with a dirty hack than not get it done at all.

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello Aaron,

Aaron Ecay aarone...@gmail.com writes:

 If the goal is to have the latest and greatest version of Org available via
 ELPA (for all the reasons some people use ELPA instead of git), there
 are two obvious options:

 1. Org could have a stable release every month or so.

 2. The Org server could be configured to automatically package the
 master version of Org every day, as the maint version is now.

 Option 1 is widely regarded as the best choice.  However, it requires a
 lot of actual, repeated human effort.  As Debian repeatedly
 demonstrates, this is very hard to do, even once.  If option 1 could be
 done, it would already be done.

 Option 2 would be a one-time (mostly) human effort, and the daily work
 would be automated.

 But what would not be automated is the actual human effort that goes into
 making a release: writing NEWS and documentation for new features, testing
 for regressions, generating the emacs Changelog files, merging changes
 from emacs trunk back into to org code base, merging org code into emacs
 trunk, ...  Someone still has to do all those things eventually.  Or not,
 and the quality of org as a software product suffers.

Refusing to make the git master version available through ELPA doesn't
help any of those things get done.  It simply denies the latest Org to
those unable or afraid of using git.

Of the things in your list, I think only the NEWS and Changelog are
absent from the master branch in git.  Lots of us happily use Org master
from git without them every day.  Do they really need to be done at
all?

If Emacs 25 is taking Org out of core, does the code still have to be
merged into the trunk?

If the manpower does not exist to support both a maint and a master
branch, maybe they should be merged.  Could that be done?

Still just trying to make it easier to spread the gospel of Org,
Terry
-- 
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello,

Sebastien Vauban sva-n...@mygooglest.com writes:

 As Grant pointed out, it’s a lot more convenient working inside Emacs
 for switching between versions and such.

 How do you switch between versions in ELPA?  IIUC, you only get the
 latest version, and if that one is not right, you're kind of stuck: you
 can't reinstall the previous version via the interface. Or maybe I have
 to learn something new?

Only one version per package name is allowed, so with everything in one
archive it won't currently work.

However, with smaller archives each holding one version, it becomes
possible.

For instance, to get the latest package of the main version of Org,
enable the Orgmode.org/elpa archive.  To go back to the slightly older,
perhaps more stable version in the GNU archive, remove the
Orgmode.org/elpa archive from your archive configuration, uninstall Org,
then reinstall it, and you will get the version from the GNU archive,
which will now be the latest one the packages system can find.

It's kind of a hack, sure, but until the package system is upgraded to
handle dependence on multiple versions of the same package, it works.
It would probably be inconvenient to do this for every package, but I
don't mind doing it for major packages like Org.

HTH,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Achim Gratz strom...@nexgo.de writes:

 The version of package manager that people most likely use today always
 choses the latest version from _any_ archive available when you update.
 You can't tell it to consider some archive more authoritative than
 another or that it should stick with whatever source archive the package
 was originally installed from.

Of course.  My explanation was worded poorly, because instead of
sleeping I was wasting my time supporting someone else's request to be
able to get the latest version of Org via ELPA.

 The current daily builds are here:
 […]

 That sort of contorsionist gymnastics defeats the whole point of having
 a package manager in the first place.  If every package would have to do
 that we'd all end up juggling dozens of archives in our config files.

The guidance for using Org via ELPA is already to add the
Orgmode.org/elpa archive (paraphrased).  Changing that to add
Orgmode.org/elpa-stable for the stable version or
Orgmode.org/elpa-unstable for the bleeding edge version is suddenly
contortionist gymnastics?  Really?  Compared to using git?

 If the next version of Emacs breaks Org out of core into the GNU ELPA
 package archive, things can be even easier:  Keep the stable version in
 the GNU package archive, and keep the unstable version in the archive on
 the orgmode.org server.

 I wouldn't hold my breath.  At the moment that mechanism by which to do
 that is certainly not in place and there's no agreement on what it
 should look like.

Agreement or not, something will be done.  Already the mechanisms are in
place that put the maint version in both locations.  The biggest
obstacle I to this that I see is that developers tend to hate the
package manager and love git.

 (And personally, I think the contrib parts should either be merged
 into the core or split into separate packages, but that's another can of
 worms.)

 if you want to move things into core, clean those files up, create tests
 and get the copyrights assignmed to the FSF by their authors and propose
 their inclusion.

 If you want separate packages, I'm quite certain that this needs further
 modifications at least to some of the files.  The current mode of
 operation is that they should be compiled together with the rest of Org
 and no checks are made if they work if installed sepaerately.  Some of
 them likely do, others probably not.

Yes, either choice would be an effort.

However, there is currently the problem that some packages depend on
org, and others on org-plus-contrib, which cause both to be installed
(without some controtionist gymnastics).  IMHO, the Org package at
Orgmode.org/elpa should either always include contrib, as the git
repository does, or split the contrib part into an org-contrib package
that depends on org.

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello again,

Rasmus ras...@gmx.us writes:

 I want to collaborate on Org files with my wife and parents,
 ^^^
 
 Do you?  It sounds cool!

It's complicated.

I've convinced my parents to begin writing memoir-type books, and my
wife works in non-profit, where good books are always good solutions.  I
push them toward using plain text files for the benefits we all know,
and because I can turn the files into epub books, Kindle books, and PDF
print books using my custom Org export code.

I would love to introduce them to the awesomeness of Org.  I think they
could work in Emacs, and I'm sure they could handle updating things via
ELPA, but I'm also pretty sure that the sight of git would send them
screaming all the way back to Microsoft Word.

At the same time, I don't want to use or write my custom code for an old
version of Org, and the files produced by the maint and master versions
of Org are slightly incompatible.

So.  The current process is for them to use Markdown formatting in their
plain-text files.  At least these can be converted with a quick script
(and Calibre's ebook-convert) to epub, Kindle, and pdf versions.  These
are okay, but not great.  For final versions, I will need to convert
the Markdown down Org using Pandoc, then do the pretty exports using my
Manuscript package.  This is not a solution.  This is a labor-intensive,
error-prone hack.

I would so much prefer to get them into Emacs and Org.  And I could, if
the master version was availble through ELPA.

 In a real-world situation, I want to collaborate on Org files with my
 wife and parents, and I want to use the current best version of Org
 (which has significant improvements to #+INCLUDE that I use), but I do
 not want to try to install git on their Windows machines,

 I agree.  I have the same problem when I build documents (via CI) on a
 remote Debian server where I don't want to mess around with anything more
 than what comes with Emacs by default.

This is another great use-case for an ELPA version of the git master.

 Serious Org users are already forced to install and run git to use the
 master version, and whatever the dangers, the practice is almost
 completely without problems.  A bleeding edge ELPA would merely make
 that simpler.

 I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
 of other packages will move to GNU ELPA and thus separate release channels
 (these packages will still be bundled with Emacs).  This means we can push
 out new versions easily, making more frequent releases more attractive.
 Again, if you want to help out with preparing releases just let the list
 and Bastien now.

I'm looking forward to this new arrangement (though it will be
interesting when, AFAIK, Gnus still doesn't have a workflow through
ELPA).  However, I don't see how this will make it easier to push out
new stable releases.  That still has the inherent problem that making
something called a stable version takes a lot of human effort.

I wonder how much effort it would take to copy onto my own machine the
scripts on the server that package the git maint version into an ELPA
version, and modify them to package master instead.  Probably not much.
I could host that on my own server, or maybe upload it to Melpa.  I
think I will look into that.

All the best,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello again,

Achim Gratz strom...@nexgo.de writes:

 Rasmus writes:
 I agree.  I have the same problem when I build documents (via CI) on a
 remote Debian server where I don't want to mess around with anything more
 than what comes with Emacs by default.

 You can use a tarball and the support for manual builds, described in:
 http://orgmode.org/worg/dev/org-build-system.html#sec-7

I think there is even an existing way to automate the whole process,
isn't there?  Org is awesome.

But still, we were looking for an ELPA solution, not just a different
workaround.

 I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
 of other packages will move to GNU ELPA and thus separate release channels
 (these packages will still be bundled with Emacs).  This means we can push
 out new versions easily, making more frequent releases more
 attractive.

 None of this is going to lift one core limitation of package manager:
 there can be only one.  It doesn't support packages that subsume other
 packages, so org-whatever is totally different from org and would be
 installed together when referenced by dependencies even though it makes
 no sense.

I wrote in my other e-mail that the limit is one per archive, but I
don't think that's technically true.  I think you can actually have as
many as you want, even from the same archive, but only the one with the
newest date (actually, greatest file name) will be installed.

So, to make all the packages that depend on Org use the unstable version
rather than the stable version, add-to-list 'package-archives the
unstable archive rather than the stable archive.

And if you want to keep have both the GNU archive and the Orgmode.org
archive in your package-archives, and you want to have the unstable
version from Orgmode.org installed instead of the stable version from
the GNU archive, no problem:  The one in the GNU archive has an older
date because the unstable one on the Orgmode.org server gets updates
every day, and thus the package manager will select that one to install.

IIUC,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello,

Rasmus ras...@gmx.us writes:

 As I think somebody said, the correct fix to this problem is more
 frequent released.  I'm sure Bastien would appreciate help with this.
 Do you want to volunteer?

If the goal is to have the latest and greatest version of Org available via
ELPA (for all the reasons some people use ELPA instead of git), there
are two obvious options:

1. Org could have a stable release every month or so.

2. The Org server could be configured to automatically package the
master version of Org every day, as the maint version is now.

Option 1 is widely regarded as the best choice.  However, it requires a
lot of actual, repeated human effort.  As Debian repeatedly
demonstrates, this is very hard to do, even once.  If option 1 could be
done, it would already be done.

Option 2 would be a one-time (mostly) human effort, and the daily work
would be automated.

So, if the goal is to have the latest and greates version of Org
available via ELPA (and it should be), option 2 is the only one that is
possible in the real world, so that's the one we should set up.

All the best,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello,

Achim Gratz strom...@nexgo.de writes:

 It doesn't get any easier than it already is.  Having both a stable and
 an unstable version of Org avilable via ELPA is a non-starter for the
 simple reason that the package manager can't deal with the versioning
 problems this would introduce.

I think this is not only not a non-starter, I think it is very easy
with the existing package manager.

The package manager can only handle one version of a package *per
archive*, so instead use one archive per version.

The current daily builds are here:

http://orgmode.org/elpa/

To allow choosing between stable (maint) and unstable (master), put the
package archives here instead:

Stable: http://orgmode.org/elpa-stable/

Unstable: http://orgmode.org/elpa-unstable/

Then, just add-to-list 'package-archives whichever flavor you want.

(And actually, to do away with the current conflict between the org and
org-plus-contrib packages, each of those should be in a separate
archive as well.)

If the next version of Emacs breaks Org out of core into the GNU ELPA
package archive, things can be even easier:  Keep the stable version in
the GNU package archive, and keep the unstable version in the archive on
the orgmode.org server.

(And personally, I think the contrib parts should either be merged
into the core or split into separate packages, but that's another can of
worms.)

All the best,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

A major benefit of an ELPA version of the bleeding edge version of
Org is that it enables those of us who run Emacs and Org on machines
where we can not install git (or just do not want to) to have the latest
version of Org nonetheless.

In a real-world situation, I want to collaborate on Org files with my
wife and parents, and I want to use the current best version of Org
(which has significant improvements to #+INCLUDE that I use), but I do
not want to try to install git on their Windows machines, and I do not
want to scare them off by introducing the world of Git in addition to
Emacs.  And it's not limited to #+INCLUDE.  I've been using Org for many
years, and no matter how good a release of Org has been, the version in
maint has followed right behind with new killer features.  Having that
version in Elpa makes it easier for me to share the awesome.

Aaron Ecay aarone...@gmail.com writes:

 IMO this is a bad idea.  The bleeding edge version is expected to be
 somewhat unstable, and exposing it via ELPA will lead to foot-shooting
 incidents.

I understand this concern in principle, but it is difficult for me to
imagine how it would be validated in actual usage.

Serious Org users are already forced to install and run git to use the
master version, and whatever the dangers, the practice is almost
completely without problems.  A bleeding edge ELPA would merely make
that simpler.

I regularly use both the git master version of Org and the ELPA version
of Org, and I do extensive elisp coding that interacts with both, and I
do not remember a problem that could be described as foot-shooting.

Any significant problems in a bleeding edge version would be resolved
the same way they are in the master version of git, only with the
solution packaged, delivered, and installed by the next day, except
automatically.

It is easy to imagine someone else unofficially packaging the bleeding
edge version and making it available via ELPA, and hard to imagine that
resulting in significant problems.  Melpa is loaded with bleeding edge
versions, but the problems I hear or see from it are very rare.

Also, as noted before, if someone is unhappy with the bleeding edge
version, switching back would be easy.

 On the other hand, it would be nice to have more regular releases from
 master to maint.  AFAIK the last one was a year and a half ago (Org
 8.2).  However, this has traditionally required a lot of effort from
 Bastien and others, so it’s not a simple case of “wishing will make it
 so”.

Very true, and no doubt there are benefits to having a stable version
 available.

However, not providing the bleeding edge version on ELPA is not
without cost.  The mailing list is littered with responses from Nicolas
saying that problem has been fixed in the master version 

One last thought: I think it would be better to name the versions
stable and unstable, to match the meanings established by Debian.

All the best,
Terry
--
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Nikolai Weibull n...@disu.se writes:

 Would it be of interest to anyone else if the bleeding edge version
 was available via elpa?

I would also very much appreciate it.

Terry
--
T.F. Torrey

[O] Bug: nil in HTML export output

[T.F. Torrey]

Hello,

With the latest code from the git repo, the HTML export of items having
drawers but no top-level content puts a stray nil in the
outline-text- div.

Minimal document to show bug:

#+BEGIN_SRC org
,* Item without drawers does not make nil

,* Item with drawer and top-level content does not make nil
  :PROPERTIES:
  :CUSTOM_ID: item_1
  :END:

Here is top-level content.

,* Item with drawer but no top-level content makes nil
  :PROPERTIES:
  :CUSTOM_ID: item_1
  :END:

#+END_SRC

Reproduced starting Emacs with emacs -q, loading Org from the latest pull from 
git,
then exporting the test document using the export dispatcher.

Snipped output:

#+BEGIN_SRC html
div id=outline-container-sec-1 class=outline-2
h2 id=sec-1span class=section-number-21/span Item without drawers 
does not make nil/h2
/div

div id=outline-container-item_1 class=outline-2
h2 id=item_1a id=sec-2/aspan class=section-number-22/span Item 
with property drawer and top-level content does not make nil/h2
div class=outline-text-2 id=text-item_1
p
Here is top-level content.
/p
/div
/div

div id=outline-container-item_1 class=outline-2
h2 id=item_1a id=sec-3/aspan class=section-number-23/span Item 
with property drawer but no top-level content makes nil/h2
div class=outline-text-2 id=text-item_1
nil/div
/div
#+END_SRC

Emacs  : GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2014-12-19 on brahms, modified by Debian
Package: Org-mode version 8.3beta (release_8.3beta-764-ga1f540 @ 
/home/tftorrey/T/org-mode/lisp/)

I haven't chased down the cause yet.

Terry
--
T.F. Torrey

Re: [O] New maintainer

[T.F. Torrey]

Thank you for your hard work, Bastien. You've done a fantastic job
under unusually adversarial conditions.

On Thu, Apr 18, 2013 at 9:53 AM, Bastien b...@gnu.org wrote:
 Dear all,

 I'm stepping down as the Org maintainer.

 Carsten accepted to step up, if the community agrees.
 Please raise your thumbs up or your concerns, if any.

 I'm glad I had this opportunity to work as Robin and
 I'm even more glad Batman may strike back!

 :)

 --
  Bastien

[O] [Bug] HTML Exporter Does Not Convert \\ To br /

[T.F. Torrey]

The old exporter would convert \\ at the end of a line to br / to
force a line break. The manual still says that \\ will force a line
break, but the new HTML exporter, while indeed breaking the line
there, does not insert the br / to make it render as a new line.

This is using the latest version from Git.

I think this is a bug, not a limitation of the new exporter.

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] [Bug] HTML Exporter Does Not Convert \\ To br /

[T.F. Torrey]

On Sun, Apr 21, 2013 at 4:02 AM, Eric Abrahamsen
e...@ericabrahamsen.net wrote:
 Hi Terry,

 I just tried with emacs -Q (I'm on 24.3.1) and git Org mode, and the \\
 is exported as br/. Can you check with emacs -Q? If you look in
 ox-html.el, you'll see that the function `org-html-line-break' should
 produce a br/\n.

 Could something else be going wrong?

Thanks for the verification. Indeed, it does work with emacs -Q, and
even with a simple restart of Emacs. Sorry for the noise. -- T.

Re: [O] (no subject)

[T.F. Torrey]

Thank you for your thoughtful reply. -- T.

Bastien b...@altern.org writes:

 Hi Terry,

 I hear you.  I completely agree that Org should not be less flexible
 than it has been so far.  At least not for very good reasons, shared
 by both the developers and the users.  IOW: ease of maintainance and
 code consistency should not let us introduce rigidity for the users.

 Let's focus on the regressions and let's try to fix the ones that we
 can fix.

 As discussions have shown so far, Nicolas holds the keys when it comes
 to honoring Org's consistency regarding its syntax -- the document he
 wrote will help us all to speak about the same syntax and rules.  But
 as you may have felt, I'm more on the user conveniency side, even if
 we need to sacrifice some consistency.  There is a balance here, and I
 hope we keep a good one.

 So as I said: let's focus on what you perceive as regressions wrt what
 Org allows.

 The subject of this thread does not fall in this category: headlines
 have always been starting with stars, there is no regression here.  On
 the contrary: a few years ago, we had no answer to this FAQ, now we
 can help users with several solution when the problem is aesthetic.

 Finally, I agree with Suvayu that the problem *is* mostly aesthetic,
 so the solutions we provide are enough (i.e., the FAQ, org-bullets.el
 in contrib/.)  The question is rather whether we should have an Org
 option in core to allow users to tweak the appearance of the stars:
 my answer here is no, because I don't see why users would stop here.
 Once we offer such an option for headlines, why not for comments and
 other characters with a syntactic role?  (I replied a question on
 stackoverflow on how to use % instead of # for comments...)

 Anyway -- Org still stands on the side of users' freedom, let's
 fix the real regressions.

 Thanks!

Re: [O] ox-html.el removal

[T.F. Torrey]

Jambunathan K kjambunat...@gmail.com writes:

 Meanwhile, someone should fix up the FSF assignment notice on those
 files.  As far as I am concerned, it is a routine housekeeping thing and
 hasn't taken effect.  I am not assigning any copyright to FSF.

Section 1a of the copyright assignment agreement is very specific:

#+BEGIN_QUOTE:
  1.(a) Developer hereby agrees to assign and does hereby assign to FSF
Developer's copyright in changes and/or enhancements to the suite of
programs known as EMACS (herein called the Program), including any
accompanying documentation files and supporting files as well as the
actual program code. These changes and/or enhancements are herein called
the Works.
#+END_QUOTE:

As a signed contributor, you have already assigned copyright of your
changes and/or enhancements to Emacs to the FSF (and therefore to this
community).  The agreement does not limit the assignment to those that
land in an Emacs release, or those you don't change your mind about, or
anything like that.  Any changes and/or enhancements to Emacs became
property of the FSF from the moment you wrote them.

Because you are not the copyright holder, it isn't even your prerogative
to decide which license the code is released under.  It happens to be
GPL, but the code is licensed by the copyright holder, which is the FSF,
not you.

Even listing you as an author in the file is a courtesy, not an
obligation.

Furthermore, any future code you might write concerning Org is also
automatically property of the FSF, and by extension this community.  You
have no rights to it, moral or otherwise.

#+BEGIN_QUOTE:
(b) The assignment of par. 1(a) above applies to all past and future
works of Developer that constitute changes and enhancements to the
Program.
#+END_QUOTE:

With the copyright assignment in place, there is nothing to clear up
for the next release of Emacs.  The FSF owns the code.  You gave it to
them for $1 and other good and valuable consideration.

There is no way to change these terms for code you have already written,
unless you can convince the FSF to assign the copyright back to you, or
win the rights through legal action, neither of which sound fruitful.

If you are unhappy granting the copyright to your future Org code to the
FSF, your only recourse is to terminate your agreement with the FSF.  I
don't precisely know how that would be done, given that the copyright
assignment document makes no provision for its cancellation, but a
simple, formal notice of termination of the agreement might suffice,
even if made only to this list, which is operated by the FSF and managed
by its representatives.

Also, if you genuinely believe that anyone (including you) has a claim
to the rights to the Emacs code you have written, Section 2 of the
copyright assignment requires you to notify them:

#+BEGIN_QUOTE:
2. Developer will report occasionally, on Developer's
initiative and whenever requested by FSF, the changes and/or
enhancements which are covered by this contract, and (to the extent
known to Developer) any outstanding rights, or claims of rights, of any
person, that might be adverse to the rights of Developer or FSF or to
the purpose of this contract.
#+END_QUOTE:

Finally, this is only my understanding of the copyright assignment, but
the terms seem straightforward and clear.  If there really is
uncertainty among the developers here about what the copyright
assignment means, we should get clarification from RMS about the intent
or FSF legal about its legal implications before it leads to a lot of
hurt feelings (or worse).

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Create course material with org-mode

[T.F. Torrey]

Hello Thorsten,

Torsten Wagner torsten.wag...@gmail.com writes:

 Actually the topic is not exactly OT, I'm looking for a meta-system which
 helps me to keep all those different things together. Hopefully, in a way
 which allows me to generate different kind of course material from the same
 sources.
 I was wondering, can org-mode be such a meta-system e.g. could I keep
 materials of a certain topic within a single org-file and use (customized)
 exporters to create the desired outputs like a interactive HTML version, a
 printable PDF, exercises and questions for exams?

 E.g. a file structure like this

 * Theory
 text text text

 ** Interactive example :HTML
 Bable code

 ** more theory in detail
 *** Images

 ** lecture slides :BEAMER

 ** Exercises
 *** Solutions

 ** Exam questions
 *** 1
 *** 2
 *** 3

This is more or less precisely the structure I use for managing my work.
I maintain each project as one Org file, keeping together all related
text, todo lists, spreadsheets, web pages, letters, and even files like
SVG files.  This way I can add just one file (per project) to my agenda
and not miss any tasks, and backing up my critical work is just a matter
of copying my Org files.  When needed, I also export the individual
nodes as HTML, PDF, OpenDocument, csv, or whatever.

This works very well for me, even when I am treating university classes
as projects and keeping the syllabus, instruction material, lab
material, data, tests, correspondence, and everything else together in
one file.

 This file should ideally run through different exporters to generate
 interactive HTML for a website,
 printable PDF version,
 slides for a lecture,
 exercises with and without solution,
 exam questions,

 One task which might require some more attention (and code) would be to
 compile e.g.  the entire script from different source files. Same for an
 entire exam, a set of exercise, etc.
 The benefit of an approach like above would be that I can keep all related
 infos close to each other. It would be much easier to make changes among
 all different outputs, create new material, etc.
 Hope this makes my idea more clear.

 Thanks for helping

 Torsten

It was this capability of Org that first captured me as a user, and I
still know of nothing else with so much accessibility, utility, and
power.

I'd be happy to give you more information about how to set up an Org
file to export to different formats the way I use mine, but really the
information is very clear in the manual.

And of course, if you have any trouble, the list is really great.

All the best,
Terry
-- 
T.F. Torrey

[O] [bug] [new exporter] [markdown] Underline exports as HTML

[T.F. Torrey]

Hello,

The new markdown exporter (which I didn't think I'd use, but now greatly
appreciate) seems to export underlines as HTML rather than markdown.

In other words, this:

The _second_ thing.

exports as this:

The span style=text-decoration:underline;second/span thing.

I'm not experienced with markdown, but this doesn't look right to me.

Emacs  : GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0)
 of 2012-12-24 on menkib, modified by Debian
Package: Org-mode version 8.0-pre (release_8.0-pre-36-g0c7e2c @ 
/home/tftorrey/.emacs.d/elisp/org/lisp/)

All the best,
Terry
-- 
T.F. Torrey

Re: [O] (no subject)

[T.F. Torrey]

Hello,

Bastien b...@altern.org writes:

 Hi Andreas,

 Andreas Röhler andreas.roeh...@easy-emacs.de writes:

 Hmm, AFAIS trouble might occur only if someone tries to load a
 non-default --i.e. not-starred-- org-file while the default is
 active.

 ... or if someone shares a file online using non-star character
 as the prefix for headlines: this file won't be processed by
 Org tools like org-ruby and the like.

 But even then it's quite easy to write a guess, which might start if
 org-mode didn't encounter the stars where expected.

 Org files are not just for Emacs, that's were the problem lies...

I don't understand this heavy-handed approach.

Plain text is great because I can do whatever I want.  What I come up
with might not work correctly in other tools (or anything at all), but I
have the freedom to do interesting things, and to have my files look
just the way I want them to.

Emacs is great because it allows me the freedom of near-infinite
customization.  It has sensible defaults, but it allows me to break
things however I want.

Org, on the other hand, seems to be moving away from that in many ways.
Headlines must start with stars because I might someday post something
on the web and it wouldn't work for someone else?  Other tools might not
recognize my file correctly?  A developer of some other tool might
someday have a problem?  These are not good reasons for limiting what I
can do with my own Org files.

I don't need or want supervision in how I create my files.  I want
freedom.  If I wanted supervision, I wouldn't be using Emacs.  Have you
seen the lisp posted to the web?  Somehow, Emacs and I survive that.

Org started as a great tool that let me do cool things with my text
files.  I don't want to see it change to a rigid format for me to force
my files into, where my only options are conform or leave.

Org should err on the side of user freedom.

IMHO,
Terry
-- 
T.F. Torrey

Re: [O] [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Jambunathan,

Jambunathan K kjambunat...@gmail.com writes:

 Torrey

 One small problem, though: I see that if there is a TOC at the top and
 then one included later using #+TOC, the exporter gives them both the
 same id (div id=table-of-contents).  Duplicate ID's makes the XML
 invalid.

 What do you suggest instead? id=table-of-contents-1 for the first
 #+TOC: keyword and so on?

 Why do you need two table of contents?

I don't, though some might.  As was explained earlier in this thread, if
toc: options are set in the OPTIONS line, and a #+TOC is specified
later, two tables of contents are generated, and they have the same ID.
It is a feature of the new exporter, but duplicate ID's are not valid in
XML.

It is common for technical manuals to have a top-level table of contents
at the front of the manual and a detailed table of contents later on.
For instance, the GNU project Info manuals have that structure.

 This gives a significant advantage in that authors can link to the
 various instances just by knowing their own usage.  For instance, if
 they provided a top-level toc at the beginning of their book, and a
 deeper-level toc later on, they could link to each separately by id by
 knowing this plan.

 This seems like a valid use-case.  

 I would recommend that you just specify just the use-case and leave out
 the hows of implementation.

 Put your user hat and set aside the developer's hat.

What a strange, semi-insulting thing to say.

And misguided, too, as I was suggesting a design, not its
implementation.  As someone with all my own documents in Org and
extensive experience developing XSLT and lisp to process the XHTML
output of Org, I appreciate when the design of the HTML output is
logical and useful.

I would rather see a good design implemented in hacks than a poor design
implemented in beautiful code.

Regards,
Terry
-- 
T.F. Torrey

Re: [O] [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Jambunathan,

I admire your energy and coding skill, but I wish you would stop
occupying our time with replies like this.  Your tone is insulting, and
seems deliberately so, and none of this response is helpful to the
original thread.

I won't reply to more of your posts like this, so if you don't get a
reply, know that it's because your message was insulting and off-topic.
I'm only sending this on the odd chance that you are not aware of what
you are doing, in which case this might be helpful to you.

If you want to follow up to this message, I invite you to do so
off-list, where it might have been best for me to post this as well.

Best regards,
Terry

Jambunathan K kjambunat...@gmail.com writes:

 tftor...@tftorrey.com (T.F. Torrey) writes:

 This gives a significant advantage in that authors can link to the
 various instances just by knowing their own usage.  For instance, if
 they provided a top-level toc at the beginning of their book, and a
 deeper-level toc later on, they could link to each separately by id by
 knowing this plan.

 This seems like a valid use-case.  

 I would recommend that you just specify just the use-case and leave out
 the hows of implementation.

 Put your user hat and set aside the developer's hat.

 What a strange, semi-insulting thing to say.

 There is nothing strange in what I said.  I wasn't insulting.

 And misguided, too, as I was suggesting a design, not its
 implementation.  As someone with all my own documents in Org and
 extensive experience developing XSLT and lisp to process the XHTML
 output of Org, I appreciate when the design of the HTML output is
 logical and useful.

 When you were suggesting 

 #+toc: :a b :b c :c d

 that is implementation specifics and you were arguing from a HTML
 standpoint.  If you were in fact designing, you would have articulated
 your case for other backends and how your suggested changes would impact
 ox.el.

 I would rather see a good design implemented in hacks than a poor design
 implemented in beautiful code.

 If you have better ideas, show us the patch.  

 Otherwise, I suggest that you wear your user hat and place the use-case
 before use while others can take care of the details.

Re: [O] [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Jambunathan,

Jambunathan K kjambunat...@gmail.com writes:

 Is there a way your specific problem could be solved if we were to use
 CSS counters for numbering various things?  Would you like to submit a
 patch to ox-html.el that uses CSS-based counters rather than counters
 computed with hand.

No.

I'm not sure I understand your motives here, but I think you would like
to make changes to ox-html.el that would address the bug report/feature
request I sent.  If so, read on.

The problem is that in situations where the HTML exporter produces two
tables of contents, it gives them both the same ID.  That makes the XML
invalid, breaks some linking, and tends to choke XSLT processors.

I suggested three different strategies for the ID:

1. A detailed schema (see original email)
2. Allowing user to designate the ID
3. Just adding a sequence number to the end

Of these,

1 would probably be the hardest to implement, but would
provide the most accessibility for users and post-processors.

2 would probably be the easiest to implement, but would have the problem
that users wouldn't know they had to do it until something didn't work.

3 is probably the easiest to implement, but with the lowest utility.

My personal choice would be for both 1 and 2 to be implemented, but as
I'm not doing the work, that might be too much to ask.  Just doing 3
would make the XML valid again (in these cases), and would be good
enough for now.

So, if you're looking to implement a solution, 1 and 2 please, or 3 if 1
and 2 are too much work right now.  If, on the other hand, you're just
trying to find a way to make my suggestions sound dumb, please see my
previous e-mail.

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Jambunathan,

Jambunathan K kjambunat...@gmail.com writes:

 Jambunathan K kjambunat...@gmail.com writes:

[... 13 lines omitted ...]

 Subtree export of headline 1, but with section numbers starting at 1.
 Subtree export of headline 2, but with section numbers starting at 2.
 Splice them together.

 Considering that HTML exporter can export a subtree, I believe you can
 do some XSLT magic so that the individual HTML generated by Org is
 transformed before being spliced.

 Do you really want this to be supported within the scope of the Org
 exporter?  Are you sure you have explored all the tricks in your bag
 before raising this request.  Just wanted to confirm, because you seem
 to be the HTML expert among the three of us...

I'm not sure we are talking about the same issues.  For one thing, you
are replying to yourself here.  I did not suggest this.  My request was
merely for valid XML ID's for tables of contents from the HTML exporter,
given that most of the XML tricks in my bag depend on valid XML input.

[... 11 lines omitted ...]

 Allow a subtree to take EXPORT_TOC property.  (There should be a way to
 specifiy where this TOC will end up in - beginning of that chapter or
 end of the chapter)

 Similarly, one could introduce EXPORT_ENDNOTES property whereby each
 chapter can have it's own self-contained End Notes section.

I don't think these are related to my original concern, but they do
sound like interesting ideas that might be of use to me.  They also
sound like a lot of work.  Should this be taken up again after the 8.0
release?

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] [new exporter] [html] Tables of Contents

[T.F. Torrey]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 tftor...@tftorrey.com (T.F. Torrey) writes:

 One small problem, though: I see that if there is a TOC at the top and
 then one included later using #+TOC, the exporter gives them both the
 same id (div id=table-of-contents).  Duplicate ID's makes the XML
 invalid.

 What do you suggest instead? id=table-of-contents-1 for the first
 #+TOC: keyword and so on?


 Regards,

If I were implementing this with abundant resources, I'd probably opt
for a schema of base-type[-levels][-sequence], with these definitions:

- base :: probably toc to group and identify these id's
- type :: headlines, images, or other current or future types
- level :: depth of map, if it makes sense for the type
- sequence :: if necessary, the number of the copy of this configuration
  in this document

This schema would produce id's such as these:

- toc-headlines-1 :: lone instance of toc/headlines/one level
- toc-headlines-2 :: lone instance of toc/headlines/two levels
- toc-headlines-2-2 :: second instance of toc/headlines/two levels
- toc-images :: lone instance of toc/images (do levels make sense?)
- toc-tables :: first instance of list of tables
- toc-tables-2 :: second instance of list of tables

You get the idea.

This gives a significant advantage in that authors can link to the
various instances just by knowing their own usage.  For instance, if
they provided a top-level toc at the beginning of their book, and a
deeper-level toc later on, they could link to each separately by id by
knowing this plan.

Another idea for achieving the same linkability without the plan, would
be to support assigning an id in the plist (that isn't implemented yet),
such as #+TOC: :type headlines :levels 2 :id toc-headlines-2.  With
this power would come the responsibility for the users to make sure id's
were not duplicated.

As a minimum, your suggestion (table-of-contents-1, etc.) would be
reasonable for most use cases, and it's the shortest route to valid XML.

Some users of Org are producing complex documents that will probably be
active users of multiple toc types.  I'm curious what kind of schema
would work best for their use cases.

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] [ANN] Merge of new export framework on Wednesday

[T.F. Torrey]

Hello,

Rick Frankel r...@rickster.com writes:

 Also, shouldn't :html-style-include-default be
 :html-head-include-default?

The variable and this property should stay html-style-include-default,
or at worst become html-head-include-default-style.

The intent of changing things from html-style... to html-head... was
to make it clear that the use is for anything in the head, not merely
style.

It is still appropriate for variables that actually refer to style to
have the word style in them.

IMHO,
Terry
-- 
T.F. Torrey

Re: [O] Frustrated user of orgmode

[T.F. Torrey]

Suvayu Ali fatkasuvayu+li...@gmail.com writes:

 On Mon, Mar 04, 2013 at 07:10:47PM +0530, Vikas Rawal wrote:
 
 Do we have even a sketchy documentation of what a user is supposed to

 http://orgmode.org/worg/org-faq.html#new-exporter-switch

FWIW, I was trying to find this last night to answer a question, and
even though I knew exactly what I was looking for, I couldn't find it.
Granted, it was late and I was tired, but the site map has nothing, the
index has only dead ends, and the Google custom search doesn't seem to
narrow it down (lots and lots of things match exporter and new, and
I couldn't remember enough specific text to make it work).  (I was
looking for the syntax for the new #+TOC keyword, and in the end I gave
up and didn't find it until right now.)

I'm not making myself sound smart here, but the point is that I will be
happy when we get the documentation migrated over.

In the meantime, if we could add some prominent links to the sitemap,
index, and Worg index.html, that would have helped me a lot, and maybe
others.

Best regards,
Terry
-- 
T.F. Torrey

[O] [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello,

The new exporter currently puts the generated Table of Contents at the
beginning of the exported document in addition to the location of 
#+TOC: headlines.  I don't think it should insert it at the beginning
when it is called later.

However, I think the new exporter introduces disparities in the output
options that give us a chance to do something better.

In the new exporter, the type of generated Table of Contents depends on
two different configurations:

1. In the #+OPTIONS line, the toc: option determines whether to include
a TOC at the beginning, and how many levels /any/ TOC's should have.

2. The keyword #+TOC: can also be used to insert a generated TOC at a
specific location in the document.  This keyword allows options of
headlines, images, and listings, but it has no provision for levels.

Currently, using the OPTION toc:nil suppresses a default TOC.  Later on,
the #+TOC keyword is still recognized and acted upon, which I think is
the correct behavior, but then it includes all levels in the generated
TOC, because there no way to tell it otherwise.

IMHO, the #+OPTIONS line toc: option is unnecessary.  However, if used,
it should only provide the document default options for generated TOC's.

Instead, the #+TOC keyword should be changed to support the plist
structure that has been adopted elsewhere.  Thus, an example might be:

#+TOC: :type headlines :levels 2

Other options might be included, too, such as the option to suppress
dates or TODO states as Carsten requested, or perhaps even user-supplied
options, something like this:

#+TOC: :type headlines :levels 2 :dates nil :todo nil :title nil
   :extra-function my-custom-toc-headline-processor

(In this example, the :title property means the Table of Contents at
the top of the TOC, not the title of the headline.)

I don't know how the current options (or these I've proposed) could be
designated in the OPTIONS line.  If we dropped support for the toc:
option in the OPTIONS line, people would have to insert the #+TOC:
keyword with its options where they wanted it.  Would that be so bad?

I was going to post a bug report saying that the initial generated TOC
should not be included if there was a following #+TOC line, but then I
couldn't answer what to do if the later TOC was only images or listings.
My proposal eliminates this problem.

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Frustrated user of orgmode

[T.F. Torrey]

Hello Suvayu,

Suvayu Ali fatkasuvayu+li...@gmail.com writes:

 On Mon, Mar 04, 2013 at 11:42:24AM -0700, T.F. Torrey wrote:
 
 I'm not making myself sound smart here, but the point is that I will be
 happy when we get the documentation migrated over.

 FWIW, Worg (and Org) is a volunteer effort.  That particular FAQ entry
 started with me putting up a rather sparse 5 or so item list sometime
 back.  Later it was brought to the current level of detail by Bastien
 and others.  My point is, the easiest way to improve documentation is to
 add it yourself[1] when you hit on something new.

Please don't take my note as a complaint, it was intended only as a
sympathetic groan.  I well understand that Org is all-volunteer effort,
and I have the deepest appreciation for and admiration of all involved.
Emacs and Org have transformed my life!

All the same ... when I'm working on something at three in the morning,
and I *know* I saw (and saved) a bit of information, and the sitemap and
the index and even Google just shrug their shoulders I would have
been happy to add publicity for the information myself, if I could have
just found it!

  If you do not know
 how to add to Worg take a look here:

   http://orgmode.org/worg/#sec-4

I have not yet sent my public key to Bastien to become a Worg
contributor, but I expect to soon.

 If getting that to work is a problem, post on the list with the text and
 someone else will add it.

I'm pretty sure that's a given. :-)

 Cheers,

 PS: I updated the index for that entry.  Let me know if this is better.

Hmm.  I don't see it on the website, but it probably just hasn't been
rebuilt yet, and I don't know where you might have added the index
entry.  In the most recent pull from Worg, however, I see that Bastien
has started an Org-8.0 document.  That will be a big help.

 Footnotes:

 [1] Here by you I do not mean specifically you Terry, just a place
 holder for any Org user.

Thanks to you and everyone for your contributions.

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Frustrated user of orgmode

[T.F. Torrey]

Hello Bastien,

Bastien b...@altern.org writes:

 Hi Terry, 

 tftor...@tftorrey.com (T.F. Torrey) writes:

 (I was looking for the syntax for the new #+TOC keyword, and in the
 end I gave up and didn't find it until right now.)

 This is in the manual.  If you are using Org from master, just
 ~$ make doc and read the info/pdf page.  The section is entitled
 Table of contents.

Of course!  I actually have that so it updates automatically in my
machine, but I assumed the changes had not been documented yet.  Thanks
for the tip.

 In the meantime, if we could add some prominent links to the sitemap,
 index, and Worg index.html, that would have helped me a lot, and maybe
 others.

 I have migrated the migration instructions and tips here:
 http://orgmode.org/worg/org-8.0.html

This is looking good.

 Let's update this page as much as we can.

I hope and expect to soon.

 Thanks!

Many thanks to you,
Terry
-- 
T.F. Torrey

Re: [O] [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Nicolas,

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 tftor...@tftorrey.com (T.F. Torrey) writes:

 The new exporter currently puts the generated Table of Contents at the
 beginning of the exported document in addition to the location of 
 #+TOC: headlines.  I don't think it should insert it at the beginning
 when it is called later.

 I think it should. There's no reason for it to go against user's will,
 is there?

With the old exporter, the OPTIONS toc: option controlled whether a TOC
was generated at all.  With toc:2 (for instance), if you had
[TABLE-OF-CONTENTS] somewhere in the document, it would put the TOC
there *instead* of at the top.  I favor the new behavior.

IIUC, your response means that what I proposed is already, mostly, the
way things are intended: that the OPTIONS: toc: directive already only
applies to the default settings and the TOC at the top.

One small problem, though: I see that if there is a TOC at the top and
then one included later using #+TOC, the exporter gives them both the
same id (div id=table-of-contents).  Duplicate ID's makes the XML
invalid.

 However, I think the new exporter introduces disparities in the output

[... 10 lines omitted ...]

 headlines, images, and listings, but it has no provision for levels.

 Of course it has:

   #+TOC: headlines 2

 It is documented in the manual.

I didn't realize that this had been updated.  Thanks for the info.

[... 15 lines omitted ...]

 Instead, the #+TOC keyword should be changed to support the plist
 structure that has been adopted elsewhere.  Thus, an example might be:

 #+TOC: :type headlines :levels 2

 Indeed. I have to change this. But I need to modify the parser for such
 attributes first.

I'm sure there is no hurry.

 Other options might be included, too, such as the option to suppress
 dates or TODO states as Carsten requested, or perhaps even user-supplied
 options, something like this:

 #+TOC: :type headlines :levels 2 :dates nil :todo nil :title nil
:extra-function my-custom-toc-headline-processor

 (In this example, the :title property means the Table of Contents at
 the top of the TOC, not the title of the headline.)

 Interesting. But that's some additional work for back-end developers.

They could ignore what they can't or don't want to use, of course.

 I don't know how the current options (or these I've proposed) could be
 designated in the OPTIONS line.

 Some defcustom could be used. But we're not there yet.

This approach seems obtuse and perhaps over-engineered to me, but I'll
let it go.

The new TOC design solves a thorny problem I had with the old exporter.
Thanks a lot!

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] Bug: New HTML exporter incorrect attributes

[T.F. Torrey]

Hello Nicolas,

Nicolas Goaziou n.goaz...@gmail.com writes:

 tftor...@tftorrey.com (T.F. Torrey) writes:

 You don't assign attributes to an image in a paragraph, you assign
 attributes to the paragraph itself.

 It would be nice if there actually was a way to assign an attribute to a
 paragraph, so that the ATTR_HTML: class=XXX syntax would export as p
 class=XXX, but that is a different issue.

 It would be ATTR_HTML: :class XXX. I try to unify syntax for
 attributes with syntax for Babel and AFAICT, `html' is the last back-end
 to have key=value syntax.

I see that this does not presently work, and the author listed on
ox-html.el is not currently active on this list.  I hope you are not the
only one working on this.  It would be our great misfortune for you to
become burned out.

 For the time being, Org syntax
 doesn't allow to specify attributes per link object.

 I think what you are saying is that the current intended behavior is for
 whatever is specified by ATTR_HTML to apply to every image or link in
 the paragraph.

 No. I am saying that ATTR_HTML behaviour in _undefined_ when a paragraph
 contains more than one link, as it has always been.

 If you carefully look at Org manual (in application with previous
 exporter framework), in Images in HTML export, you will notice that
 HTML attributes only apply to a single link pointing to an image, not to
 a paragraph containing many links.

I see no such limitation in the Org manual (12.5.6).  It says this:

If you need to add attributes to an inlined image, use a
`#+ATTR_HTML'.

Though the example that follows doesn't show a paragraph, calling them
inline indicates they will be within a paragraph.  Org manual section
12.5.4 also shows ATTR_HTML applying to a hyperlink by itself, but
hyperlinks would rarely be used that way in real life, and in fact the
old exporter always applied ATTR_HTML attributes to the next item in a
paragraph.

I have always understood the manual to mean that an ATTR_HTML would
apply to *the next thing* in the document that it could, and that was
what happened in practice.  That was a useful thing for them to do.

 As a consequence, attributes will be assigned to every link within the
 paragraph.

 Is this behavior helpful to anyone in any practical circumstances?

 I never said it was. It's not even a feature. I'm just explaining what
 is happening.

If it isn't intended behavior, and it isn't helpful, then we should make
it stop doing that.

 Moreover, this means that, not only does the new exporter fail where the
 old one succeeded,

 I worked hard to make the new export framework compatible with defined
 behaviour of previous exporter, not with handy undocumented side-effects
 it may have.

 It seems to me that, whether the user is happy with the output or not,
 the HTML exporter ought to produce valid HTML.

 I agree. But, in this case, you're using undefined Org syntax (which,
 admittedly, used to work for you).

The HTML exporter should produce valid HTML regardless of the input.

 If there's a simple patch that mimics this for html back-end, I don't
 mind applying it. But it still won't make up for a real solution.

 Unless, that is, it is decided that this behaviour is an official
 feature supported by Org, in which case, it should be added to the
 manual.

The Org manual describes ATTR_HTML as a feature that applies to the
following image or link.  It makes no mention of restrictions to
following content in the paragraph, and neither does it say it will
apply to all following images or links.  The manual could be amended to
say that ATTR_HTML applies to just the next image or link.  To fit the
current situation, it might say, In cases where ATTR_HTML is applied to
an image in a paragraph, following links will not be made invalid.  But
why would anyone be expecting invalid HTML in the first place?

Incidentally, I always thought that simply using another HTML_ATTR would
handle multiple images or links in the old exporter.  In other words,
this:

#+ATTR_HTML: width=10 alt= [Cool thing] 
[[file:cool_thing.jpg]]
This is a paragraph about cool things.
#+ATTR_HTML: class=bar
Cool thing found here [[http://example.com/][example.com]].

Would become this:

p
img src=cool_thing.jpg width=10 alt= [Cool thing] /This is a 
paragraph about cool things. Cool thing found here a
href=http://example.com/; class=barexample.com/a.
/p

I don't remember using that in the old exporter, but I thought it would
work.

It almost works in the new exporter, but it begins a new paragraph
before the second #+ATTR_HTML.  I'm not sure this is the intended
behavior, though, because it isn't formatted like other new paragraphs.

 A more general workaround that would help everyone affected would be to
 temporarily modify ox-html.el so that attributes from ATTR_HTML only
 apply to the *first* item in the paragraph.  This would have the
 advantage of mimicking the behavior of the old exporter (thus not
 breaking existing content) and of keeping

Re: [O] Bug: New HTML exporter incorrect attributes

[T.F. Torrey]

Hello Nicolas,

Thanks for your prompt reply, though I think our discussion is a little
off-track here, as noted below.

Nicolas Goaziou n.goaz...@gmail.com writes:

 tftor...@tftorrey.com (T.F. Torrey) writes:

 It would be ATTR_HTML: :class XXX. I try to unify syntax for
 attributes with syntax for Babel and AFAICT, `html' is the last back-end
 to have key=value syntax.

This was your response to my comment that it would be handy to apply
attributes to paragraphs, not the links or images within them.

 I see that this does not presently work, and the author listed on
 ox-html.el is not currently active on this list.  I hope you are not the
 only one working on this.  It would be our great misfortune for you to
 become burned out.

 It's not much work once we agree about the real syntax. For example, for
 links, there are two ways to replace:

I think you are now talking about a syntax for adding attributes to
links and images within paragraphs.  In the e-mail to which you are
replying, I thought were agreeing that modifying the inline link and
image syntax was the best solution to these, and had thoughts on what
that might look like in another thread.  What you describe here still
has the limitation that either all links and images in a paragraph must
have the same attributes, or some must be invalid, or only the first is
reachable.

Apart from that, I have other more general concerns with this approach
noted below.

   #+ATTR_HTML: width=400px

 The easiest one, is simply to ask for `:options' before:

   #+ATTR_HTML: :options width=\400px\

 This is heavier but will be consistent with other back-ends.

Yes, this is heavy.  Escaping the quotes is unwieldy, and raises doubts
about what else might need to be escaped.  Also, given that the whole
and only point of the ATTR_HTML keyword is for describing options,
adding :options is redundant.  From a design standpoint, it might be
elegant that it matches other things, but here it seems very awkward,
and I don't understand who it would benefit.

This seems another step away from plain text toward another
programming language.  The first syntax looks like plain text.  The
second looks like programming.  For babel, and actual programming
languages, I'm sure this makes good sense.  For applying a width to an
image, it's overkill.

For instance, compare this plain text:

#+ATTR_HTML: :options width=\400px\ title=\My image\
[[file:image.jpg]]

to the HTML alternative:

img width=400px title=My image src=image.jpg/

Shouldn't the plain text be more straightforward to enter and easier to
understand that what it is replacing?

Here is the same thing in AsciiDoc:

image:image.jpg[My image,width=400]

Granted, I've already noted that I think we are moving toward inline
attribute specifications, so this syntax for images and links is
probably moot anyway, but I think the larger point still stands.

I hate to say that I have other concerns as well, but I do, below.

 Otherwise, there is also:

   #+ATTR_HTML: :width 400px

 But this requires to have a list of all properties supported. If we take
 that route, here is a suggested list of such properties for a tag:

   - rel
   - target
   - type
   - accesskey
   - class
   - style
   - title

 and for img

   - alt
   - height
   - width

 What do you think about it?

I think it is rather heavy-handed.  I don't understand why this
requires a list of properties supported.  The old exporter would
simply plug whatever you told it into the tag, trusting that you knew
what you were doing.  I'm sure this simplified the code, and it gave
great power to the user.  Why should the user need permission from the
developers to apply any arbitrary attributes to their elements?

Imposing these restrictions on users seems to make more work for the
users, and more work for the developers, to the benefit of no one.

Also, I don't know why attributes should be defined for each backend
rather than once for everywhere.  The attributes would be designated for
an object, and each backend would decide which to use or ignore.

For instance, though I know the LaTeX syntax not correct, this seems
like massive overkill for making a link red:

#+ATTR_LATEX: :options text-color: red
#+ATTR_HTML: :options class=\red\
Here is a [[file:doc.html]][red link]].

FWIW, the same thing in AsciiDoc would be this:

Here is a [red]#link:doc.html#[red link].

And it would work correctly for every backend, current or future.

In AsciiDoc, the attributes belong to the item, and every backend is
free to use or ignore them.  Plain text sure looks appealing.

Again, this is applying the old ATTR_ syntax instead of the suggested
inline attribute designations, but if the new link syntax matches the
spirit of the existing structure, something like this is in the works:

Here is a [[file:doc.html][red link][@@html: class=\red\@@ @@latex:
text-color: red@@]].

IMHO, the AsciiDoc approach is much better.

 The HTML exporter should produce valid HTML regardless of the input

Re: [O] Bug: New HTML exporter incorrect attributes

[T.F. Torrey]

Hello,

First, as always, thanks for the prompt reply.

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 tftor...@tftorrey.com (T.F. Torrey) writes:

 Where attributes have been assigned to an image in a paragraph, the new
 exporter applies those attributes to both the image and a following
 link.

 You don't assign attributes to an image in a paragraph, you assign
 attributes to the paragraph itself.

It would be nice if there actually was a way to assign an attribute to a
paragraph, so that the ATTR_HTML: class=XXX syntax would export as p
class=XXX, but that is a different issue.

 For the time being, Org syntax
 doesn't allow to specify attributes per link object.

I think what you are saying is that the current intended behavior is for
whatever is specified by ATTR_HTML to apply to every image or link in
the paragraph.

 As a consequence, attributes will be assigned to every link within the
 paragraph.

Is this behavior helpful to anyone in any practical circumstances?

Moreover, this means that, not only does the new exporter fail where the
old one succeeded, the new one produces invalid HTML (anchors with
invalid attributes) in the use case I described (ATTR_HTML to apply to
an image beginning a paragraph which later has a link in it, which
happens several times in almost all my documents).

It seems to me that, whether the user is happy with the output or not,
the HTML exporter ought to produce valid HTML.

 A hack could be implemented in ox-html.el so only image links
 get these attributes, but it would be the same with multiple images
 within the same paragraph.

Again, I can't think of a practical situation where this would be
helpful.  If all the images and/or links had the same styling, simple
CSS would suffice, and there would be no need for the ATTR_HTML.

In my case, however, this would actually work.

I know that it is possible to style links using ATTR_HTML, but does
anyone actually do that in practice?  I don't think I ever have.  If no
one uses it, would it be missed?

 A proper solution to the problem would be to slightly change link
 syntax.

The link syntax change will be a welcome addition, though I understand
that it is not a high priority.

 Until then, you'll have to use workarounds (like, for example, writing
 the other link in raw HTML syntax within an export snippet).

Yes, a personal workaround would be to use the raw HTML syntax to mark
the image in my example.  This has the strong disadvantage, however, of
meaning the image doesn't appear at all when the document is exported to
other formats, and of requiring changes to all affected documents when
the syntax changes again.

A more general workaround that would help everyone affected would be to
temporarily modify ox-html.el so that attributes from ATTR_HTML only
apply to the *first* item in the paragraph.  This would have the
advantage of mimicking the behavior of the old exporter (thus not
breaking existing content) and of keeping images for other export
formats.  Of course, anyone relying on the ATTR_HTML to set attributes
for every image and/or link in a paragraph would have to adopt a
different workaround, but ... does anyone really do this?

In my case, rather than changing all my documents to use raw HTML for
the images, I will write a filter function that walks through the final
HTML and removes invalid and superfluous attributes from the anchor
tags.  This strikes me as a rather ugly hack, though.

It seems unlikely to me that this issue only comes up with the HTML
exporter.  Surely some documents with primary output formats of LaTeX or
OpenDocument have similar requirements.  I wonder how those export
backends handle situations like this.

Thanks again for your help and hard work.

Best regards,
Terry
-- 
T.F. Torrey

[O] Bug: New HTML exporter incorrect attributes

[T.F. Torrey]

Hello,

Where attributes have been assigned to an image in a paragraph, the new
exporter applies those attributes to both the image and a following
link.

For example, this:

#+BEGIN_SRC org
#+ATTR_HTML: width=10 alt= [Cool thing] 
[[file:cool_thing.jpg]]
Cool thing found here [[http://example.com/][example.com]].
#+END_SRC

is exported to this:

#+BEGIN_HTML
p
img src=cool_thing.jpg width=10 alt= [Cool thing] /
Cool thing found here a href=http://example.com/; width=10
 alt= [Cool thing] example.com/a.
/p
#+END_HTML

Emacs  : GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0)
 of 2012-12-24 on menkib, modified by Debian

Package: Org-mode version 7.9.3e (7.9.3e-1173-g14df16 @
/home/tftorrey/.emacs.d/elisp/org/lisp/)

Best regards,
Terry
-- 
T.F. Torrey

[O] FIXME lines in ox-html.el

[T.F. Torrey]

Hello list,

There are about 25 lines of what looks like function or filter names
under the heading of FIXME in ox-html.el.

Does anyone know if these are features handled by the old exporter but
not yet by the new one, goals for new functionality, or something else?

Do these need to be resolved before the new exporter can reliably
replace the old one?

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] BIND org-html-style-include-*

[T.F. Torrey]

Hello,

Nicolas Goaziou n.goaz...@gmail.com writes:

 tftor...@tftorrey.com (T.F. Torrey) writes:

 Now, I have these:

 #+BIND: org-html-style-include-default nil
 #+BIND: org-html-style-include-scripts nil

 But they seem to be silently ignored, though if I setq the values ahead
 of time, the output is suppressed.

 Can these still be set using BIND?  If so, what am I doing wrong?

 What is the value of `org-export-allow-bind-keywords'?

Aha! That's the one I was looking for.  Thanks.

 Also, the value of org-html-mathjax-template seems to be output now by
 default, and I don't remember seeing it before.  Is this an intended
 change?  If so, how can it be suppressed?  (If not ... ???)

 I cannot answer you for now, because I don't know enough of the HTML
 back-end.

I still don't see any similar options regarding MathJax.  Perhaps
everyone else uses MathJax, or the functionality simply hasn't been
implemented yet.  If only the HTML export backend maintainer were still
on the list...

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] Macro expansion in new exporter

[T.F. Torrey]

Hello Nicolas,

Thank your for your thoughtful reply.

Nicolas Goaziou n.goaz...@gmail.com writes:

 tftor...@tftorrey.com (T.F. Torrey) writes:

 1. You wrote before that macros were scaled back because what they did
 could be done by babel.  Is that really a good reason for removing
 functionality?  Everything that Org does could be done in other tools,
 and yet ... we have Org.

 Macros were scaled down because the parser has to be able to know when
 it looks at one of them. This limits the places where a macro can be
 found. For example, it doesn't make much sense to expect a macro to be
 found in an example block.

 But scaling down macros made some of its features disappear. Since Babel
 code could provide them anyway, it generated no real regression.

Perhaps.  We still know of no easy/straightforward way at all to
replicate using babel the behavior I had (creating 'p
class=foobar/p' with a macro), let alone in a pair of single lines.

 To sum it up, they were not downgraded because of Babel, but if Babel
 hadn't been there, this wouldn't have happened.

 2. You wrote to Carsten that macros could no longer contain newlines.
 That seems like an arbitrary limitation.  Is it?

 In the parser, there's a difference between objects and elements.
 Distinction is made clear in the comments lines of org-element.el. To
 put it simply, objects cannot contain blank lines.

Thanks for the tip.  I've been very impressed with the comments in your
code.  Great work!

 Macros are objects. If I allow a newline in a macro, I allow two and
 therefore a blank line. For example a macro within a paragraph could
 potentially split it into two paragraphs. In this case, there would be
 a mismatch between what the user can see in the buffer, and what will
 happen during export.

 Babel code already has got this privilege (of breaking structure of the
 document). During alpha-test phase, bugs were reported because of
 unanticipated discrepancies between Babel code in original buffer and
 results in export buffer.

 Allowing macros to do the same would be asking for more trouble.

Macros are so straightforward compared to babel, I wonder how much
trouble they /could/ generate.

 3. Is there really a reason why macro expansion is limited to a few
 keywords rather than all?  Who would that trip up?  Ditto for verbatim
 and code emphasis.

 Most keywords are simple key and values couples. The parser mustn't look
 into the values, as it may find constructs that do not exist.

 On the other hand some selected keywords have to be parsed, because
 their value is really Org data. They are defined in org-element.el.
 See `org-element-document-properties' and `org-element-parsed-keywords'
 for an exhaustive list.

Thanks for this valuable tip.

 Verbatim and code emphasis contents are never parsed, by definition.

I was reading that wrong.  Code emphasis is not emphasis (italics).
Sorry for the noise.

 4. Given that macro values are easy to find in the source document, and
 unexpanded macros are easy to find in the output document, couldn't I
 just add a filter to the exporter to find and expand any unexpanded
 macros (and lingering newline indicators)?  Is there an easy method for
 adding such a filter?

 It may be possible, although very hackish. Functions in filters are, at

I have a lot of code that could be described as hackish, at best.  I
don't mind because producing beautiful code is pretty far down on my
list of goals.  I suspect, though, it would make you either laugh or
feel nauseous, probably both.

 the moment, called from the export buffer. So you can probably read
 macro definitions there. I think a proper filter to use for that would
 be `org-export-filter-final-output-functions'.

That's one I'm familiar with.  Thanks.

 I still strongly suggest to use Babel instead.

I wonder if an entry in the (underused) Library of Babel could replicate
the macro functionality and eliminate the need for macros as separate
things.  I will have to look into that when I have more time.

 5. Actually, why do macros need to be an exporter problem at all?
 Couldn't the macro functionality be put into a separate package that
 used hooks and filters to connect itself into the export routine and the
 various back-ends (if even necessary)?  Then macros could be made to do
 interesting things without burdening the export engine (and its
 maintainer) at all.

 Macros are an exporter problem, albeit a limited one, because their
 expansion happens during the export process. Also, some macros are very
 export oriented and have to be handled at the export framework level
 (e.g. {{{author}}}). Though, an export back-end actually never sees
 any macro, as these are expanded before its translator functions are
 called.

I'm pretty sure I could replicate (and even expand) the old macro
functionality by hooking an expansion function into
org-export-before-parsing-hook.  Maybe I will write an extension to try.

 Most of the macro code lives in org.el

[O] Dynamic blocks in the new exporter

[T.F. Torrey]

Hello again,

Does the new export framework impose new restrictions on or change the
functionality of dynamic blocks?

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] BIND org-html-style-include-*

[T.F. Torrey]

Hello,

Nicolas Goaziou n.goaz...@gmail.com writes:

 tftor...@tftorrey.com (T.F. Torrey) writes:

 I still don't see any similar options regarding MathJax.  Perhaps
 everyone else uses MathJax, or the functionality simply hasn't been
 implemented yet.  If only the HTML export backend maintainer were still
 on the list...

 Would you mind describing what is missing? It shouldn't be hard to
 implement it.

By default, the HTML export engine includes some CSS for basic
presentation, some JavaScript for interacting with code in the HTML, and
some JavaScript for the MathJax functionality (among many other things,
of course).

The CSS can be not included by setting org-html-style-include-default to
nil.

The non-MathJax JavaScript can be not included by setting
org-html-style-include-scripts to nil.

However, the new HTML exporter includes the MathJax JavaScript every
time, and I don't see any variable to set to suppress it.

The old exporter did not export it.  IIRC, it was off by default, and
there was a setting to turn it on (don't quote me, I never used it).

Recent posts by Bastien suggest that maybe it is supposed to be included
only if LaTeX is used in the buffer, but I'm not sure he was talking
about this issue.

With the new exporter on my Org, even the most minimal Org file exported
to HTML includes MathJax.  My Org version is 7.9.3e-1032-g791a8d.  The
most recent pulls fail testing (which people must already know).

(By the way, though it may be too late to change them now, the variables
would be better named org-html-include-style-default and
org-html-include-scripts-default and possibly
org-html-include-scripts-mathjax.  The HTML exporter has many things
that might be included in the output, and having the variables all
starting with org-html-include- would make them easier for everyone to
find, understand, and modify.)

(Similarly, as someone else wrote, #+HTML_STYLE would be much better
named #+HTML_HEAD, given that style is just one of the many things this
directive might put into the head element of the html.)

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Dynamic blocks in the new exporter

[T.F. Torrey]

Hello Seb,

Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 Hello T.F.,

 T.F. Torrey wrote:
 Does the new export framework impose new restrictions on or change the
 functionality of dynamic blocks?

 I've used them quite extensively today. Did not notice anything wrong.

 What are you trying to tell us?

I was merely inquiring to understand my options.

Before the new exporter, I converted my more complex macros to dynamic
blocks.  They are very handy, and I'm already familiar with implementing
them.

Now I'm deciding the best way to replace macros that no longer work.  I
didn't want to begin porting macros to dynamic blocks only to find out
that they had also been pared down in favor of babel.

Thanks for the prompt reply.

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] Macro expansion in new exporter

[T.F. Torrey]

Nicolas Goaziou n.goaz...@gmail.com writes:

 tftor...@tftorrey.com (T.F. Torrey) writes:

 This almost works, I think ...

 #+name: snippet-awesome
 #+begin_src org :exports results :results raw
 Snippet of awesome text that changes sometimes. #+end_src

 #+HTML: p class=foo
 #+CALL: snippet-awesome :results raw
 #+HTML: /p

 ... except that it doesn't actually export anything, and changing
 :exports to none doesn't help.  And neither does removing the :results
 raw from the call.

 Wild guess: did you activate org in your Babel languages?

Doh!  And that was one of the things I checked, too.

Now it works, but it isn't a solution because the CALL is wrapped in its
own p.  I'll figure something out.

Thanks again.

T.
-- 
T.F. Torrey

Re: [O] BIND org-html-style-include-*

[T.F. Torrey]

Hello,

Bastien b...@altern.org writes:

 Hi Terry,

 tftor...@tftorrey.com (T.F. Torrey) writes:

 However, the new HTML exporter includes the MathJax JavaScript every
 time, and I don't see any variable to set to suppress it.

 This is not the case anymore since commit 4d7f4d87.

Yes.  Thank you for the fix.

 Recent posts by Bastien suggest that maybe it is supposed to be included
 only if LaTeX is used in the buffer, but I'm not sure he was talking
 about this issue.

 I hope I was -- the MathJax config will now be included if your HTML
 page contains LaTeX snippets to display.  It will not be included
 otherwise.

 With the new exporter on my Org, even the most minimal Org file exported
 to HTML includes MathJax.  My Org version is 7.9.3e-1032-g791a8d.  The
 most recent pulls fail testing (which people must already know).

 You are behind a few commits, please update.

make up2 reports these failures (and thus does not install):

6 unexpected results:
   FAILED  test-org-babel/inline-src_blk-default-results-replace-line-1
   FAILED  test-org-babel/inline-src_blk-results-file
   FAILED  test-org-babel/inline-src_blk-results-raw
   FAILED  test-org-babel/inline-src_blk-results-scalar
   FAILED  test-org-babel/inline-src_blk-results-silent
   FAILED  test-org-babel/inline-src_blk-results-verbatim

I was reluctant to run make update when the tests failed, but I did
anyway for the rest of this.

 (By the way, though it may be too late to change them now, the variables
 would be better named org-html-include-style-default and
 org-html-include-scripts-default and possibly
 org-html-include-scripts-mathjax.  The HTML exporter has many things
 that might be included in the output, and having the variables all
 starting with org-html-include- would make them easier for everyone to
 find, understand, and modify.)

 I somewhat agree.  But C-h v org-html-include TAB expands and display 
 all variables here, so maybe not such an issue.  It is not too late to
 change the names of the variables, but I'd rather stick to these names
 because it lowers the effort when switching from 7.9 to 8.0.

Yes, typing C-h v org-html-include finds these variables:

org-html-style-include-default
org-html-style-include-scripts

It bothers me that the second one is misnamed.  It has nothing to do
with style.  Even for just these two, starting with org-html-include
(that is, org-html-include-style and org-html-include-script --- they
should probably both be singular or plural) would be an improvement, and
who knows what future development brings?

These variables are already changing (from org-export-html-style-*) for
8.0.  Now is a good time to DTRT.

 (Similarly, as someone else wrote, #+HTML_STYLE would be much better
 named #+HTML_HEAD, given that style is just one of the many things this
 directive might put into the head element of the html.)

 For this one I agree completely.  I will make this change.

All the people who just changed their files from #+STYLE to #+HTML_STYLE
will curse us, or you anyway, but it would make me happy (the change,
not them cursing you).

Thank you for your time and attention.

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] Macro expansion in new exporter

[T.F. Torrey]

Hello again,

Like many others, I'm adapting my workflow to the new exporter.  Like
Carsten (but apparently few others), I've been using macros extensively.
Though I've spent several days digging through the mailing list and
code, I still don't have the answers I need, but hopefully I can ask
intelligent questions.

Nicolas Goaziou n.goaz...@gmail.com writes:

 On that topic, the main difference with the previous exporter is that
 macros are now required to be in a context that can be parsed. Thus, for
 example, the following is not a macro:

   ~{{{title}}}~

What is meant by a context that can be parsed?

In my work, it has been very useful to use macros for snippets of
text.  Then, instead of changing the text everywhere when I want a
change, I would just change the macro.  So...

For instance, I used to be able to do this:

#+MACRO: status Draft
#+HTML: p class=status{{{status}}}/p

And on export to HTML, I would get what you would expect:
p class=statusDraft/p

With the new exporter, the macro is left unexpanded in the output:
p class=status{{{status}}}/p

Of course, I could also put the {{{status}}} in any ordinary text and
have it there as well.

In extensive experiments, I have not found any combination of input that
would produce the old output using macros.

The old behavior had an elegant, one-line solution.  Perhaps the
functionality could be duplicated with babel, but surely not as simply
and directly as with the old macro system.

Is there a way to replicate the old behavior in the new export engine?

Also, in your response to Carsten's question about macros, you suggested
this:

#+MACRO: thumbright @@html:img src=./Content/$2/thumb.jpg 
style=float:right;width:$1;margin:0px 20px 0px 20px; 
alt=./Content/$2/thumb.jpg /@@

The @@ syntax looks new to me.  Can you tell me what the function of
the @@ is?  Is this documented somewhere?

Best regards,
Terry
-- 
T.F. Torrey

[O] BIND org-html-style-include-*

[T.F. Torrey]

Hello,

In my files, this used to work to suppress the default styles and
javascript:

#+BIND: org-export-html-style-include-default nil
#+BIND: org-export-html-style-include-scripts nil

Now, I have these:

#+BIND: org-html-style-include-default nil
#+BIND: org-html-style-include-scripts nil

But they seem to be silently ignored, though if I setq the values ahead
of time, the output is suppressed.

Can these still be set using BIND?  If so, what am I doing wrong?

Also, the value of org-html-mathjax-template seems to be output now by
default, and I don't remember seeing it before.  Is this an intended
change?  If so, how can it be suppressed?  (If not ... ???)

Emacs: GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of
 2012-12-24 on menkib, modified by Debian

Package: Org-mode version 7.9.3e (7.9.3e-970-g728c0e @
/home/tftorrey/.emacs.d/elisp/org/lisp/)

Best regards,
Terry
-- 
T.F. Torrey

Re: [O] Macro expansion in new exporter

[T.F. Torrey]

Hello Nicolas,

Thank you for your thoughtful clarification about macros in the new
exporter.  Probably in the long run I will find happiness using babel
for what I want to do.  In the meantime, however, I have a few more
questions:

1. You wrote before that macros were scaled back because what they did
could be done by babel.  Is that really a good reason for removing
functionality?  Everything that Org does could be done in other tools,
and yet ... we have Org.

2. You wrote to Carsten that macros could no longer contain newlines.
That seems like an arbitrary limitation.  Is it?

3. Is there really a reason why macro expansion is limited to a few
keywords rather than all?  Who would that trip up?  Ditto for verbatim
and code emphasis.

4. Given that macro values are easy to find in the source document, and
unexpanded macros are easy to find in the output document, couldn't I
just add a filter to the exporter to find and expand any unexpanded
macros (and lingering newline indicators)?  Is there an easy method for
adding such a filter?

5. Actually, why do macros need to be an exporter problem at all?
Couldn't the macro functionality be put into a separate package that
used hooks and filters to connect itself into the export routine and the
various back-ends (if even necessary)?  Then macros could be made to do
interesting things without burdening the export engine (and its
maintainer) at all.

Thanks again for your amazing work.

Best regards,
Terry
-- 
T.F. Torrey

[O] Macro expansion in new exporter

[T.F. Torrey]

Hello all,

I really like the new exporter, and I appreciate the hard work of
everyone involved.

Right now, though, it's giving me a small problem: in the export to
HTML, macro's are not expanded, so I have {{{title}}}, for instance, in
the HTML output.

I haven't been following the list as closely as I'd like, so I'm hoping
I missed something relevant in the changeover.

If anyone has any ideas, I'd appreciate them before I go digging.

Emacs  : GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0)
 of 2012-12-24 on menkib, modified by Debian
Package: Org-mode version 7.9.2+ (7.9.2+-GNU-Emacs-24-3 (commit 488eea) @ mixed 
installation! /usr/share/emacs/24.3.50/lisp/org/ and 
/home/tftorrey/.emacs.d/elisp/org/lisp/)

Terry
-- 
T.F. Torrey

Re: [O] Problem with org-clock-persistence-insinuate in org-plus-contrib

[T.F. Torrey]

That's curious.

Achim Gratz writes:

 Actually, you will need to customize that variable if you want to use
 ditaa.  But the error is that ob-ditaa is missing a (require
 'org-compat), I've pushed a fix for that.  But you may still do your
 own customizations for Org too early, you should defer them to after
 package-initialize has run.

First, thanks so much for your help.  My whole life is in Emacs and
Org.

My initial report should be amended, because after a few cycles,
the error came back even with org-clock-persistence-insinuate commented
out.  I did not run and save a backtrace of that.

I don't use ditaa at all, and I have no mention of it in my init
file.  Something else must have been pretty far off the rails to be
calling it.

Finally, the only things before package-initialize in my init file were
some general Emacs interface settings (tool bar off, some others, I can
post a list if anyone is interested).  Nothing org related was before
it.  Nonetheless, when I move package-initialize to be the first thing
in the init file, the problem goes away.

Thanks again for your help.

Best regards,
Terry
-- 
T.F. Torrey

[O] Problem with org-clock-persistence-insinuate in org-plus-contrib

[T.F. Torrey]

 nil)
  file-name-directory(nil)
  (expand-file-name ../contrib (file-name-directory (or load-file-name 
buffer-file-name)))
  (file-name-as-directory (expand-file-name ../contrib (file-name-directory 
(or load-file-name buffer-file-name
  (expand-file-name scripts (file-name-as-directory (expand-file-name 
../contrib (file-name-directory (or load-file-name buffer-file-name)
  (file-name-as-directory (expand-file-name scripts (file-name-as-directory 
(expand-file-name ../contrib (file-name-directory (or load-file-name 
buffer-file-name))
  (expand-file-name ditaa.jar (file-name-as-directory (expand-file-name 
scripts (file-name-as-directory (expand-file-name ../contrib 
(file-name-directory (or load-file-name buffer-file-name)))
  eval((expand-file-name ditaa.jar (file-name-as-directory (expand-file-name 
scripts (file-name-as-directory (expand-file-name ../contrib 
(file-name-directory (or load-file-name buffer-file-name
  #[(v) 
\302!\205;\303\304\305!\\205;J\203\303\306\305!\\2046\307N\205;\310N\205;J\311\310N@!\232?\205;
B\211\207 [v list boundp string-match \\`\\(org-\\|outline-\\) 
symbol-name \\(-hook\\|-function\\)\\' custom-type standard-value eval] 
4](org-ditaa-jar-path)
  mapatoms(#[(v) 
\302!\205;\303\304\305!\\205;J\203\303\306\305!\\2046\307N\205;\310N\205;J\311\310N@!\232?\205;
   B\211\207 [v list boundp string-match \\`\\(org-\\|outline-\\) 
symbol-name \\(-hook\\|-function\\)\\' custom-type standard-value eval] 4])
  org-submit-bug-report()
  call-interactively(org-submit-bug-report record nil)
  command-execute(org-submit-bug-report record)
  execute-extended-command(nil org-submit-bug-report)
  call-interactively(execute-extended-command nil nil)
#+END_QUOTE

Best regards,
Terry
-- 
T.F. Torrey

[O] Bug: Bad timestamp 'habit'

[T.F. Torrey]

Hello,

I am currently unable to produce an agenda from my files.  This bug
crept in somewhere in the last few days, but I'm not sure exactly when.

This habit timestamp:

SCHEDULED: 2012-08-08 Wed .+1d

Produces this error:

condition-case: Bad timestamp `habit' at 210773 in buffer `Writing.org'
Error was: (Not a standard Org-mode time string: habit)

It works if I use the min/max format (2012-08-08 Wed .+1d/2d), but I
don't want to do that, and according to the manual, that isn't required.

Also, in this bug report data, I wonder why org-loaddefs.el can not be
found.  I run the org from a git repo, not compiled.

Emacs : GNU Emacs 24.2.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2) of
 2012-09-28 on louvi, modified by Debian Package: Org-mode version 7.9.2
 (release_7.9.2-383-g09d6bc-git @ org-loaddefs.el can not be found!)

If no one else sees this, I'll dig through my files to see what's
broken, but I see lots of work has been done to the agenda creator
recently, and maybe this is a new problem and an easy fix.

Best,
Terry
-- 
T.F. Torrey

[O] [PATCH] Fix for relative symlinks in subdirectories

[T.F. Torrey]

Hello all,

When publishing a project that contains relative symlinks in
subdirectories, org-publish-cache-ctime-of-src mistakenly connects the
true file name with the base-dir of the project instead of the symlink,
causing an error when the linked file is in a subdirectory and not the
base-dir.

The attached patch modifiies org-publish-cache-ctime-of-src to use the
dir of the current file as the base-dir instead of simply the project
base-dir.

With this change, though, the base-dir argument to this function now
never does anything. This doesn't seem to cause problems for me, but I
am far from intimate with the workings of the org-publish cache system.
Perhaps someone with better knowledge of the system could provide a
better fix. Otherwise, the base-dir argument could be refactored out.

ChangeLog entry: Fix for relative symlinks in subdirectories

Modify org-publish-cache-ctime-of-src to use the dir of the current file
as the base-dir instead of simply the project base-dir.

TINYCHANGE

Emacs : GNU Emacs 24.2.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2) of
 2012-08-29 on nannyberry, modified by Debian Package: Org-mode version
 7.9 (release_7.9-190-g845daf.dirty-git @ mixed installation!
 /usr/local/share/emacs/site-lisp/ and
 /home/tftorrey/.emacs.d/src/org-mode/lisp/)

Best regards,
Terry
--
T.F. Torrey

diff --git a/lisp/org-publish.el b/lisp/org-publish.el
index e78e2d4..cd77c82 100644
--- a/lisp/org-publish.el
+++ b/lisp/org-publish.el
@@ -1191,7 +1191,7 @@ Returns value on success, else nil.
 (defun org-publish-cache-ctime-of-src (f base-dir)
   Get the FILENAME ctime as an integer.
   (let ((attr (file-attributes
-  (expand-file-name (or (file-symlink-p f) f) base-dir
+  (expand-file-name (or (file-symlink-p f) f) (file-name-directory 
f)
 (+ (lsh (car (nth 5 attr)) 16)
(cadr (nth 5 attr)
 

[O] [PATCH] Works around bug in exporting subtree with HTML_CONTAINER_CLASS

[T.F. Torrey]

Hello all,

When exporting a subtree with an HTML_CONTAINER_CLASS property set,
exporting fails with this error: (error Before first headline at
position 455 in buffer *temp*) This happens because the system is
trying to apply the class to the parent level, but the exporting of a
subtree doesn't bring the parent level into the temp buffer.

The attached patch modifies org-export-remember-html-container-classes
to ignore the HTML_CONTAINER_CLASS property altogether in these cases.
It would probably be better to apply the designated class to the
container div or perhaps the body, but this change works for me, and I
may be the only one bothered by this.

If it is determined that another fix is more in the spirit of these
files, I will not be offended.

ChangeLog entry: Fix export of subtree with HTML_CONTAINER_CLASS

Modify org-export-remember-html-container-classes to work around problem
when exporting subtree with HTML_CONTAINER_CLASS property.

TINYCHANGE

All the best,
Terry
-- 
T.F. Torrey

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index c901a88..875bdf8 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -1476,8 +1476,11 @@ the current file.
^[ \t]*:HTML_CONTAINER_CLASS:[ \t]+\\(.+\\)$ nil t)
   (setq class (match-string 1))
   (save-excursion
+   (if (re-search-backward ^\\* (point-min) t)
+   (progn
(org-back-to-heading t)
(put-text-property (point-at-bol) (point-at-eol) 'html-container-class 
class)
+))
 
 (defvar org-export-format-drawer-function nil
   Function to be called to format the contents of a drawer.

[O] [PATCH] Fixes org-rmail-follow-link

[T.F. Torrey]

With creating links working in Rmail, now I see that following links
fails with the error Message not found.

The error comes from the use of the function widen in
org-rmail-follow-link. In an RMAIL buffer, the widen function only
widens to the current message. The function to widen to the entire
buffer is rmail-widen.

The attached patch replaces widen with rmail-widen and also removes the
following two lines (added by Bastien as part of the previous patch re
Rmail), because rmail-widen already displays full headers, so testing
and toggling them on has no effect.

GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2) of
2012-07-29 on doubah, modified by Debian

Org-mode version 7.8.11 (release_7.8.11-392-g9dae6f-git @ mixed
installation! /usr/local/share/emacs/site-lisp/ and
/home/tftorrey/.emacs.d/src/org-mode/lisp/)

Best to all,
Terry
-- 
T.F. Torrey

diff --git a/lisp/org-rmail.el b/lisp/org-rmail.el
index 9148a8e..d28a420 100644
--- a/lisp/org-rmail.el
+++ b/lisp/org-rmail.el
@@ -101,9 +101,7 @@
(rmail (if (string= folder RMAIL) rmail-file-name folder))
(setq message-number
  (save-restriction
-   (widen)
-   (when (eq rmail-header-style 'normal)
- (rmail-toggle-header -1))
+   (rmail-widen)
(goto-char (point-max))
(if (re-search-backward
 (concat ^Message-ID:\\s-+ (regexp-quote

Re: [O] [PATCH] Fixes org-rmail-store-link

[T.F. Torrey]

 This is fixed now, thanks.

 I used a slightly different fix, taking `rmail-header-style' into
 account.  Thanks anyway for the patch!

It works for me. Thanks for the quick fix. Although ...

-- 
T.F. Torrey

Re: [O] [PATCH] Fixes org-rmail-store-link

[T.F. Torrey]

Nick Dokos nicholas.do...@hp.com writes:

 The attached patch remedies this by toggling on the full header display
 before getting the Message-ID.
 

 Shouldn't it be toggled off afterwards?

That would seem logical to me, too, but the internal workings of
org-rmail.el and the rmail functions (which I don't fully understand)
already always leave the headers toggled off.

In the long run, this should probably be changed to respect the state
prior to storing the link, but for now, Bastien's patch makes the
linking function work.

Terry
-- 
T.F. Torrey

[O] [PATCH] Fixes org-rmail-store-link

[T.F. Torrey]

Hello all,

Attempting to save a link in an Rmail buffer fails with the error
Wrong type argument: arrayp, nil.

Attempting to save a link in an Rmail buffer succeeds if all headers
are shown (by pressing T to toggle the display).

Attempting to save a link in an Rmail summary buffer always fails with
the same error, even if all headers are shown.

The error occurs because org-rmail-store-link attempts to get the
Message-ID header with mail-fetch-field, then remove the angle
brackets with org-remove-angle-brackets. However, without showing full
headers, Message-ID is hidden, and (mail-fetch-field message-id)
returns nil. When this is passed to org-remove-angle-brackets, the
error is thrown.

The attached patch remedies this by toggling on the full header display
before getting the Message-ID.

Emacs  : GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2012-07-29 on doubah, modified by Debian

Package: Org-mode version 7.8.11 (release_7.8.11-360-g7c4ac5-git @ mixed
installation! /usr/local/share/emacs/site-lisp/ and
/home/tftorrey/.emacs.d/src/org-mode/lisp/)

Best to all,
Terry
-- 
T.F. Torrey

diff --git a/lisp/org-rmail.el b/lisp/org-rmail.el
index cb379d3..f8abbf4 100644
--- a/lisp/org-rmail.el
+++ b/lisp/org-rmail.el
@@ -52,6 +52,7 @@
 	  (rmail-show-message rmail-current-message))
 	(when (fboundp 'rmail-narrow-to-non-pruned-header)
 	  (rmail-narrow-to-non-pruned-header))
+	(rmail-toggle-header 0)
 	(let* ((folder buffer-file-name)
 	   (message-id (mail-fetch-field message-id))
 	   (from (mail-fetch-field from))

Re: [Orgmode] Minor docstring bug: org-footnote-goto-previous-reference

[T.F. Torrey]

 Date: Sun, 24 Oct 2010 08:57:35 +0530
 Subject: Re: [Orgmode] Minor docstring bug:
   org-footnote-goto-previous-reference
 From: Noorul Islam noo...@noorul.com
 To: rpgold...@sift.info
 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2)
 Cc: Org Mode emacs-orgmode@gnu.org
 Sender: emacs-orgmode-bounces+tftorrey=tftorrey@gnu.org
 
 On Sun, Oct 24, 2010 at 5:00 AM, Robert Goldman rpgold...@sift.info wrote:
  The docstring for the command org-footnote-goto-previous-reference is
 
    Find the next previous of the footnote with label LABEL.
 
  ...which I can't actually parse.
 
  Find the (immediately) previous reference to the footnote with label
  LABEL.
 
  Is that better?
 
 
 Patch is attached. I modified it a bit.

Noorul,

Actually, your modification makes it grammatically incorrect. The word
immediately is to modify the adjective previous, and in English, an
adjective needs to be modified by an adverb. So, immediately previous
would be correct, but immediate previous is not.

Trying to be helpful, not merely nit-picking,
Terry

 Fix doc string
 
 * lisp/org-footnote.el (org-footnote-goto-previous-reference): Fix doc string
 
 Proposed by Robert Goldman rpgold...@sift.info
 
 Thanks and Regards
 Noorul
 ___
 Emacs-orgmode mailing list
 Please use `Reply All' to send replies to the list.
 Emacs-orgmode@gnu.org
 http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] arranging and publishing music with Org-mode and lilypond

[T.F. Torrey]

Hello,

 From: Stefan Vollmar voll...@nf.mpg.de
 Date: Sun, 03 Oct 2010 00:26:39 +0200
 To: emacs org-mode mailing list emacs-orgmode@gnu.org
 X-Mailer: Apple Mail (2.1081)
 X-detected-operating-system: by eggs.gnu.org: Solaris 9
 Subject: [Orgmode] arranging and publishing music with Org-mode and lilypond
 Sender: emacs-orgmode-bounces+tftorrey=tftorrey@gnu.org
 
 Dear all,
 
 I believe that many members of this list with an interest in music 
 (notation/composition) might find the http://lilypond.org project addictive 
 (in the nicest possible manner): the concept is rather similar to writing 
 TeX, there is very good Emacs support (if you know where to look), it is all 
 OpenSource, there is extensive documentation (in LaTeX format with embedded 
 lilypond snippets), the print quality is excellent.
 
 I mention this because while arranging some piece of music recently, I 
 noticed that Org-mode might be helpful in this context - it is probably 
 already possible by tweaking org-babel a bit: lilypond encourages the user to 
 structure music in a way that lends itself rather naturally to processing 
 with Org-mode - you can assign a theme, a few bar with notes or even whole 
 voices to variables and use them repeatedly. And imagine using Org-mode's 
 outline capabilities to structure a piece of music. Exporting an org-file 
 with lilypond-snippets in it to PDF or HTML might also be an interesting 
 option.
 
 I have not yet put any effort into it and just wanted to find out if anybody 
 apart from me finds the combination of Org-mode and lilypond (potentially) 
 exciting.

I think this is very exciting.

Best regards,
Terry

 Warm regards,
  Stefan
 -- 
 Dr. Stefan Vollmar, Dipl.-Phys.
 Head of IT group
 Max-Planck-Institut für neurologische Forschung
 Gleuelerstr. 50, 50931 Köln, Germany
 Tel.: +49-221-4726-213  FAX +49-221-4726-298
 Tel.: +49-221-478-5713  Mobile: 0160-93874279
 Email: voll...@nf.mpg.de   http://www.nf.mpg.de
 
 
 
 
 
 
 ___
 Emacs-orgmode mailing list
 Please use `Reply All' to send replies to the list.
 Emacs-orgmode@gnu.org
 http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Question: Repeating Items?

[T.F. Torrey]

I had a similar problem with duplicate agenda entries. After much
aggravation, I discovered I had a duplicate entry for the file in the
setq org-agenda-files section of my .emacs file. Could the new machine
have multiple sections adding entries to org-agenda-files? Does the
value of that variable show duplicates? -- T.

 From: Matt Lundin m...@imapmail.org
 To: Kenneth Miller kenn...@erdosmiller.com
 Date: Thu, 16 Sep 2010 11:33:48 -0400
 User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)
 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
   recognized.
 Cc: emacs-orgmode@gnu.org
 Subject: [Orgmode] Re: Question: Repeating Items?
 Sender: emacs-orgmode-bounces+tftorrey=tftorrey@gnu.org
 
 Hi Ken,
 
 Kenneth Miller kenn...@erdosmiller.com writes:
 
  I fired up org-mode on my new machine, pulled my org files from source
  control, set my agenda files and agenda-key, attempted to view my
  agenda, and got the following. I've replaced some of the names with
  random characters for privacy, but events and todos are repeating
  themselves over and over and I can't seem to figure out why.
 
 I've never encountered this problem. Could you please provide a test
 case org file (along with the relevant portions of your .emacs)?
 
 Also, could you please report what version of org-mode you are using
 (M-x org-version).
 
 Best,
 Matt
 
 
  Example:
 
  Tuesday    14 September 2010
    em:         Sched.11x:  TODO Schedule Detectachem Monthly Review
    em:         Sched.11x:  TODO Detectachem Monthly Documentation
    em:         Sched.11x:  TODO Detectachem Monthly Billing
    em:         Sched.11x:  TODO Schedule Detectachem Monthly Review
    em:         Sched.11x:  TODO Detectachem Monthly Documentation
    em:         Sched.11x:  TODO Detectachem Monthly Billing
    em:         Sched.11x:  TODO Schedule Detectachem Monthly Review
    em:         Sched.11x:  TODO Detectachem Monthly Documentation
    em:         Sched.11x:  TODO Detectachem Monthly Billing
    em:         Sched.11x:  TODO Schedule Detectachem Monthly Review
    em:         Sched.11x:  TODO Detectachem Monthly Documentation
    em:         Sched.11x:  TODO Detectachem Monthly Billing
    em:         Sched.11x:  TODO Schedule Detectachem Monthly Review
    em:         Sched.11x:  TODO Detectachem Monthly Documentation
    em:         Sched.11x:  TODO Detectachem Monthly Billing
    em:         Sched.10x:  TODO Payroll
    em:         Sched.10x:  TODO Payroll
    em:         Sched.10x:  TODO Payroll
    em:         Sched.10x:  TODO Payroll
    em:         Sched.10x:  TODO Payroll
    pipe:       In -31 d.:  TODO Research wireless security for credit
  card transactions.
    pipe:       In -31 d.:  TODO Research wireless security for credit
  card transactions.
    pipe:       In -31 d.:  TODO Research wireless security for credit
  card transactions.
    pipe:       In -31 d.:  TODO Research wireless security for credit
  card transactions.
    pipe:       In -31 d.:  TODO Research wireless security for credit
  card transactions.
 
  ___
  Emacs-orgmode mailing list
  Please use `Reply All' to send replies to the list.
  Emacs-orgmode@gnu.org
  http://lists.gnu.org/mailman/listinfo/emacs-orgmode
 
 ___
 Emacs-orgmode mailing list
 Please use `Reply All' to send replies to the list.
 Emacs-orgmode@gnu.org
 http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] [ANN] Org to Atom, revisited

[T.F. Torrey]

On 06/18/2010 09:03 AM, David Maus wrote:

Olivier Schwander wrote:


[here]: http://ictsoc.de/code/org-atom/example.atom



Is there the source of this feed somewhere ? It would be nice to have a
self sufficient example.


I've uploaded the source of the example feed to

http://ictsoc.de/code/org-atom/example.org

But it's really as straightforward as the simple example in the
documentation.


* Download and installation



Maybe it would be useful to have the emacs lisp fragment users need to
put in their .emacs file ? And add this part to the Download and
install section of the online manual.


I'll put more detailed install instructions there as soon as there is
a decision about including org-atom into Org or not (yet).


1.2 Headline properties


A headline that matches the TAGS/PROP/TODO query for feed entries
requires at least two headline properties to be present: The =ID=
property with a unique identifier of the headline (preferable a UUID)
and a property called =atom_published= containing a time stamp with
the date an entry should be considered to be published.  If these two
properties are not present, they are automatically created using Org's
default method to create ID properties[2] and current time and date for
the publishing
date[3]



Maybe it should be better to extract timestamp from the usual timestamp
below headlines, like this one:



* Some title
  [2010-06-16 mer. 14:19]



or



* DONE Some title
  CLOSED: [2010-06-16 mer. 14:19]



Actually, with this solution, it would be better to remove the timestamp
used from the export, since it will displayed by the reader.


The problem is, that the Atom specification requires an entry to have
at least a atom:updated element.  Thus there must be timestamp
somewhere.  Binding the timestamp to a special position in Org mode
markup would limit the functionality of the exporter.

However: I understand that it could be reasonable to not use a
property, but an already present timestamp.  What about something like
this:

The name of the published and updated property can be customized.  It
can either be a string with the property name or the symbol
'timestamp_ia.  If it is this symbol, the exporter uses the first
inactive timestamp of a headline.  If the headline does not have an
inactive timestamp, the exporter throws an error.


This would be a welcome addition. I would use it, and perhaps it would 
entice RMS to adopt Org Mode as well. It's pretty close to what he  uses 
for his political notes:

http://www.stallman.org/archives/2010-mar-jun.html


1.3 Export settings

   content:   turn on/off publishing content



When content is t, the headline is exported both in title and in
content, is this a feature or a bug ? If it's a feature, it should be
nice to have an option to disable it.


Hah!  Good catch.  Never paid attention to this.  Just pushed a commit
that removes the title in the content element.

Thanks for the comment and suggestions.

   -- David

--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de



___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode


Org Mode gets better all the time. Thanks again.

- Terry

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] [ANN] Org to Atom, revisited

[T.F. Torrey]

David,

This is really great work, and I'm excited about using it for my own 
site. Hopefully this will be included in the official Org mode soon.


Thank you for this.

- Terry

On 06/15/2010 09:51 AM, David Maus wrote:


The Org to Atom exporter I've preliminary announce some weeks ago
entered a state I consider to be stable and consistent enough to be
included into Org mode.

It provides export, publishing and a sitemap functions that let you
create an Atom feed for a web page project based on (multiple) Org
mode files.  An example that shows the support of inline images in
feed entry content can be found [here].

[here]: http://ictsoc.de/code/org-atom/example.atom

* Download and installation

   The Org to Atom exporter is maintained in a copy of Org mode's git
   repository in branch org-atom located at

   git://github.com/dmj/dmj-org-mode.git

   You can download the most recent version at

   [http://github.com/dmj/dmj-org-mode/raw/org-atom/lisp/org-atom.el]

   To use the exporter you need a recent version of atom-syndication.el,
   an elisp implementation of the Atom Syndication Format.  You can get
   atom-syndication.el from github, too:

   git://github.com/dmj/atom-syndication.git

* Usage

   Please see the almost complete documentation below or read via web at

   [http://ictsoc.de/code/org-atom.html]

* Backward incompatibility

   If you have used an older version of the exporter you need to revise
   your configuration due to incompatible changes.  Most notably:

 - in-buffer options and publishing properties have be (re)renamed
   to start with #+FEED and :feed instead of #+ATOM and :atom;

 - support for the atom:category element is temporarily removed;

 - some default values have changed:

   - content is not published by default

   - names of the atom:updated and atom:published property default to
 atom_updated and atom_published

* Things yet to be done

   Besides support of even more atom elements (e.g. use tags for the
   atom:category element), the exporter would require a proper
   documentation for the Org mode manual, and of course some real-world
   testing.  Thus I'm interested not just in bugs, glitches,
   inconsistencies, and complains about the exporter but some feedback
   about the present documentation, too.

* Documentation

 Publish Atom feeds based on Org files
 =

Date: 2010-06-15 18:49:21 CEST

Table of Contents
=
1 Exporting an Org file to Atom
 1.1 In-buffer options
 1.2 Headline properties
 1.3 Export settings
 1.4 Example
2 Publish feeds for a web page project
 2.1 Publish a feed for each file in the project
 2.2 Publish a combined feed for project files


1 Exporting an Org file to Atom


An Atom feed consists of a head with feed meta data (e.g. feed title
and description) and one or more feed entries.  The exporter maps Org
mode subtrees to Atom feed entries and requires special in-buffer
options with feed as well as headline properties with entry specific
meta data.

1.1 In-buffer options
==

An Atom feed is identified by a globally unique identifier, preferably
a UUID.  Such an identifier must be present in a Org file supposed to
get exported or published to Atom in the =#+FEED_ID= in-buffer option.

If you do not use a UUID, the value of this in-buffer option must be a
proper IRI, like for example a URL that identifies this particular
feed.

To be able to properly reference feed entry content and the feed
itself[1], at least the URL of the feed must be given
by the =#+FEED_URL=.  By default Org assumes the published content
available in the same place like the feed with the name of the Org
file and the extension defined in =org-export-html-extension=.

For example a feed for the file =example.org= with the in-buffer
option =#+FEED_URL= set to =http://example.tld/feed.atom= is expected
to reference content located on the URL
=http://example.tld/example.html=.

If you indent to use different URLs for the feed and the referenced
content, you can set the content URL manually by providing the
in-buffer option =#+FEED_CONTENT_URL=.

Prospective feed entries are found by using the TAGS/PROP/TODO query
specified in the =#+FEED_MAP_ENTRIES= option.

If present, the exporter uses the in-buffer options =#+TITLE= and
=#+DESCRIPTION= for the feed title and description.  If no title is
given, the exporter uses the file name.  If you want the feed title or
description to be different than title and description of the
published HTML file, you can use the in-buffer options =#+FEED_TITLE=
and =#+FEED_DESCRIPTION=.

Atom feeds are required to have an associated author of a feed and its
entries.  Exporting an Org file to Atom thus always uses the author
specified with the =#+AUTHOR= option as the name of the author of a
feed.  If this option is not present, Org falls back to use