Re: [O] [RFC] Draft mode

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> That sounds awesome, though I haven't had time to test it yet.

Patch pushed to master, along with documentation and tests.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Draft mode

[Rasmus]

Nicolas Goaziou  writes:

> Here's another take on this, which is quite different from the original
> draft mode. Now, behaviour on broken links is controlled with
> `org-export-with-broken-links' or its OPTIONS counterpart
> "broken-links".
>
> It is possible to either error on a broken link, ignore it, or mark it
> with an obnoxious string in the output.
>
>
> Feedback welcome.

That sounds awesome, though I haven't had time to test it yet.

Thanks,
Rasmus

-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

Re: [O] [RFC] Draft mode

[Nicolas Goaziou]

Rasmus  writes:

> While I agree that options such as 't:·', '^:·', 'h:·' are bad, I think
> 'barf:·' is nice.  It's short and precise, much like 'num:·'.
>
> Something like 'barf-on-invalid-link' is very easy to mistype or forget.
> And yes, I mostly type options by hand.

Here's another take on this, which is quite different from the original
draft mode. Now, behaviour on broken links is controlled with
`org-export-with-broken-links' or its OPTIONS counterpart
"broken-links".

It is possible to either error on a broken link, ignore it, or mark it
with an obnoxious string in the output.


Feedback welcome.


Regards,

>From 0508461b2d57629e1c391c57a7326093f61b07e6 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Sat, 10 Oct 2015 16:03:05 +0200
Subject: [PATCH] ox: Add an option to ignore broken links

* lisp/ox.el (org-export-with-broken-links): New variable.
(org-export-options-alist): Add new OPTIONS item.
(broken-link): New error type.
(org-export-resolve-coderef):
(org-export-resolve-fuzzy-link):
(org-export-resolve-id-link): Raise appropriate error symbol when a link
cannot be resolved.
(org-export-data): Handle new error type.
---
 lisp/ox.el | 221 -
 1 file changed, 132 insertions(+), 89 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index d140f17..d74f48b 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -112,6 +112,7 @@
 (:time-stamp-file nil "timestamp" org-export-time-stamp-file)
 (:with-archived-trees nil "arch" org-export-with-archived-trees)
 (:with-author nil "author" org-export-with-author)
+(:with-broken-links nil "broken-links" org-export-with-broken-links)
 (:with-clocks nil "c" org-export-with-clocks)
 (:with-creator nil "creator" org-export-with-creator)
 (:with-date nil "date" org-export-with-date)
@@ -797,6 +798,27 @@ is nil.  You can also allow them through local buffer variables."
   :package-version '(Org . "8.0")
   :type 'boolean)
 
