Re: [O] [PATCH] Improve usage of odt content templates

2014-05-22 Thread Detlef Steuer
Am Wed, 21 May 2014 14:47:37 +0200
schrieb Nicolas Goaziou n.goaz...@gmail.com:

 Hello,
 
 Christian Kellermann ck...@pestilenz.org writes:
 
  I first thought about using ODT_STYLES_FILE in the list form and
  pick out the content.xml from there, but maybe that's a bit
  unexpected as one might use a different content than from the style.
 
  But the control flow as it is now would need to be refactored to
  make this a nice patch too.
 
  I shall resend this patch with proper docstrings and manual patches
  if you like.
 
 Please do.
 
  I think this is a more general issue: should we implement an
  
#+OPTIONS: title:nil
  
  feature? I think it makes some sense since we already have
  date:nil and author:nil. In any case, keywords are not meant to be
  used for booleans. This should be an OPTIONS item.
 
  I don't feel qualified to decide on this. I can provide the needed
  patches though.
 
 Introducing the item is easy, but making something out of it in each
 back-end is not, as it requires to define what title:nil means there.
 In particular, should it be an empty title or something else?
 
 For example, ascii back-end provides a banner as its title. Should
 title:nil remove the title from the banner or should it remove the
 banner altogether, thus overriding date:t and author:t items.
 
 Likewise, should title:nil insert \title{} in a LaTeX document
 header, remove the \maketitle{} line, or perhaps, both?

To be consistent over backends I think it should be implemented as
an empty title string. If date:t or/and author:t are specified these
should show up somewhere.

\maketitle{} should be removed only, if a titlepage would appear empty 
in the exported document.

Just the usual 2c worth of opinion.

Detlef


 
 It seems that you answered to that question regarding ODT back-end
 though.
 
 WDYT?
 
 
 Regards,
 






Re: [O] [PATCH] Improve usage of odt content templates

2014-05-22 Thread Rasmus
Detlef Steuer detlef.ste...@gmx.de writes:

 Introducing the item is easy, but making something out of it in each
 back-end is not, as it requires to define what title:nil means there.
 In particular, should it be an empty title or something else?
 
 For example, ascii back-end provides a banner as its title. Should
 title:nil remove the title from the banner or should it remove the
 banner altogether, thus overriding date:t and author:t items.
 
 Likewise, should title:nil insert \title{} in a LaTeX document
 header, remove the \maketitle{} line, or perhaps, both?

 To be consistent over backends I think it should be implemented as
 an empty title string. If date:t or/and author:t are specified these
 should show up somewhere.

 \maketitle{} should be removed only, if a titlepage would appear empty 
 in the exported document.

 Just the usual 2c worth of opinion.

IMO, it just shouldn't set title in LaTeX.  When I use author:nil
\author{·} is simply not set and could be loaded via another file.  I
would also remove the \maketitle command.  I don't have any
particularly good argument for this, other than it feels right. . .
Alternatively, there could be a yet another option maketitle:if-title,
maketitle:always. . .

With the text backend.  I would make the banner dependent on the
presence of a title.  I.e. I'd probably go for no title, no banner.
Though it's less clear here to what extend a title-less banner makes
sense here.

—Rasmus

-- 
When in doubt, do it!




Re: [O] [PATCH] Improve usage of odt content templates

2014-05-21 Thread Nicolas Goaziou
Hello,

Christian Kellermann ck...@pestilenz.org writes:

 I first thought about using ODT_STYLES_FILE in the list form and
 pick out the content.xml from there, but maybe that's a bit unexpected
 as one might use a different content than from the style.

 But the control flow as it is now would need to be refactored to
 make this a nice patch too.

 I shall resend this patch with proper docstrings and manual patches
 if you like.

Please do.

 I think this is a more general issue: should we implement an
 
   #+OPTIONS: title:nil
 
 feature? I think it makes some sense since we already have date:nil and
 author:nil. In any case, keywords are not meant to be used for booleans.
 This should be an OPTIONS item.

 I don't feel qualified to decide on this. I can provide the needed
 patches though.

