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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> 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: <div style=\"page-break-before: always\">&nbsp;</div>")
>         ;; 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