[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Leha
Subject: Re: [O] [PATCH] Re: \newpage in HTML export
Date: Sun, 24 Nov 2013 14:58:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eric Abrahamsen <address@hidden> writes:

> On 11/24/13 16:31 PM, Nicolas Goaziou wrote:
>> Hello,
>> RĂ¼diger Sonderfeld <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]