Introducing the item is easy, but making something out of it in each
back-end is not, as it requires to define what title:nil means there. In
particular, should it be an empty title or something else?

For example, ascii back-end provides a banner as its title. Should
title:nil remove the title from the banner or should it remove the
banner altogether, thus overriding date:t and author:t items.

Likewise, should title:nil insert \title{} in a LaTeX document header,
remove the \maketitle{} line, or perhaps, both?

It seems that you answered to that question regarding ODT back-end
though.

WDYT?


Regards,

-- 
Nicolas Goaziou



Re: [O] [PATCH] Improve usage of odt content templates

2014-05-20 Thread Eric Abrahamsen
Rasmus ras...@gmx.us writes:

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

 I think this is a more general issue: should we implement an

   #+OPTIONS: title:nil

 feature? I think it makes some sense since we already have date:nil and
 author:nil. In any case, keywords are not meant to be used for booleans.
 This should be an OPTIONS item.

 That's nicer than a blank title (#+TITLE: ).

 I prefer the earlier ox-behavior where no title would be printed if
 title was missing, rather than using the file-name.  The file name is
 never interesting in my work flow.  If introducing a title option it
 would be nice if an option is print title if present so that this
 can be set by default.

+1

I'm forever deleting the title because I forget to insert an empty
string #+TITLE option. If there was an `org-export-with-title' option
I'd set it to nil and be happy 80% of the time.

E




Re: [O] [PATCH] Improve usage of odt content templates

2014-05-20 Thread Christian Kellermann
Rasmus ras...@gmx.us writes:
 That's nicer than a blank title (#+TITLE: ).

 I prefer the earlier ox-behavior where no title would be printed if
 title was missing, rather than using the file-name.  The file name is
 never interesting in my work flow.  If introducing a title option it
 would be nice if an option is print title if present so that this
 can be set by default.

I can second this, the filename never looks nice when doing an export.

Kind regards,

Christian




Re: [O] [PATCH] Improve usage of odt content templates

2014-05-20 Thread Detlef Steuer
Am Tue, 20 May 2014 16:37:45 +0800
schrieb Eric Abrahamsen e...@ericabrahamsen.net:

 Rasmus ras...@gmx.us writes:
 
  Nicolas Goaziou n.goaz...@gmail.com writes:
 
  I think this is a more general issue: should we implement an
 
#+OPTIONS: title:nil
 
  feature? I think it makes some sense since we already have
  date:nil and author:nil. In any case, keywords are not meant to be
  used for booleans. This should be an OPTIONS item.
 
  That's nicer than a blank title (#+TITLE: ).
 
  I prefer the earlier ox-behavior where no title would be printed if
  title was missing, rather than using the file-name.  The file name
  is never interesting in my work flow.  If introducing a title
  option it would be nice if an option is print title if present so
  that this can be set by default.
 
 +1

+2

Have fought with set filename as title before, would like and use 
such an option.

Detlef

 
 I'm forever deleting the title because I forget to insert an empty
 string #+TITLE option. If there was an `org-export-with-title' option
 I'd set it to nil and be happy 80% of the time.
 
 E
 
 
 



-- 
Detlef Steuer

---

Dr. Detlef Steuer
Helmut-Schmidt-Universität
Fakultät WiSo
Holstenhofweg 85
22043 Hamburg

Tel:  040/6541-2819
mail: ste...@hsu-hh.de





Re: [O] [PATCH] Improve usage of odt content templates

2014-05-20 Thread Bastien
Hi Nicolas,

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

 I think this is a more general issue: should we implement an

   #+OPTIONS: title:nil

 feature? I think it makes some sense since we already have date:nil and
 author:nil. In any case, keywords are not meant to be used for booleans.
 This should be an OPTIONS item.

