Re: [O] [PATCH] Re: \newpage in HTML export

[Bastien]

Hi Suvayu,

Suvayu Ali  writes:

> It already exists:
>
>   
>
> Maybe this can be improved?

This is the documentation for export filters, with some example.

But it is not clear that this page welcome new contributed
filters, and I think it does not.

I think having another page would help.

-- 
 Bastien

Re: [O] [PATCH] Re: \newpage in HTML export

[Suvayu Ali]

On Sat, Jan 04, 2014 at 11:40:10AM +0100, Bastien wrote:
> Hi Andreas,
> 
> Andreas Leha  writes:
> 
> > It is a very small thing and I am very much happy with using a filter based
> > approach here.
> 
> One thing really worth improving is the tutorials around filters on
> Worg.  Or maybe: let's create a place similar to org-hacks.org called
> org-filters.org listing useful filters.

It already exists:

  

Maybe this can be improved?

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] [PATCH] Re: \newpage in HTML export

[Bastien]

"Sebastien Vauban" 
writes:

> The thing is that, IMHO, there are 2 types of filters required:
>
> - filters for my own additions to Org syntax, that I don't need (or
>   want) to share with anybody
>
> - filters for "missing" Org syntax which seems a need that many users
>   have at some point
>
> The \newpage stuff, AFAIU, falls in the second category. This question
> came a couple of times already on this ML, hence my suggestion to offer
> it in a more standard way -- without just telling "go on Worg, copy some
> snippet you'd find, paste it in your .emacs, and tell your colleagues to
> do the same".

Yes, that's why I suggest filters to be only for local customizations,
while "filters-needed-by-many-users" should really be in the code (and
probably not as filters.)

But still, a place to find and learn about filters would be nice.

-- 
 Bastien

Re: [O] [PATCH] Re: \newpage in HTML export

[Sebastien Vauban]

Hello Bastien,

Bastien wrote:
> "Sebastien Vauban" writes:
>
>> Shouldn't, then, some filters be available by default in core Org?
>
> I don't think so: my understanding is that "default filters" would
> then be implemented without relying on filters -- so filters are
> really optional by nature. Nicolas will correct me if I'm wrong.
>
> But building a page on Worg listing useful filters is a separate task,
> and a good one.

The thing is that, IMHO, there are 2 types of filters required:

- filters for my own additions to Org syntax, that I don't need (or
  want) to share with anybody

- filters for "missing" Org syntax which seems a need that many users
  have at some point

The \newpage stuff, AFAIU, falls in the second category. This question
came a couple of times already on this ML, hence my suggestion to offer
it in a more standard way -- without just telling "go on Worg, copy some
snippet you'd find, paste it in your .emacs, and tell your colleagues to
do the same".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [PATCH] Re: \newpage in HTML export

[Bastien]

"Sebastien Vauban" 
writes:

> Shouldn't, then, some filters be available by default in core Org?

I don't think so: my understanding is that "default filters" would
then be implemented without relying on filters -- so filters are
really optional by nature.  Nicolas will correct me if I'm wrong.

But building a page on Worg listing useful filters is a separate
task, and a good one.

-- 
 Bastien

Re: [O] [PATCH] Re: \newpage in HTML export

[Sebastien Vauban]

Andreas Leha wrote:
>> Could you expand on what you mean by "less portable"? I'm interested in
>> portability from a reproducible research perspective and want to avoid
>> habits that don't port well to other researchers' systems.
>>
>
> I did not want to include these words in the first place.  The words 'less
> portable' are too strong here.
>
> You won't be affected, since you ship your emacs / Org configuration
> with the document, IIUC.  (Which is the only possible way to achieve
> something like reproducibility with Org...)
> In that case you can simply include such a filter in that configuration.
>
> The non-portable part comes from the need to share that filter.
> Anybody without that filter will not be able to export your document in
> the intended way.

Shouldn't, then, some filters be available by default in core Org?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [PATCH] Re: \newpage in HTML export

[Bastien]

Andreas Leha  writes:

> I am very sorry -- would have been a nice way to contribute.

No problem, I just wanted to verbalize this wish so that someone
with more time at hand can take the challenge :)

-- 
 Bastien

