Exporter aborts upon encountering even one unresolvable link

Exporter aborts upon encountering even one unresolvable link

[D. C. Toedt]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

I just updated to 8.3.1 from 8.3beta (from git).  That appears to have been
a terrible mistake on my part.

From this thread
<https://lists.gnu.org/archive/html/emacs-orgmode/2015-09/msg00040.html> I
see that the exporter now throws an error and aborts when it encounters an
unresolvable link.  That makes things really, REALLY difficult.  It means I
can't get a complete, working export to HTML (in my case) until all link
problems are fixed in my 22KLOC .org file (which I use to generate
http://www.CommonDraft.org/index.html
<http://www.commondraft.org/index.html>).  That seems EXTREMELY suboptimal.
(I'm trying to be tactful here.)

Worse, the exporter doesn't even generate a list of unresolvable links
before aborting.  That means the only way that I can find and fix busted
links (so far as I know) is to do an export --- which takes several minutes
given the large file  --- and have the export abort on a single link. Then
I fix that one link, export again, and have it abort again. Repeat.
Aaaargggggg.

I started looking at the hooks, as suggested in a message in the previous
thread, but I'm not nearly skilled enough in elisp to be able to do
anything useful.

Any suggestions?


*D. C. Toedt III  **(My last name is pronounced "Tate"; I go by "D. C.,"
which stands for Dell Charles**) *
Attorney & neutral arbitrator -- tech contracts & IP  |  Adjunct professor,
University of Houston Law Center
​Author, ​​​Common Draft <http://www.commondraft.org/> desk book of
contract clauses & research notes   |  LinkedIn: dctoedt
<http://www.linkedin.com/in/dctoedt>   |   Calendar
<https://www.google.com/calendar/embed?src=dc.toedt@toedt.com&mode=WEEK>
(redacted)
E: dc@toedt.com    O: +1 (713) 364-6545    C: +1 (713) 516-8968
​​

​
Houston, Texas (Central time zone)

Unless expressly stated otherwise, this message is not intended
to serve as assent to an agreement or other document, whether or not
attached to this message.

[-- Attachment #2: Type: text/html, Size: 7082 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[D. C. Toedt]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

P.S.:   Thank heavens for Time Machine.




On Thu, Sep 24, 2015 at 9:50 PM, D. C. Toedt <dc@toedt.com> wrote:

> I just updated to 8.3.1 from 8.3beta (from git).  That appears to have
> been a terrible mistake on my part.
>
> From this thread
> <https://lists.gnu.org/archive/html/emacs-orgmode/2015-09/msg00040.html>
> I see that the exporter now throws an error and aborts when it encounters
> an unresolvable link.  That makes things really, REALLY difficult.  It
> means I can't get a complete, working export to HTML (in my case) until all
> link problems are fixed in my 22KLOC .org file (which I use to generate
> http://www.CommonDraft.org/index.html
> <http://www.commondraft.org/index.html>).  That seems EXTREMELY
> suboptimal. (I'm trying to be tactful here.)
>
> Worse, the exporter doesn't even generate a list of unresolvable links
> before aborting.  That means the only way that I can find and fix busted
> links (so far as I know) is to do an export --- which takes several minutes
> given the large file  --- and have the export abort on a single link.
> Then I fix that one link, export again, and have it abort again. Repeat.
> Aaaargggggg.
>
> I started looking at the hooks, as suggested in a message in the previous
> thread, but I'm not nearly skilled enough in elisp to be able to do
> anything useful.
>
> Any suggestions?
>
>
> *D. C. Toedt III  **(My last name is pronounced "Tate"; I go by "D. C.,"
> which stands for Dell Charles**) *
> Attorney & neutral arbitrator -- tech contracts & IP  |  Adjunct
> professor, University of Houston Law Center
> ​Author, ​​​Common Draft <http://www.commondraft.org/> desk book of
> contract clauses & research notes   |  LinkedIn: dctoedt
> <http://www.linkedin.com/in/dctoedt>   |   Calendar
> <https://www.google.com/calendar/embed?src=dc.toedt@toedt.com&mode=WEEK>
> (redacted)
> E: dc@toedt.com    O: +1 (713) 364-6545    C: +1 (713) 516-8968
> ​​
>
> ​
> Houston, Texas (Central time zone)
>
> Unless expressly stated otherwise, this message is not intended
> to serve as assent to an agreement or other document, whether or not
> attached to this message.
>
>
>

[-- Attachment #2: Type: text/html, Size: 8050 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]

"D. C. Toedt" <dc@toedt.com> writes:

> P.S.:   Thank heavens for Time Machine.

True - but mainly for other things.


>
>
>
>
> On Thu, Sep 24, 2015 at 9:50 PM, D. C. Toedt <dc@toedt.com> wrote:
>
>> I just updated to 8.3.1 from 8.3beta (from git).  That appears to have
>> been a terrible mistake on my part.
>>
>> From this thread
>> <https://lists.gnu.org/archive/html/emacs-orgmode/2015-09/msg00040.html>
>> I see that the exporter now throws an error and aborts when it encounters
>> an unresolvable link.  That makes things really, REALLY difficult.  It
>> means I can't get a complete, working export to HTML (in my case) until all
>> link problems are fixed in my 22KLOC .org file (which I use to generate
>> http://www.CommonDraft.org/index.html
>> <http://www.commondraft.org/index.html>).  That seems EXTREMELY
>> suboptimal. (I'm trying to be tactful here.)
>>
>> Worse, the exporter doesn't even generate a list of unresolvable links
>> before aborting.  That means the only way that I can find and fix busted
>> links (so far as I know) is to do an export --- which takes several minutes
>> given the large file  --- and have the export abort on a single link.
>> Then I fix that one link, export again, and have it abort again. Repeat.
>> Aaaargggggg.
>>
>> I started looking at the hooks, as suggested in a message in the previous
>> thread, but I'm not nearly skilled enough in elisp to be able to do
>> anything useful.
>>
>> Any suggestions?
>>
>>
>> *D. C. Toedt III  **(My last name is pronounced "Tate"; I go by "D. C.,"
>> which stands for Dell Charles**) *
>> Attorney & neutral arbitrator -- tech contracts & IP  |  Adjunct
>> professor, University of Houston Law Center
>> ​Author, ​​​Common Draft <http://www.commondraft.org/> desk book of
>> contract clauses & research notes   |  LinkedIn: dctoedt
>> <http://www.linkedin.com/in/dctoedt>   |   Calendar
>> <https://www.google.com/calendar/embed?src=dc.toedt@toedt.com&mode=WEEK>
>> (redacted)
>> E: dc@toedt.com    O: +1 (713) 364-6545    C: +1 (713) 516-8968
>> ​​
>>
>> ​
>> Houston, Texas (Central time zone)
>>
>> Unless expressly stated otherwise, this message is not intended
>> to serve as assent to an agreement or other document, whether or not
>> attached to this message.
>>
>>
>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3549 bytes --]

"D. C. Toedt" <dc@toedt.com> writes:

> I just updated to 8.3.1 from 8.3beta (from git).  That appears to have been
> a terrible mistake on my part.>
> From this thread
> <https://lists.gnu.org/archive/html/emacs-orgmode/2015-09/msg00040.html> I
> see that the exporter now throws an error and aborts when it encounters an
> unresolvable link.  That makes things really, REALLY difficult.  It means I
> can't get a complete, working export to HTML (in my case) until all link
> problems are fixed in my 22KLOC .org file (which I use to generate
> http://www.CommonDraft.org/index.html
> <http://www.commondraft.org/index.html>).  That seems EXTREMELY suboptimal.
> (I'm trying to be tactful here.)

See the thread 
,----
|  Bug: Export to html fails when link to header in non existing file in
|  document present WAS: Error export to html - "Org-publish-cache-get:
|  `org-publish-cache-get' called, but no cache present" [8.3beta
|  (release_8.3beta-1115-g8f3946 @
|  /Users/rainerkrug/.emacs.d/org-mode/lisp/)]
`----

For further details.

>
> Worse, the exporter doesn't even generate a list of unresolvable links
> before aborting.  That means the only way that I can find and fix busted
> links (so far as I know) is to do an export --- which takes several minutes
> given the large file  --- and have the export abort on a single link. Then
> I fix that one link, export again, and have it abort again. Repeat.
> Aaaargggggg.

You can use org-lint for this.

>
> I started looking at the hooks, as suggested in a message in the previous
> thread, but I'm not nearly skilled enough in elisp to be able to do
> anything useful.

Look at publishing instead of exporting to html which works with
missing links.

I have the following in my emacs.org which makes it possible to publish
all org files to html in the folder ./pubHTML/ which is equivalent to
exporting.

#+begin_src emacs-lisp 
(setq org-publish-project-alist
      '(
        ("local"
         :base-directory "./"
         :base-extension "org"
         :publishing-directory "./pubHTML/"
         :recursive t
         :publishing-function org-html-publish-to-html
         :headline-levels 6
         :auto-preamble t)
        ))
#+end_src

Cheers,

Rainer

>
> Any suggestions?
>
>
> *D. C. Toedt III  **(My last name is pronounced "Tate"; I go by "D. C.,"
> which stands for Dell Charles**) *
> Attorney & neutral arbitrator -- tech contracts & IP  |  Adjunct professor,
> University of Houston Law Center
> ​Author, ​​​Common Draft <http://www.commondraft.org/> desk book of
> contract clauses & research notes   |  LinkedIn: dctoedt
> <http://www.linkedin.com/in/dctoedt>   |   Calendar
> <https://www.google.com/calendar/embed?src=dc.toedt@toedt.com&mode=WEEK>
> (redacted)
> E: dc@toedt.com    O: +1 (713) 364-6545    C: +1 (713) 516-8968
> ​​
>
> ​
> Houston, Texas (Central time zone)
>
> Unless expressly stated otherwise, this message is not intended
> to serve as assent to an agreement or other document, whether or not
> attached to this message.

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[Suvayu Ali]

On Fri, Sep 25, 2015 at 09:04:29AM +0200, Rainer M Krug wrote:
> 
> Look at publishing instead of exporting to html which works with
> missing links.

That sounds a bit fishy.  AFAIK, ox-publish just wraps around the usual
org-export-as functions from ox.el.  I could be wrong of course.

-- 
Suvayu

Open source is the future. It sets us free.

Re: Exporter aborts upon encountering even one unresolvable link

[D. C. Toedt]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

To the org-mode maintainers (all praise and thanks to them, incidentally):
 Is there any chance that this can be made into a per-file configuration
#+OPTION?  No doubt the publishing approach suggested by Rainer (thanks
also to him for suggesting it) would work, but it would take some effort to
get it set up; I've looked into publishing on previous occasions and
concluded it was easier just to do a simple HTML export.  Other things
being equal, #+OPTION options would be easier for non-expert users such as
me to work with, than fiddling with the .emacs file.

D. C. Toedt III
*(My last name is pronounced "Tate")*
Attorney & arbitrator -- tech contracts & IP
Common Draft <http://www.CommonDraft.org> contracts project
O: +1 (713) 364-6545
C: +1 (713) 516-8968
​​

dc@toedt.com
www.OnContracts.com/About

Unless expressly stated otherwise,
this message is not intended to serve
as assent to an agreement or other document,
even if attached to this message.


On Fri, Sep 25, 2015 at 12:04 AM, Rainer M Krug <Rainer@krugs.de> wrote:

[portions omitted]​​



> ​​
> Look at publishing instead of exporting to html which works with
> ​​
> missing links.
> ​​
>
> ​​
> I have the following in my emacs.org which makes it possible to publish
> all org files to html in the folder ./pubHTML/ which is equivalent to
> exporting.
>
> #+begin_src emacs-lisp
> (setq org-publish-project-alist
>       '(
>         ("local"
>          :base-directory "./"
>          :base-extension "org"
>          :publishing-directory "./pubHTML/"
>          :recursive t
>          :publishing-function org-html-publish-to-html
>          :headline-levels 6
>          :auto-preamble t)
>         ))
> #+end_src
>
>
>

[-- Attachment #2: Type: text/html, Size: 6373 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2855 bytes --]

"D. C. Toedt" <dc@toedt.com> writes:

> To the org-mode maintainers (all praise and thanks to them, incidentally):
>  Is there any chance that this can be made into a per-file configuration
> #+OPTION?  No doubt the publishing approach suggested by Rainer (thanks
> also to him for suggesting it) would work, but it would take some effort to
> get it set up; I've looked into publishing on previous occasions and
> concluded it was easier just to do a simple HTML export.

Partly true.

If you add

#+begin_src emacs-lisp 
(setq org-publish-project-alist
      '(
        ("local"
         :base-directory "./"
         :base-extension "org"
         :publishing-directory "./pubHTML/"
         :recursive t
         :publishing-function org-html-publish-to-html
         :headline-levels 6
         :auto-preamble t)
        ))
#+end_src

to your emacs.el file you will have the publishing into a subdirectory
called "./pubHTML/" in the current directory.

Cheers,

Rainer

> Other things
> being equal, #+OPTION options would be easier for non-expert users such as
> me to work with, than fiddling with the .emacs file.
>
> D. C. Toedt III
> *(My last name is pronounced "Tate")*
> Attorney & arbitrator -- tech contracts & IP
> Common Draft <http://www.CommonDraft.org> contracts project
> O: +1 (713) 364-6545
> C: +1 (713) 516-8968
> ​​
>
> dc@toedt.com
> www.OnContracts.com/About
>
> Unless expressly stated otherwise,
> this message is not intended to serve
> as assent to an agreement or other document,
> even if attached to this message.
>
>
> On Fri, Sep 25, 2015 at 12:04 AM, Rainer M Krug <Rainer@krugs.de> wrote:
>
> [portions omitted]​​
>
>
>
>> ​​
>> Look at publishing instead of exporting to html which works with
>> ​​
>> missing links.
>> ​​
>>
>> ​​
>> I have the following in my emacs.org which makes it possible to publish
>> all org files to html in the folder ./pubHTML/ which is equivalent to
>> exporting.
>>
>> #+begin_src emacs-lisp
>> (setq org-publish-project-alist
>>       '(
>>         ("local"
>>          :base-directory "./"
>>          :base-extension "org"
>>          :publishing-directory "./pubHTML/"
>>          :recursive t
>>          :publishing-function org-html-publish-to-html
>>          :headline-levels 6
>>          :auto-preamble t)
>>         ))
>> #+end_src
>>
>>
>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[D. C. Toedt]

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

>> Look at publishing instead of exporting to html which works with missing
links.
​​

Apparently it doesn't.
I'm still having the same problem of throwing a fatal error --- even when
publishing, not exporting --- when encountering a missing (unresolvable)
link.  This was after doing a clean install of org-mode 8.3.2 (20151005,
using the emacs package manager) on top of a clean install of the latest
stable version of emacs (24.5) from EmacsForMacOSX. (I'm running the latest
version of Mac OS X Yosemite; haven't gotten around to El Capitan.)  I then
set up publishing the way Rainer suggested in his email.  Well, publishing
likewise throws an error when it encounters a missing link target, just as
does exporting.

> You can use org-lint for this.

I haven't tried org-lint yet (
http://steve.planetbarr.com/posts/2015-08-11-org-lint.html).  That requires
building org from a separate branch in git.  That makes me nervous -- I'm a
user, not a dev, and while I'm sort of familiar with git, it seems like yet
another layer of complexity.

I don't mean to be a nag, but I genuinely don't understand why org-mode's
former way of dealing with unresolvable links during export was disabled.
The old way, namely just marking the problem link in the output file and
continuing with the export, made it very easy to search for the problem in
the output file. That approach was simple and worked quite well.  It also
allowed exporting a single .org file, instead of jumping through the hoops
of publishing a project.  The new way seems like a giant step backwards;
it's likely to be a significant barrier to entry for non-expert users.

Can the old way of dealing with unresolvable links be restored, at least as
an option?



D. C. Toedt III
*(My last name is pronounced "Tate")*
Attorney & arbitrator -- tech contracts & IP
Common Draft <http://www.CommonDraft.org> toolkit for contract drafters
O: +1 (713) 364-6545
C: +1 (713) 516-8968
​​

dc@toedt.com
www.OnContracts.com/About

Unless expressly stated otherwise,
this message is not intended to serve
as assent to an agreement or other document,
even if attached to this message.

[-- Attachment #2: Type: text/html, Size: 7221 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[D. C. Toedt]

[-- Attachment #1: Type: text/plain, Size: 5552 bytes --]

UPDATE:

> I haven't tried org-lint yet (
http://steve.planetbarr.com/posts/2015-08-11-org-lint.html).
> That requires building org from a separate branch in git.  That makes me
nervous --
> I'm a user, not a dev, and while I'm sort of familiar with git, it seems
like yet another layer of complexity.

1.  OK, I got org-mode version 8.3.2 up and running using git.

The org-lint feature works -- very nice.

> The old way, namely just marking the problem link in the output file and
continuing with the export,
> made it very easy to search for the problem in the output file. That
approach was simple and worked quite well.

I still think that, but at least I'm up and running again.

Thanks to all for putting up with my lack of expertise, and especially to
the org-mode creator(s) and maintainers for a very-useful tool.

2.  For background: I'm a lawyer and part-time law professor.  I've been
using org-mode for several years now in building http:/www.CommonDraft.org
-- a free (Creative Commons) library of clauses for tech- and commercial
contracts, extensively annotated with citations, commentary, and links to
further reading.  The long-term goal is to have a Common Draft reference
version of each substantive variation of each type of contract clause
that's typically seen in the wild. That will free up lawyers from always
having to draft detailed contract language, and from having to review other
people's detailed language --- instead, we can simply incorporate desired
Common-Draft clauses by reference. (It's analogous to a library of callable
functions in software development.)  That will save time for both the
contract drafter and for the other side's legal reviewer, which in turn
will help the parties get a workable contract to signature sooner, at lower
cost.

In pitching the Common Draft concept, my latest metaphor for non-techies is
this:  If you're ordering a meal in a Chinese-food restaurant, but you
don't want any monosodium glutamate (MSG) in your food, you're _not_ going
to hand your server a set of detailed recipes for the dishes you want and
ask that the kitchen staff use those recipes.  No, you're simply going to
order from the menu --- hot-and-sour soup, kung-pao chicken, or whatever
--- but you'll say to your server, "no MSG, please," as a desired
variation.  It's the same idea for the Common Draft project:  A contract
drafter can "order from the menu" and specify any desired variations. The
Common Draft project is starting to get some attention in the
contract-management community; the International Association for Contract
and Commercial Management (http://www.IACCM.com), which has around 35,000
members worldwide, is supporting it.





D. C. Toedt III
*(My last name is pronounced "Tate")*
Attorney & arbitrator -- tech contracts & IP
Common Draft <http://www.CommonDraft.org> toolkit for contract drafters
O: +1 (713) 364-6545
C: +1 (713) 516-8968
​​

dc@toedt.com
www.OnContracts.com/About

Unless expressly stated otherwise,
this message is not intended to serve
as assent to an agreement or other document,
even if attached to this message.



On Fri, Oct 9, 2015 at 5:28 PM, D. C. Toedt <dc@toedt.com> wrote:

> >> Look at publishing instead of exporting to html which works with missing
> links.
> ​​
>
> Apparently it doesn't.
> I'm still having the same problem of throwing a fatal error --- even when
> publishing, not exporting --- when encountering a missing (unresolvable)
> link.  This was after doing a clean install of org-mode 8.3.2 (20151005,
> using the emacs package manager) on top of a clean install of the latest
> stable version of emacs (24.5) from EmacsForMacOSX. (I'm running the latest
> version of Mac OS X Yosemite; haven't gotten around to El Capitan.)  I then
> set up publishing the way Rainer suggested in his email.  Well, publishing
> likewise throws an error when it encounters a missing link target, just as
> does exporting.
>
> > You can use org-lint for this.
>
> I haven't tried org-lint yet (
> http://steve.planetbarr.com/posts/2015-08-11-org-lint.html).  That
> requires building org from a separate branch in git.  That makes me nervous
> -- I'm a user, not a dev, and while I'm sort of familiar with git, it seems
> like yet another layer of complexity.
>
> I don't mean to be a nag, but I genuinely don't understand why org-mode's
> former way of dealing with unresolvable links during export was disabled.
> The old way, namely just marking the problem link in the output file and
> continuing with the export, made it very easy to search for the problem in
> the output file. That approach was simple and worked quite well.  It also
> allowed exporting a single .org file, instead of jumping through the hoops
> of publishing a project.  The new way seems like a giant step backwards;
> it's likely to be a significant barrier to entry for non-expert users.
>
> Can the old way of dealing with unresolvable links be restored, at least
> as an option?
>
>
>
> D. C. Toedt III
> *(My last name is pronounced "Tate")*
> Attorney & arbitrator -- tech contracts & IP
> Common Draft <http://www.CommonDraft.org> toolkit for contract drafters
> O: +1 (713) 364-6545
> C: +1 (713) 516-8968
> ​​
>
> dc@toedt.com
> www.OnContracts.com/About
>
> Unless expressly stated otherwise,
> this message is not intended to serve
> as assent to an agreement or other document,
> even if attached to this message.
>
>
>

[-- Attachment #2: Type: text/html, Size: 16495 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[thomas]

[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]

just my 2 cents: I think the new error message is very nice and helpful, 
UNLESS you work on a bigger document, narrow your buffer and try to 
export the narrowed portion of the document.
This does not work anymore.

I can agree with D. C. Toedt that it would be nice to have an easy way 
to customize this behaviour of the exporter.

- thomas


On 25.09.2015 04:50, D. C. Toedt wrote:
> I just updated to 8.3.1 from 8.3beta (from git).  That appears to have 
> been a terrible mistake on my part.
>
> From this thread 
> <https://lists.gnu.org/archive/html/emacs-orgmode/2015-09/msg00040.html> 
> I see that the exporter now throws an error and aborts when it 
> encounters an unresolvable link. That makes things really, REALLY 
> difficult.  It means I can't get a complete, working export to HTML 
> (in my case) until all link problems are fixed in my 22KLOC .org file 
> (which I use to generate http://www.CommonDraft.org/index.html 
> <http://www.commondraft.org/index.html>). That seems EXTREMELY 
> suboptimal. (I'm trying to be tactful here.)
>
> Worse, the exporter doesn't even generate a list of unresolvable links 
> before aborting. That means the only way that I can find and fix 
> busted links (so far as I know) is to do an export --- which takes 
> several minutes given the large file  --- and have the export abort on 
> a single link. Then I fix that one link, export again, and have it 
> abort again. Repeat.  Aaaargggggg.
>
> I started looking at the hooks, as suggested in a message in the 
> previous thread, but I'm not nearly skilled enough in elisp to be able 
> to do anything useful.
>
> Any suggestions?
>
>
> *D. C. Toedt III */(My last name is pronounced "Tate"; I go by "D. 
> C.," which stands for Dell Charles//) /
> Attorney & neutral arbitrator -- tech contracts & IP  | Adjunct 
> professor, University of Houston Law Center
> ​ Author, ​​ ​Common Draft <http://www.commondraft.org/>**desk book of 
> contract clauses & research notes   | LinkedIn:dctoedt 
> <http://www.linkedin.com/in/dctoedt>   |Calendar 
> <https://www.google.com/calendar/embed?src=dc.toedt@toedt.com&mode=WEEK>(redacted) 
>
> E: dc@toedt.com <mailto:dc@toedt.com> O: +1 (713) 364-6545 C: +1 (713) 
> 516-8968
> ​ ​
> ​
> Houston, Texas (Central time zone)
>
> Unless expressly stated otherwise, this message is not intended
> to serve as assent to an agreement or other document, whether or not
> attached to this message.
>
>


[-- Attachment #2: Type: text/html, Size: 16509 bytes --]

Re: Exporter aborts upon encountering even one unresolvable link

[Nick Dokos]

thomas <thomas@friendlyvillagers.com> writes:

> just my 2 cents: I think the new error message is very nice and helpful, UNLESS you work on a bigger document, narrow your buffer and try to export the narrowed portion of the
> document.
> This does not work anymore.
>
> I can agree with D. C. Toedt that it would be nice to have an easy way to customize this behaviour of the exporter.
>

See the thread with title "[RFC] Draft mode":

http://thread.gmane.org/gmane.emacs.orgmode/101542

> - thomas
>
> On 25.09.2015 04:50, D. C. Toedt wrote:
>
>     I just updated to 8.3.1 from 8.3beta (from git).  That appears to have been a terrible mistake on my part.
>    
>     From this thread I see that the exporter now throws an error and aborts when it encounters an unresolvable link.  That makes things really, REALLY difficult.  It means I can't get
>     a complete, working export to HTML (in my case) until all link problems are fixed in my 22KLOC .org file (which I use to generate http://www.CommonDraft.org/index.html).  That
>     seems EXTREMELY suboptimal. (I'm trying to be tactful here.)
>    
>     Worse, the exporter doesn't even generate a list of unresolvable links before aborting.  That means the only way that I can find and fix busted links (so far as I know) is to do an
>     export --- which takes several minutes given the large file  --- and have the export abort on a single link. Then I fix that one link, export again, and have it abort again.
>     Repeat.  Aaaargggggg.
>    
>     I started looking at the hooks, as suggested in a message in the previous thread, but I'm not nearly skilled enough in elisp to be able to do anything useful.
>    
>     Any suggestions?
>
>     D. C. Toedt III  (My last name is pronounced "Tate"; I go by "D. C.," which stands for Dell Charles) 
>     Attorney & neutral arbitrator -- tech contracts & IP  |  Adjunct professor, University of Houston Law Center
>     ​ Author, ​​ ​Common Draft desk book of contract clauses & research notes   |  LinkedIn: dctoedt   |   Calendar (redacted) 
>     E: dc@toedt.com    O: +1 (713) 364-6545    C: +1 (713) 516-8968
>     ​ ​
>         
>     ​
>     Houston, Texas (Central time zone)
>    
>     Unless expressly stated otherwise, this message is not intended 
>     to serve as assent to an agreement or other document, whether or not
>     attached to this message.
>

-- 
Nick