+1!

-- 
 Bastien



Re: [O] [PATCH] Improve usage of odt content templates

2014-05-19 Thread Nicolas Goaziou
Hello,

Christian Kellermann ck...@pestilenz.org writes:

 I have been using org-mode's odt exporter heavily for the last days
 with the attached patches. These scratch an itch I have and I submit
 them to this list in the hope of being useful to others.

Thank you for your patches.

 * Possibility to override the globally defined
 org-odt-content-template-file variable in the document

It is already possible to override the varible file-wise with:

  #+BIND: org-odt-content-template-file somefile

I'm not sure it is worth adding another keyword. OTOH, there's also
ODT_STYLES_FILE and they are quite symmetric, so one could expect to be
able to set both. But then, `org-odt-content-template-file''s docstring
needs to be updated, and the feature should be documented in the manual.

Also, it should be

  (:odt-content-template-file ODT_CONTENT_TEMPLATE_FILE nil 
org-odt-content-template-file t)

 * Avoid inserting the document title as the first thing in the
 document contents, as there already is a title set in a title page
 in the template. As org-mode already sets the title data tag this
 can be used in the template to generate the correct title. However
 inserting the title as text is not desireable in that scenario.

I think this is a more general issue: should we implement an

  #+OPTIONS: title:nil

feature? I think it makes some sense since we already have date:nil and
author:nil. In any case, keywords are not meant to be used for booleans.
This should be an OPTIONS item.


Regards,

-- 
Nicolas Goaziou



Re: [O] [PATCH] Improve usage of odt content templates

2014-05-19 Thread Rasmus
Nicolas Goaziou n.goaz...@gmail.com writes:

 I think this is a more general issue: should we implement an

   #+OPTIONS: title:nil

 feature? I think it makes some sense since we already have date:nil and
 author:nil. In any case, keywords are not meant to be used for booleans.
 This should be an OPTIONS item.

That's nicer than a blank title (#+TITLE: ).

I prefer the earlier ox-behavior where no title would be printed if
title was missing, rather than using the file-name.  The file name is
never interesting in my work flow.  If introducing a title option it
would be nice if an option is print title if present so that this
can be set by default.

—Rasmus

--
El Rey ha muerto. ¡Larga vida al Rey!





Re: [O] [PATCH] Improve usage of odt content templates

2014-05-19 Thread Christian Kellermann
Hi!

* Nicolas Goaziou n.goaz...@gmail.com [140519 18:16]:
 It is already possible to override the varible file-wise with:
 
   #+BIND: org-odt-content-template-file somefile
 
 I'm not sure it is worth adding another keyword. OTOH, there's also
 ODT_STYLES_FILE and they are quite symmetric, so one could expect to be
 able to set both. But then, `org-odt-content-template-file''s docstring
 needs to be updated, and the feature should be documented in the manual.

I first thought about using ODT_STYLES_FILE in the list form and
pick out the content.xml from there, but maybe that's a bit unexpected
as one might use a different content than from the style.

But the control flow as it is now would need to be refactored to
make this a nice patch too.

I shall resend this patch with proper docstrings and manual patches
if you like.

 
 Also, it should be
 
   (:odt-content-template-file ODT_CONTENT_TEMPLATE_FILE nil 
 org-odt-content-template-file t)

Ah of course.

 
  * Avoid inserting the document title as the first thing in the
  document contents, as there already is a title set in a title page
  in the template. As org-mode already sets the title data tag this
  can be used in the template to generate the correct title. However
  inserting the title as text is not desireable in that scenario.
 
 I think this is a more general issue: should we implement an
 
   #+OPTIONS: title:nil
 
 feature? I think it makes some sense since we already have date:nil and
 author:nil. In any case, keywords are not meant to be used for booleans.
 This should be an OPTIONS item.

I don't feel qualified to decide on this. I can provide the needed
patches though.

Thanks for your review!

Regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.