Re: [O] [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Bastien  writes:

> Hi Andreas,
>
> Andreas Leha  writes:
>
>> It is a very small thing and I am very much happy with using a filter based
>> approach here.
>
> One thing really worth improving is the tutorials around filters on
> Worg.  Or maybe: let's create a place similar to org-hacks.org called
> org-filters.org listing useful filters.

I agree.  an org-filters collection would be awesome!

>
> Any taker?

Not me, I am afraid, since I am completely out of time right now(so that
I should actually not read or write anything on this list...).

I am very sorry -- would have been a nice way to contribute.

Regards,
Andreas

Re: [O] [PATCH] Re: \newpage in HTML export

[Bastien]

Hi Andreas,

Andreas Leha  writes:

> It is a very small thing and I am very much happy with using a filter based
> approach here.

One thing really worth improving is the tutorials around filters on
Worg.  Or maybe: let's create a place similar to org-hacks.org called
org-filters.org listing useful filters.

Any taker?

-- 
 Bastien

Re: [O] [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Hi Tom,

t...@tsdye.com (Thomas S. Dye) writes:

> Aloha Andreas,
>
> Andreas Leha  writes:
>
>> Bastien  writes:
>>
>>> Nicolas Goaziou  writes:
>>>
> So in short:  If page breaks are not in org directly many people will
> end up with inferior and/or less portable org files.

 For the record, after thinking about it, I'd rather stay away from
 invisible characters in Org syntax, would it be page breaks or
 non-breaking spaces.
>>>
>>> FWIW I fully support not using invisible chars in Org syntax.
>>
>> This follows up on just a side aspect in this thread that is (partly)
>> separate from its subject.
>>
>>
>> Just to wrap the thread up in my words:
>>
>> 1. Cross-backend (or more cross-backend) support of \newpage built into
>>Org directly was disapproved in favor of a less portable filter based
>>solution [fn:1].
>
> Could you expand on what you mean by "less portable"? I'm interested in
> portability from a reproducible research perspective and want to avoid
> habits that don't port well to other researchers' systems.
>

I did not want to include these words in the first place.  The words 'less
portable' are too strong here.

You won't be affected, since you ship your emacs / Org configuration
with the document, IIUC.  (Which is the only possible way to achieve
something like reproducibility with Org...)
In that case you can simply include such a filter in that configuration.


The non-portable part comes from the need to share that filter.
Anybody without that filter will not be able to export your document in
the intended way.


Just to clarify:
It is a very small thing and I am very much happy with using a filter based
approach here.

> Happy New Year!
Same to you!

Regards,
Andreas

Re: [O] [PATCH] Re: \newpage in HTML export

[Thomas S. Dye]

Aloha Andreas,

Andreas Leha  writes:

> Bastien  writes:
>
>> Nicolas Goaziou  writes:
>>
 So in short:  If page breaks are not in org directly many people will
 end up with inferior and/or less portable org files.
>>>
>>> For the record, after thinking about it, I'd rather stay away from
>>> invisible characters in Org syntax, would it be page breaks or
>>> non-breaking spaces.
>>
>> FWIW I fully support not using invisible chars in Org syntax.
>
> This follows up on just a side aspect in this thread that is (partly)
> separate from its subject.
>
>
> Just to wrap the thread up in my words:
>
> 1. Cross-backend (or more cross-backend) support of \newpage built into
>Org directly was disapproved in favor of a less portable filter based
>solution [fn:1].

Could you expand on what you mean by "less portable"? I'm interested in
portability from a reproducible research perspective and want to avoid
habits that don't port well to other researchers' systems.

Happy New Year!

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Bastien  writes:

> Nicolas Goaziou  writes:
>
>>> So in short:  If page breaks are not in org directly many people will
>>> end up with inferior and/or less portable org files.
>>
>> For the record, after thinking about it, I'd rather stay away from
>> invisible characters in Org syntax, would it be page breaks or
>> non-breaking spaces.
>
> FWIW I fully support not using invisible chars in Org syntax.

This follows up on just a side aspect in this thread that is (partly)
separate from its subject.


Just to wrap the thread up in my words:

1. Cross-backend (or more cross-backend) support of \newpage built into
   Org directly was disapproved in favor of a less portable filter based
   solution [fn:1].

2. Introducing invisible chars (as syntax for a possible implementation
   of such cross backend \newpage) in Org syntax was generally
   disapproved.

Regards,
Andreas


Footnotes:

[fn:1] http://permalink.gmane.org/gmane.emacs.orgmode/79164

Re: [O] [PATCH] Re: \newpage in HTML export

[Bastien]

Nicolas Goaziou  writes:

>> So in short:  If page breaks are not in org directly many people will
>> end up with inferior and/or less portable org files.
>
> For the record, after thinking about it, I'd rather stay away from
> invisible characters in Org syntax, would it be page breaks or
> non-breaking spaces.

FWIW I fully support not using invisible chars in Org syntax.

-- 
 Bastien

Re: [O] [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Nicolas Goaziou  writes:

> Hello,
>
> Andreas Leha  writes:
>
>> Just for me to understand:
>> The recommended way now
>
> Note that the recommended way hasn't really changed. There was no
> recommended way before, nor there is one now.
>

;-)

>> is to have a filter and write (say) \mypersonalnewline in my orgmode
>> files? Even if \mypersonalnewline won't work for anyone except myself?
>> Or did I miss something?
>
> You can write ^L in your files, as long as you transform it into
> something useful, through a filter.
>

I am not interested in ^L in particular.  I am interested in a
pagebreak, that works across backends.  My filter will not use '^L' but
rather '\newpage'.

> It will work for anyone with whom you share your Org configuration, or,
> at least, anyone using an equivalent filter.

Ok.  So be it.

Regards,
Andreas

Re: [O] [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Andreas Leha  writes:

> Just for me to understand:
> The recommended way now

Note that the recommended way hasn't really changed. There was no
recommended way before, nor there is one now.

> is to have a filter and write (say) \mypersonalnewline in my orgmode
> files? Even if \mypersonalnewline won't work for anyone except myself?
> Or did I miss something?

You can write ^L in your files, as long as you transform it into
something useful, through a filter.

It will work for anyone with whom you share your Org configuration, or,
at least, anyone using an equivalent filter.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> Andreas Leha  writes:
>
>> So in short:  If page breaks are not in org directly many people will
>> end up with inferior and/or less portable org files.
>
> For the record, after thinking about it, I'd rather stay away from
> invisible characters in Org syntax, would it be page breaks or
> non-breaking spaces.

I agree about the invisible characters.

>
> Porting an Org file requires to also to port Org configuration. A filter
> is enough to support these characters. Added support would just be, IMO,
> "coolishness".

Just for me to understand:
The recommended way now is to have a filter and write (say) \mypersonalnewline
in my orgmode files?  Even if \mypersonalnewline won't work for anyone
except myself?  Or did I miss something?

Regards,
Andreas

Re: [O] [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Andreas Leha  writes:

> So in short:  If page breaks are not in org directly many people will
> end up with inferior and/or less portable org files.

For the record, after thinking about it, I'd rather stay away from
invisible characters in Org syntax, would it be page breaks or
non-breaking spaces.

Porting an Org file requires to also to port Org configuration. A filter
is enough to support these characters. Added support would just be, IMO,
"coolishness".


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Re: \newpage in HTML export

[Jambunathan K]

You could have used a #+PAGEBREAK and handled it as part of say an
advice to org-BACKEND-keyword in whatever BACKEND you are using.

Re: [O] [PATCH] Re: \newpage in HTML export

[Christian Moe]

Nicolas Goaziou writes:
> So, is this feature a must-have? 

No, it's not. (Just another user's ten cents.)

> Or would a filter template in Worg more appropriate in this case?

That, or showing how to make a {{{pagebreak}}} macro expanding to export
snippets. (And explaining how regular page breaks before new chapters
etc. are anyway better handled by styles in ODT and HTML-for-print.)

Yours,
Christian

Re: [O] [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Eric Abrahamsen  writes:

> On 11/24/13 16:31 PM, Nicolas Goaziou wrote:
>> Hello,
>>
>> Rüdiger Sonderfeld  writes:
>>
>>> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
 Anyway, I don't think this is a good idea to introduce a new syntax just
 to avoid a one-liner (or a hook, see below). Also, this would only make
 sense in few export back-ends.
>>>
>>> But is it really a new syntax or just support for an existing Emacs 
>>> convention?  See (info "(emacs) Pages").
>>>
>>> It seems like a feature which could be supported in many back-ends: LaTeX, 
>>> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.
>>
>> I do not question this.
>>
>> My point is that introducing this new syntax would bring up nothing that
>> can already be achieved using filters or hooks.
>>
>> So, is this feature a must-have? Or would a filter template in Worg more
>> appropriate in this case?
>
> It's not that everyone is desperate to have this in org proper. Putting
> it into the code base vs making a hook: my guess is the number of LOC
> would be very nearly exactly the same, and there's literally no
> practical difference in the result. When "why" and "why not" are
> perfectly balanced, it may be better to do nothing.
>
> But I think it just *feels* right, because the page delimiter already
> seems like a first-class citizen in emacs. I'll admit it's also
> partially because it's a control character. Control character! Must be
> serious programming. I also like the thought of a new org user sticking
> one in their document, exporting, and finding that org does the right
> thing.
>
> At this point, I'm pretty much neutral buoyancy on the issue, though...
>

I (as a user, so not carrying the maintenance burden of any added
feature) am in favor of having this feature in org directly.

I think many people that use some of the export functionality will need
to control page breaks at some point.  If this is not supported by org,
most of them will have (as I did until now) backend specific page breaks
in their org mode files (maybe multiple, as suggested earlier in this
thread), which is the inferior solution.

A possible argument against the filter solution is, that an org file that
relies on the presence of a filter is less portable.

And I do not agree with 'the number of LOC would be very nearly exactly
the same' as the filter has to be copy-pasted by every one who wants to
use it ;-)


So in short:  If page breaks are not in org directly many people will
end up with inferior and/or less portable org files.



- Andreas

Re: [O] [PATCH] Re: \newpage in HTML export

[Eric Abrahamsen]

On 11/24/13 16:31 PM, Nicolas Goaziou wrote:
> Hello,
>
> Rüdiger Sonderfeld  writes:
>
>> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
>>> Anyway, I don't think this is a good idea to introduce a new syntax just
>>> to avoid a one-liner (or a hook, see below). Also, this would only make
>>> sense in few export back-ends.
>>
>> But is it really a new syntax or just support for an existing Emacs 
>> convention?  See (info "(emacs) Pages").
>>
>> It seems like a feature which could be supported in many back-ends: LaTeX, 
>> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.
>
> I do not question this.
>
> My point is that introducing this new syntax would bring up nothing that
> can already be achieved using filters or hooks.
>
> So, is this feature a must-have? Or would a filter template in Worg more
> appropriate in this case?

It's not that everyone is desperate to have this in org proper. Putting
it into the code base vs making a hook: my guess is the number of LOC
would be very nearly exactly the same, and there's literally no
practical difference in the result. When "why" and "why not" are
perfectly balanced, it may be better to do nothing.

But I think it just *feels* right, because the page delimiter already
seems like a first-class citizen in emacs. I'll admit it's also
partially because it's a control character. Control character! Must be
serious programming. I also like the thought of a new org user sticking
one in their document, exporting, and finding that org does the right
thing.

At this point, I'm pretty much neutral buoyancy on the issue, though...

Eric

Re: [O] [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Rüdiger Sonderfeld  writes:

> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
>> Anyway, I don't think this is a good idea to introduce a new syntax just
>> to avoid a one-liner (or a hook, see below). Also, this would only make
>> sense in few export back-ends.
>
> But is it really a new syntax or just support for an existing Emacs 
> convention?  See (info "(emacs) Pages").
>
> It seems like a feature which could be supported in many back-ends: LaTeX, 
> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.

I do not question this.

My point is that introducing this new syntax would bring up nothing that
can already be achieved using filters or hooks.

So, is this feature a must-have? Or would a filter template in Worg more
appropriate in this case?


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Re: \newpage in HTML export

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> Here's a fairly simple first stab, with page breaks made into an
>> element, and a sample handling in the LaTeX backend. I've hardcoded ^L
>> and the page-delimiter regexp that finds it, not sure it's worth
>> providing an org-page-delimiter shadow. For now, use C-q C-l to insert
>> the control character.
>
> Thanks for the patch.
>
> Anyway, I don't think this is a good idea to introduce a new syntax just
> to avoid a one-liner (or a hook, see below). Also, this would only make
> sense in few export back-ends.
>
> Really, introducing new syntax has a cost, so you have to ponder if it's
> really useful, because, once installed, every Org user will have to pay
> the price for it.
>
> In the same vein, we have a couple of dubious syntactical elements which
> probably sound great for a few users but don't make much sense in most
> cases (e.g. quote sections, which can be replaced with an example(!)
> block and comments blocks, which can be replaced with a regular
> comment).
>
> Admittedly, in this particular case, that cost isn't very high, but
> I think it would nonetheless add up to the list of hardly-used syntax
> category.
>
>> If this passes muster I can go through the other backends and add
>> page-break handling where it makes sense. If not, I'll just keep it on
>> my local branch!
>
> You don't need such a patch. For example, you can install the following:
>
>   (defun my-page-delimiter-hook (backend)
> (while (re-search-forward page-delimiter nil t)
>   (replace-match
>(cond
> ((org-export-derived-backend-p backend 'latex)
>  "#+LATEX: newpage")
> ((org-export-derived-backend-p backend 'html)
>  "#+HTML:  ")
> ;; Ignore page delimiters in other back-ends.
> (t "")
>
>   (add-hook 'org-export-before-parsing-hook 'my-page-delimiter-hook)
>
> Obviously, you can handle as many back-ends as you see fit in
> `my-page-delimiter-hook'.
>
> Here are a few comments about the code:
>
>>  (defconst org-element-all-objects
>>'(bold code entity export-snippet footnote-reference inline-babel-call
>> - inline-src-block italic line-break latex-fragment link macro
>> + inline-src-block italic line-break latex-fragment link macro page-break
>>   radio-target statistics-cookie strike-through subscript superscript
>>   table-cell target timestamp underline verbatim)
>>"Complete list of object types.")
>
> Since `page-break' is an element type, you cannot make it also an object
> type.
>
> Also, you would need to update `org-element-paragraph-separate' regexp.
>
>>  (defun org-element-paragraph-parser (limit affiliated)
>> @@ -3845,6 +3879,8 @@ element it has to parse."
>>   ;; Horizontal Rule.
>>   ((looking-at "[ \t]*-\\{5,\\}[ \t]*$")
>>(org-element-horizontal-rule-parser limit affiliated))
>> + ((looking-at page-delimiter)
>> +  (org-element-page-break-parser limit affiliated))
>
> Using `page-delimiter' is not desirable because it implies that its
> syntax is customizable, which would go against the last syntax patches
> (changing defcustoms into defconsts whenever possible). Customizable
> syntax cripples portability: please use it with care.

No worries, I'm not terribly married to this, and I do think I do more
multiple-backend export than is the norm. I appreciate the code notes --
I'll admit I was a tiny bit confused about the difference between
element and object. I also wavered between making it a hard-coded
defconst or a fully customizable option, and landed awkwardly in
between.

A hook will probably do me.

Thanks,
Eric

Re: [O] [PATCH] Re: \newpage in HTML export

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> Here's a fairly simple first stab, with page breaks made into an
>> element, and a sample handling in the LaTeX backend. I've hardcoded ^L
>> and the page-delimiter regexp that finds it, not sure it's worth
>> providing an org-page-delimiter shadow. For now, use C-q C-l to insert
>> the control character.
>
> Thanks for the patch.
>
> Anyway, I don't think this is a good idea to introduce a new syntax just
> to avoid a one-liner (or a hook, see below). Also, this would only make
> sense in few export back-ends.
>
> Really, introducing new syntax has a cost, so you have to ponder if it's
> really useful, because, once installed, every Org user will have to pay
> the price for it.
>
> In the same vein, we have a couple of dubious syntactical elements which
> probably sound great for a few users but don't make much sense in most
> cases (e.g. quote sections, which can be replaced with an example(!)
> block and comments blocks, which can be replaced with a regular
> comment).
>
> Admittedly, in this particular case, that cost isn't very high, but
> I think it would nonetheless add up to the list of hardly-used syntax
> category.
>
>> If this passes muster I can go through the other backends and add
>> page-break handling where it makes sense. If not, I'll just keep it on
>> my local branch!
>
> You don't need such a patch. For example, you can install the following:
>
>   (defun my-page-delimiter-hook (backend)
> (while (re-search-forward page-delimiter nil t)
>   (replace-match
>(cond
> ((org-export-derived-backend-p backend 'latex)
>  "#+LATEX: newpage")
> ((org-export-derived-backend-p backend 'html)
>  "#+HTML:  ")
> ;; Ignore page delimiters in other back-ends.
> (t "")
>
>   (add-hook 'org-export-before-parsing-hook 'my-page-delimiter-hook)
>
> Obviously, you can handle as many back-ends as you see fit in
> `my-page-delimiter-hook'.
>
> Here are a few comments about the code:
>
>>  (defconst org-element-all-objects
>>'(bold code entity export-snippet footnote-reference inline-babel-call
>> - inline-src-block italic line-break latex-fragment link macro
>> + inline-src-block italic line-break latex-fragment link macro page-break
>>   radio-target statistics-cookie strike-through subscript superscript
>>   table-cell target timestamp underline verbatim)
>>"Complete list of object types.")
>
> Since `page-break' is an element type, you cannot make it also an object
> type.
>
> Also, you would need to update `org-element-paragraph-separate' regexp.
>
>>  (defun org-element-paragraph-parser (limit affiliated)
>> @@ -3845,6 +3879,8 @@ element it has to parse."
>>   ;; Horizontal Rule.
>>   ((looking-at "[ \t]*-\\{5,\\}[ \t]*$")
>>(org-element-horizontal-rule-parser limit affiliated))
>> + ((looking-at page-delimiter)
>> +  (org-element-page-break-parser limit affiliated))
>
> Using `page-delimiter' is not desirable because it implies that its
> syntax is customizable, which would go against the last syntax patches
> (changing defcustoms into defconsts whenever possible). Customizable
> syntax cripples portability: please use it with care.

No worries, I'm not terribly married to this, and I do think I do more
multiple-backend export than is the norm. I appreciate the code notes --
I'll admit I was a tiny bit confused about the difference between
element and object. I also wavered between making it a hard-coded
defconst or a fully customizable option, and landed awkwardly in
between.

A hook will probably do me.

Thanks,Eric

Re: [O] [PATCH] Re: \newpage in HTML export

[Rüdiger Sonderfeld]

On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
> Anyway, I don't think this is a good idea to introduce a new syntax just
> to avoid a one-liner (or a hook, see below). Also, this would only make
> sense in few export back-ends.

But is it really a new syntax or just support for an existing Emacs 
convention?  See (info "(emacs) Pages").

It seems like a feature which could be supported in many back-ends: LaTeX, 
ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.

Regards,
Rüdiger

Re: [O] [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> Here's a fairly simple first stab, with page breaks made into an
> element, and a sample handling in the LaTeX backend. I've hardcoded ^L
> and the page-delimiter regexp that finds it, not sure it's worth
> providing an org-page-delimiter shadow. For now, use C-q C-l to insert
> the control character.

Thanks for the patch.

Anyway, I don't think this is a good idea to introduce a new syntax just
to avoid a one-liner (or a hook, see below). Also, this would only make
sense in few export back-ends.

Really, introducing new syntax has a cost, so you have to ponder if it's
really useful, because, once installed, every Org user will have to pay
the price for it.

In the same vein, we have a couple of dubious syntactical elements which
probably sound great for a few users but don't make much sense in most
cases (e.g. quote sections, which can be replaced with an example(!)
block and comments blocks, which can be replaced with a regular
comment).

Admittedly, in this particular case, that cost isn't very high, but
I think it would nonetheless add up to the list of hardly-used syntax
category.

> If this passes muster I can go through the other backends and add
> page-break handling where it makes sense. If not, I'll just keep it on
> my local branch!

You don't need such a patch. For example, you can install the following:

  (defun my-page-delimiter-hook (backend)
(while (re-search-forward page-delimiter nil t)
  (replace-match
   (cond
((org-export-derived-backend-p backend 'latex)
 "#+LATEX: newpage")
((org-export-derived-backend-p backend 'html)
 "#+HTML:  ")
;; Ignore page delimiters in other back-ends.
(t "")

  (add-hook 'org-export-before-parsing-hook 'my-page-delimiter-hook)

Obviously, you can handle as many back-ends as you see fit in
`my-page-delimiter-hook'.

Here are a few comments about the code:

>  (defconst org-element-all-objects
>'(bold code entity export-snippet footnote-reference inline-babel-call
> -  inline-src-block italic line-break latex-fragment link macro
> +  inline-src-block italic line-break latex-fragment link macro page-break
>radio-target statistics-cookie strike-through subscript superscript
>table-cell target timestamp underline verbatim)
>"Complete list of object types.")

Since `page-break' is an element type, you cannot make it also an object
type.

Also, you would need to update `org-element-paragraph-separate' regexp.

>  (defun org-element-paragraph-parser (limit affiliated)
> @@ -3845,6 +3879,8 @@ element it has to parse."
>;; Horizontal Rule.
>((looking-at "[ \t]*-\\{5,\\}[ \t]*$")
> (org-element-horizontal-rule-parser limit affiliated))
> +  ((looking-at page-delimiter)
> +   (org-element-page-break-parser limit affiliated))

Using `page-delimiter' is not desirable because it implies that its
syntax is customizable, which would go against the last syntax patches
(changing defcustoms into defconsts whenever possible). Customizable
syntax cripples portability: please use it with care.


Regards,

-- 
Nicolas Goaziou