From: Andreas Leha <andreas.leha@med.uni-goettingen.de>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Re: \newpage in HTML export
Date: Sun, 24 Nov 2013 14:58:10 +0100 [thread overview]
Message-ID: <87li0dvr4d.fsf@med.uni-goettingen.de> (raw)
In-Reply-To: 87k3fym54f.fsf@ericabrahamsen.net
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> On 11/24/13 16:31 PM, Nicolas Goaziou wrote:
>> Hello,
>>
>> Rüdiger Sonderfeld <ruediger@c-plusplus.de> 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
next prev parent reply other threads:[~2013-11-24 13:58 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-20 18:52 \newpage in HTML export Luke Crook
2013-11-20 20:10 ` Dan Griswold
2013-11-20 21:15 ` Luke Crook
2013-11-20 21:20 ` Russell Adams
2013-11-20 23:36 ` Suvayu Ali
2013-11-21 1:11 ` Eric Abrahamsen
2013-11-21 2:38 ` Jambunathan K
2013-11-21 11:17 ` Suvayu Ali
2013-11-21 14:41 ` Eric Abrahamsen
2013-11-22 7:47 ` [PATCH] " Eric Abrahamsen
2013-11-22 10:24 ` Nicolas Goaziou
2013-11-22 12:50 ` Rüdiger Sonderfeld
2013-11-24 9:31 ` Nicolas Goaziou
2013-11-24 11:05 ` Eric Abrahamsen
2013-11-24 13:58 ` Andreas Leha [this message]
2013-12-22 13:49 ` Nicolas Goaziou
2013-12-22 14:08 ` Andreas Leha
2013-12-22 14:20 ` Nicolas Goaziou
2013-12-22 14:28 ` Andreas Leha
2014-01-03 15:39 ` Bastien
2014-01-03 19:29 ` Andreas Leha
2014-01-03 19:50 ` Thomas S. Dye
2014-01-03 20:10 ` Andreas Leha
2014-01-04 10:40 ` Bastien
2014-01-04 12:41 ` Andreas Leha
2014-01-04 14:07 ` Bastien
2014-01-05 20:53 ` Suvayu Ali
2014-01-06 9:42 ` Bastien
2014-01-04 19:47 ` Sebastien Vauban
2014-01-05 6:35 ` Bastien
2014-01-05 9:42 ` Sebastien Vauban
2014-01-05 10:46 ` Bastien
2013-11-24 16:39 ` Christian Moe
2013-11-23 9:28 ` Eric Abrahamsen
2013-11-23 9:28 ` Eric Abrahamsen
2013-11-25 9:55 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87li0dvr4d.fsf@med.uni-goettingen.de \
--to=andreas.leha@med.uni-goettingen.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.