From mboxrd@z Thu Jan 1 00:00:00 1970 From: "D. C. Toedt" Subject: Re: Exporter aborts upon encountering even one unresolvable link Date: Fri, 9 Oct 2015 17:28:41 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c17cdac9d6130521b3821d Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkgAH-0005t2-2P for emacs-orgmode@gnu.org; Fri, 09 Oct 2015 18:29:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkgAD-0002sP-SQ for emacs-orgmode@gnu.org; Fri, 09 Oct 2015 18:29:24 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:36044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkgAD-0002r4-MX for emacs-orgmode@gnu.org; Fri, 09 Oct 2015 18:29:21 -0400 Received: by oibi136 with SMTP id i136so51662866oib.3 for ; Fri, 09 Oct 2015 15:29:20 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rainer M Krug Cc: emacs-orgmode@gnu.org --001a11c17cdac9d6130521b3821d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> Look at publishing instead of exporting to html which works with missing links. =E2=80=8B=E2=80=8B 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 toolkit for contract drafters O: +1 (713) 364-6545 C: +1 (713) 516-8968 =E2=80=8B=E2=80=8B 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. --001a11c17cdac9d6130521b3821d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>=C2=A0Look at publishing instead of exporting to html which w= orks with=C2=A0missing = links.
=E2=80= =8B=E2=80=8B

Apparently it doesn't. =C2=A0
= I'm still having the same problem of throwing a fatal error --- even wh= en publishing, not exporting --- when encountering a missing (unresolvable)= link.=C2=A0 This was after doing a clean install of org-mode 8.3.2 (201510= 05, using the emacs package manager) on top of a clean install of the lates= t 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 Capita= n.) =C2=A0I then set up publishing the way Rainer suggested in his email.= =C2=A0 Well, publishing likewise throws an error when it encounters a missi= ng link target, just as does exporting.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">>=C2=A0Yo= u can use org-lint for this.

I haven&#= 39;t tried org-lint yet (http://steve.planetbarr.com/posts/20= 15-08-11-org-lint.html).=C2=A0 That requires building org from a separa= te branch in git.=C2=A0 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 lay= er of complexity.

I do= n'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 disa= bled.=C2=A0 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 p= roblem in the output file. That approach was simple and worked quite well.= =C2=A0 It also allowed exporting a single .org file, instead of jumping thr= ough the hoops of publishing a project.=C2=A0 The new way seems like a gian= t 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=C2=A0
(My last name = is pronounced "Tate")
Attorn= ey & arbitrator -- tech contracts & IP
Common Draft toolkit for contract draft= ers
O:
+1= (713) 364-6545=C2=A0 =C2=A0
C: <= a href=3D"tel:%2B1%20%28713%29%20516-8968" value=3D"+17135168968" target=3D= "_blank">+1 (713) 516-8968
=E2=80=8B=E2=80=8B
=C2=A0=C2=A0
<= div title=3D"signature">dc@= toedt.com

Unless expressly stated otherwise= ,
this message=C2=A0
is not intended=C2=A0to serve
as
assent to an agreement=C2=A0or other document,
even if=C2=A0
attached to this message.=


--001a11c17cdac9d6130521b3821d--