+(defcustom org-export-with-broken-links nil
+  "Non-nil means do not raise an error on broken links.
+
+When this variable is non-nil, broken links are ignored, without
+stopping the export process.  If it is set to `mark', broken
+links are marked as such in the output, with a string like
+
+  [BROKEN LINK: path]
+
+where PATH is the un-resolvable reference.
+
+This option can also be set with the OPTIONS keyword, e.g.,
+\"broken-links:mark\"."
+  :group 'org-export-general
+  :version "25.1"
+  :package-version '(Org . "8.4")
+  :type '(choice
+	  (const :tag "Ignore broken links" t)
+	  (const :tag "Mark broken links in output" mark)
+	  (const :tag "Raise an error" nil)))
+
 (defcustom org-export-snippet-translation-alist nil
   "Alist between export snippets back-ends and exporter back-ends.
 
@@ -1851,91 +1873,106 @@ string.  INFO is a plist holding export options.
 
 Return a string."
   (or (gethash data (plist-get info :exported-data))
-  (let* ((type (org-element-type data))
-	 (results
-	  (cond
-	   ;; Ignored element/object.
-	   ((memq data (plist-get info :ignore-list)) nil)
-	   ;; Plain text.
-	   ((eq type 'plain-text)
-		(org-export-filter-apply-functions
-		 (plist-get info :filter-plain-text)
-		 (let ((transcoder (org-export-transcoder data info)))
-		   (if transcoder (funcall transcoder data info) data))
-		 info))
-	   ;; Secondary string.
-	   ((not type)
-		(mapconcat (lambda (obj) (org-export-data obj info)) data ""))
-	   ;; Element/Object without contents or, as a special
-	   ;; case, headline with archive tag and archived trees
-	   ;; restricted to title only.
-	   ((or (not (org-element-contents data))
-		(and (eq type 'headline)
-			 (eq (plist-get info :with-archived-trees) 'headline)
-			 (org-element-property :archivedp data)))
-		(let ((transcoder (org-export-transcoder data info)))
-		  (or (and (functionp transcoder)
-			   (funcall transcoder data nil info))
-		  ;; Export snippets never return a nil value so
-		  ;; that white spaces following them are never
-		  ;; ignored.
-		  (and (eq type 'export-snippet) ""
-	   ;; Element/Object with contents.
-	   (t
-		(let ((transcoder (org-export-transcoder data info)))
-		  (when transcoder
-		(let* ((greaterp (memq type org-element-greater-elements))
-			   (objectp
-			(and (not greaterp)
- (memq type org-element-recursive-objects)))
-			   (contents
-			(mapconcat
-			 (lambda (element) (org-export-data element info))
-			 (org-element-contents
-			  (if (or greaterp objectp) data
-;; Elements directly containing
-;; objects must have their indentation
-;; normalized first.
-(org-element-normalize-contents
- data
- ;; When normalizing contents of the
- ;; first paragraph in an item or
- ;; a footnote definition, ignore
- ;; first line's indentation: there is
- ;; none and it might 

Re: [O] [RFC] Draft mode

[Rasmus]

Nick Dokos  writes:

> Eric S Fraga  writes:
>
>> On Thursday,  8 Oct 2015 at 19:00, Nicolas Goaziou wrote:
>>
>> [...]
>>
>>> I think I will go with the straight to the point
>>> `org-export-barf-on-invalid-link' variable.
>>>
>>> However, not sure about the OPTIONS item.
>>>
>>>   #+OPTIONS: ???:t
>>
>> #+options: barf:t
>>
>> ;-)
>>
>> More seriously, I'm a big fan of longer is better if more clear so how
>> about "invalidlinksok:t" or "allowdanglinglinks:t" or some variation
>> thereof?
>
> Can option names contain dashes?
> If so, combine these two ideas to make a name as similar as possible
> to the variable name:
>
> #+options: barf-on-invalid-link:t

While I agree that options such as 't:·', '^:·', 'h:·' are bad, I think
'barf:·' is nice.  It's short and precise, much like 'num:·'.

Something like 'barf-on-invalid-link' is very easy to mistype or forget.
And yes, I mostly type options by hand.

Rasmus

-- 
Got mashed potatoes. Ain't got no T-Bone. No T-Bone

Re: [O] [RFC] Draft mode

[Rasmus]

Hi,

>> Can this just be a variable set by BIND or publish?
>
> It could. If we keep throwing errors on unknown macros, I think we can
> even have an OPTIONS item.

I would be happier with this, I think.

>> The interest of such functionality seems to be limited to people who
>> maintain broken-but-soon-to-be-fixed documents... It does not seem to
>> warrant prime real estate in the exporter IMO. Further, I don't think
>> 'draft' is the correct word for this, but that's of course minor.
>
> I couldn't find anything better. Suggestions welcome.

I agree.  We already have the org-latex-classes, which a very different
from latex-proper classes.  This seems to cause a lot of confusion.
Perhaps we can limit such overlap in the future.

It’s a "relaxed" mode.  I’m not sure what a good term for this is.

Rasmus

-- 
Governments should be afraid of their people

Re: [O] [RFC] Draft mode

[Eric Abrahamsen]

Thomas S. Dye  writes:

> Rasmus  writes:
>
 The interest of such functionality seems to be limited to people who
 maintain broken-but-soon-to-be-fixed documents... It does not seem to
 warrant prime real estate in the exporter IMO. Further, I don't think
 'draft' is the correct word for this, but that's of course minor.
>>>
>>> I couldn't find anything better. Suggestions welcome.
>>
>> I agree.  We already have the org-latex-classes, which a very different
>> from latex-proper classes.  This seems to cause a lot of confusion.
>> Perhaps we can limit such overlap in the future.
>>
>> It’s a "relaxed" mode.  I’m not sure what a good term for this is.
>
> Trial mode?

Dry run?

