From: Aaron Ecay <aaronecay@gmail.com>
To: "Charles C. Berry" <ccberry@ucsd.edu>,
Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [RFC] Draft mode
Date: Mon, 28 Sep 2015 21:56:56 +0100 [thread overview]
Message-ID: <87twqe4607.fsf@gmail.com> (raw)
In-Reply-To: <alpine.OSX.2.20.1509270920330.521@charles-berrys-macbook.local>
Hi Nicolas,
This looks like a useful addition.
2015ko irailak 27an, "Charles C. Berry"-ek idatzi zuen:
>
> On Sun, 27 Sep 2015, Nicolas Goaziou wrote:
>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>>> The following patch implements a draft mode for export. When in draft
>>> mode, invalid macros and links do not throw an error. It can be toggled
>>> with `org-export-as-draft' variable, or using C-d in export dispatch.
>>>
>>> It introduces a backward incompatible change since it modifies signature
>>> from `org-export-as' and alike.
>>>
>
> I don't get it.
>
> Why not add the `draft' arg to the end of the `&optional' args? Won't that
> preserve backward compatibility?
>
> I maintain derived backends that use the `post-process' arg and are
> distributed on github. So now I will need to make them version aware
> and/or provide version specific branches so as not to break when used with
> older org-mode versions, won't I?
This is a very good point. OTOH, if backwards compatibility is going to
be broken, wouldn’t it be better to move to a keyword argument system?
IOW, the signature of ‘org-export-as’ and friends would change from:
(backend &optional subtreep visible-only body-only ext-plist)
to (using cl-defun):
(backend &key subtreep visible-only body-only ext-plist draft)
This would allow future changes to the API of this function without
breaking backwards compatibility. It would also clean up messy
constructs like:
(lambda (a s v b d)
(if a (org-org-export-to-org t s v b d)
(org-open-file (org-org-export-to-org nil s v b d))))
which could become:
(lambda (&rest kwargs)
(if (plist-get kwargs :async)
(apply #'org-org-export-to-org kwargs)
(org-open-file (apply #'org-org-export-to-org kwargs))))
and with further simplification the following, which is vastly clearer
than the original:
(lambda (&rest kwargs)
(let ((result (apply #'org-org-export-to-org kwargs)))
(unless (plist-get kwargs :async) (org-open-file result))))
Since this stanza recurs in the code for most (all?) backends, there’s
some value that org core can provide to backend authors by making it as
simple as possible.
With a non-trivial effort, the old calling convention could still be
supported (if the argument after ‘backend’ is not a :keyword, then
org-export-as knows that the old convention is in use, and it should
map the arguments 2 through 5 to the relevant keywords). It could
trigger a deprecation warning and be phased out with the next major
version (or whenever).
On a different note, does this scheme make it possible for a backend
to see whether draft mode is enabled? Latex provides a document-level
draft option, which enables certain optimizations that speed up compile
times (for example, graphics are not read in, but are replaced with a
placeholder). It would be nice if ox-latex could emit this in the latex
code when draft mode is enabled from the org side.
Thanks,
--
Aaron Ecay
next prev parent reply other threads:[~2015-09-28 20:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-27 9:38 [RFC] Draft mode Nicolas Goaziou
2015-09-27 11:37 ` Nicolas Goaziou
2015-09-27 16:31 ` Charles C. Berry
2015-09-28 20:56 ` Aaron Ecay [this message]
2015-10-07 20:22 ` Nicolas Goaziou
2015-09-27 18:39 ` Rasmus
2015-09-27 20:01 ` Marcin Borkowski
2015-10-07 20:12 ` Nicolas Goaziou
2015-10-08 14:23 ` Rasmus
2015-10-08 16:36 ` Thomas S. Dye
2015-10-08 16:54 ` Rasmus
2015-10-08 16:57 ` Eric Abrahamsen
2015-10-08 17:00 ` Nicolas Goaziou
2015-10-08 19:38 ` Eric S Fraga
2015-10-08 20:59 ` Nick Dokos
2015-10-09 8:07 ` Rasmus
2015-10-10 14:21 ` Nicolas Goaziou
2015-10-11 12:34 ` Rasmus
2015-10-17 12:54 ` Nicolas Goaziou
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twqe4607.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=ccberry@ucsd.edu \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).