Re: [O] [RFC] Draft mode

[Rasmus]

Thomas S. Dye  writes:

 The interest of such functionality seems to be limited to people who
 maintain broken-but-soon-to-be-fixed documents... It does not seem to
 warrant prime real estate in the exporter IMO. Further, I don't think
 'draft' is the correct word for this, but that's of course minor.
>>>
>>> I couldn't find anything better. Suggestions welcome.
>>
>> I agree.  We already have the org-latex-classes, which a very different
>> from latex-proper classes.  This seems to cause a lot of confusion.
>> Perhaps we can limit such overlap in the future.
>>
>> It’s a "relaxed" mode.  I’m not sure what a good term for this is.
>
> Trial mode?

The latex flag would be "-interaction=nonstopmode".  Probably a similar
flag exits in GCC.
The Knitr option is simply called error ∈ {TRUE, FALSE}.

I like nonstopmode, but I don’t care particularly for the "interaction"
classification.

Rasmus

-- 
Governments should be afraid of their people

Re: [O] [RFC] Draft mode

[Thomas S . Dye]

Rasmus  writes:

>>> The interest of such functionality seems to be limited to people who
>>> maintain broken-but-soon-to-be-fixed documents... It does not seem to
>>> warrant prime real estate in the exporter IMO. Further, I don't think
>>> 'draft' is the correct word for this, but that's of course minor.
>>
>> I couldn't find anything better. Suggestions welcome.
>
> I agree.  We already have the org-latex-classes, which a very different
> from latex-proper classes.  This seems to cause a lot of confusion.
> Perhaps we can limit such overlap in the future.
>
> It’s a "relaxed" mode.  I’m not sure what a good term for this is.

Trial mode?

hth,
Tom

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

Re: [O] [RFC] Draft mode

[Nick Dokos]

Eric S Fraga  writes:

> On Thursday,  8 Oct 2015 at 19:00, Nicolas Goaziou wrote:
>
> [...]
>
>> I think I will go with the straight to the point
>> `org-export-barf-on-invalid-link' variable.
>>
>> However, not sure about the OPTIONS item.
>>
>>   #+OPTIONS: ???:t
>
> #+options: barf:t
>
> ;-)
>
> More seriously, I'm a big fan of longer is better if more clear so how
> about "invalidlinksok:t" or "allowdanglinglinks:t" or some variation
> thereof?

Can option names contain dashes?
If so, combine these two ideas to make a name as similar as possible
to the variable name:

#+options: barf-on-invalid-link:t

But I suspect that dashes are not allowed.

--
Nick

Re: [O] [RFC] Draft mode

[Nicolas Goaziou]

Thomas S. Dye  writes:

> Rasmus  writes:
>
 The interest of such functionality seems to be limited to people who
 maintain broken-but-soon-to-be-fixed documents... It does not seem to
 warrant prime real estate in the exporter IMO. Further, I don't think
 'draft' is the correct word for this, but that's of course minor.
>>>
>>> I couldn't find anything better. Suggestions welcome.
>>
>> I agree.  We already have the org-latex-classes, which a very different
>> from latex-proper classes.  This seems to cause a lot of confusion.
>> Perhaps we can limit such overlap in the future.
>>
>> It’s a "relaxed" mode.  I’m not sure what a good term for this is.
>
> Trial mode?

I think I will go with the straight to the point
`org-export-barf-on-invalid-link' variable.

However, not sure about the OPTIONS item.

  #+OPTIONS: ???:t

Regards,

Re: [O] [RFC] Draft mode

[Eric S Fraga]

On Thursday,  8 Oct 2015 at 19:00, Nicolas Goaziou wrote:

[...]

> I think I will go with the straight to the point
> `org-export-barf-on-invalid-link' variable.
>
> However, not sure about the OPTIONS item.
>
>   #+OPTIONS: ???:t

#+options: barf:t

;-)

More seriously, I'm a big fan of longer is better if more clear so how
about "invalidlinksok:t" or "allowdanglinglinks:t" or some variation
thereof?

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-161-gd2ac25

Re: [O] [RFC] Draft mode

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> Can this just be a variable set by BIND or publish?

It could. If we keep throwing errors on unknown macros, I think we can
even have an OPTIONS item.

> The interest of such functionality seems to be limited to people who
> maintain broken-but-soon-to-be-fixed documents... It does not seem to
> warrant prime real estate in the exporter IMO. Further, I don't think
> 'draft' is the correct word for this, but that's of course minor.

I couldn't find anything better. Suggestions welcome.

Thank you for the feedback.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Draft mode

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> 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?

I'd like to avoid defun* as much as possible, because it may be harder
to read. This is also the reason why it wasn't included in core Elisp.

> On a different note, does this scheme make it possible for a backend
> to see whether draft mode is enabled?

It is possible with

  (memq 'draft (plist-get info :export-options))

However, Rasmus suggested to give up the export option and use a global
variable, instead.

> 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.

It was also suggested that "draft" wasn't the most accurate description
for this option. So, ultimately, it might not be related to LaTeX option
"draft".

Thank you for the feedback.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Draft mode

[Aaron Ecay]

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  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 `' 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  subtreep visible-only body-only ext-plist)

to (using cl-defun):

(backend  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 ( 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 ( 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

Re: [O] [RFC] Draft mode

[Nicolas Goaziou]

Nicolas Goaziou  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.
>
> This patch is incomplete as it is missing some documentation, an entry
> in ORG-NEWS and some tests. Also, export back-end in contrib/ directory
> are not updated yet. In any case, feedback welcome.
>
> It is meant to be applied on top of master branch.

And, here's a first update.

>From bae307895b934328f10f003758446b11cbc13beb Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Sun, 27 Sep 2015 10:59:20 +0200
Subject: [PATCH] ox: Implement draft mode

* lisp/ox.el (org-export-as-draft): New variable.
(org-export-dispatch-use-expert-ui): Document new export option.
(org-export-data): Ignore user errors when in draft mode.
(org-export-as): Add new optional argument to toggle draft mode. Ignore
unknown macros.
(org-export-string-as):
(org-export-to-buffer):
(org-export-to-file): Handle signature change.
(org-export-dispatch):
(org-export--dispatch-ui):
(org-export--dispatch-action): Provide a mean to toggle draft mode.

* lisp/ox-ascii.el (ascii):
(org-ascii-export-as-ascii):
(org-ascii-export-to-ascii):

* lisp/ox-beamer.el (beamer):
(org-beamer-export-as-latex):
(org-beamer-export-to-latex):
(org-beamer-export-to-pdf):

* lisp/ox-html.el (html):
(org-html-export-as-html):

* lisp/ox-icalendar.el (icalendar):

* lisp/ox-latex.el (latex):
(org-latex-export-as-latex):
(org-latex-export-to-latex):
(org-latex-export-to-pdf):

* lisp/ox-man.el (man):
(org-man-export-to-man):
(org-man-export-to-pdf):

* lisp/ox-md.el (md):
(org-md-export-as-markdown):
(org-md-export-to-markdown):

* lisp/ox-odt.el (odt):
(org-odt-export-to-odt):

* lisp/ox-org.el (org):
(org-org-export-to-org):

* lisp/ox-publish.el (org-publish-org-to):

* lisp/ox-texinfo.el (texinfo):
(org-texinfo-export-to-texinfo):
(org-texinfo-export-to-info): Handle signature change.

* testing/lisp/test-ox.el (test-org-export/handle-options):
(test-org-export/with-timestamps):
(test-org-export/uninterpreted):
(test-org-export/expand-macro):
(test-org-export/footnote-first-reference-p):
(test-org-export/handle-inlinetasks): Update tests.
---
 lisp/ox-ascii.el|  39 +++---
 lisp/ox-beamer.el   |  21 +++-
 lisp/ox-html.el |  11 +-
 lisp/ox-icalendar.el|   4 +-
 lisp/ox-latex.el|  26 ++--
 lisp/ox-man.el  |  16 ++-
 lisp/ox-md.el   |  25 ++--
 lisp/ox-odt.el  |  21 ++--
 lisp/ox-org.el  |  13 +-
 lisp/ox-publish.el  |   2 +-
 lisp/ox-texinfo.el  |  20 ++--
 lisp/ox.el  | 311 
 testing/lisp/test-ox.el | 123 +--
 13 files changed, 376 insertions(+), 256 deletions(-)

diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index 5cc70bd..b50cebb 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -97,23 +97,23 @@
   :menu-entry
   '(?t "Export to Plain Text"
((?A "As ASCII buffer"
-	(lambda (a s v b)
-	  (org-ascii-export-as-ascii a s v b '(:ascii-charset ascii
+	(lambda (a s v b d)
+	  (org-ascii-export-as-ascii a s v b d '(:ascii-charset ascii
 	(?a "As ASCII file"
-	(lambda (a s v b)
-	  (org-ascii-export-to-ascii a s v b '(:ascii-charset ascii
+	(lambda (a s v b d)
+	  (org-ascii-export-to-ascii a s v b d '(:ascii-charset ascii
 	(?L "As Latin1 buffer"
-	(lambda (a s v b)
-	  (org-ascii-export-as-ascii a s v b '(:ascii-charset latin1
+	(lambda (a s v b d)
+	  (org-ascii-export-as-ascii a s v b d '(:ascii-charset latin1
 	(?l "As Latin1 file"
-	(lambda (a s v b)
-	  (org-ascii-export-to-ascii a s v b '(:ascii-charset latin1
+	(lambda (a s v b d)
+	  (org-ascii-export-to-ascii a s v b d '(:ascii-charset latin1
 	(?U "As UTF-8 buffer"
-	(lambda (a s v b)
-	  (org-ascii-export-as-ascii a s v b '(:ascii-charset utf-8
+	(lambda (a s v b d)
+	  (org-ascii-export-as-ascii a s v b d '(:ascii-charset utf-8
 	(?u "As UTF-8 file"
-	(lambda (a s v b)
-	  (org-ascii-export-to-ascii a s v b '(:ascii-charset utf-8))
+	(lambda (a s v b d)
+	  (org-ascii-export-to-ascii a s v b d '(:ascii-charset utf-8))
   :filters-alist '((:filter-headline . org-ascii-filter-headline-blank-lines)
 		   (:filter-parse-tree org-ascii-filter-paragraph-spacing
    org-ascii-filter-comment-spacing)
@@ -2023,7 +2023,7 @@ a communication channel."
 
 ;;;###autoload
 (defun org-ascii-export-as-ascii
-  ( async subtreep visible-only body-only ext-plist)
+  ( async subtreep visible-only body-only draft ext-plist)
   "Export current buffer to a text buffer.
 
 If narrowing is active in the current 

Re: [O] [RFC] Draft mode

[Charles C. Berry]

On Sun, 27 Sep 2015, Nicolas Goaziou wrote:


Nicolas Goaziou  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 `' 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?


Chuck

Re: [O] [RFC] Draft mode

[Marcin Borkowski]

On 2015-09-27, at 20:39, Rasmus  wrote:

> Nicolas Goaziou  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.

I would welcome this feature...

> Can this just be a variable set by BIND or publish?  The interest of such
> functionality seems to be limited to people who maintain
> broken-but-soon-to-be-fixed documents...  It does not seem to warrant
> prime real estate in the exporter IMO. Further, I don't think 'draft' is
> the correct word for this, but that's of course minor.
>
>> It introduces a backward incompatible change since it modifies signature
>> from `org-export-as' and alike.
>
> Doesn't seem worth it.

...but I agree with the above.

Also, wouldn't it be even better if there were some buffer - like
(La)TeX's log file - accumulating all the errors/warnings from the
exporting process?  Then, the above behavior could be the default, but
it would produce warnings.  Or it might depend on some setting.

> Rasmus

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] [RFC] Draft mode

[Rasmus]

Nicolas Goaziou  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.

Can this just be a variable set by BIND or publish?  The interest of such
functionality seems to be limited to people who maintain
broken-but-soon-to-be-fixed documents...  It does not seem to warrant
prime real estate in the exporter IMO. Further, I don't think 'draft' is
the correct word for this, but that's of course minor.

> It introduces a backward incompatible change since it modifies signature
> from `org-export-as' and alike.

Doesn't seem worth it.

> This patch is incomplete as it is missing some documentation, an entry
> in ORG-NEWS and some tests. Also, export back-end in contrib/ directory
> are not updated yet. In any case, feedback welcome.

I did not test it at this point.

Rasmus

-- 
Sådan en god dansk lagereddike kan man slet ikke bruge mere