On Tue, Mar 17, 2015 at 6:38 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
(re unresolved ID links)
See e0b19dedb99d3c01199a159a2da8f9aa4adb2f6f
Updated fuzzy link patch attached.
Applied (with minor tweaks). Thank you.
Thanks for the changes.
I had some issues using the error messages to
Jacob Gerlach jacobgerl...@gmail.com writes:
I tried this, or more specifically:
(or ((org-element-map
...
info 'first-match))
(user-error ...
and got a failure on test-org-export/resolve-coderef. It's not
obvious to me from reading the tests if there is a test that needs to
be
Hello,
Thanks for the feedback.
On Sun, Mar 15, 2015 at 4:44 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
I don't really use code blocks, so I wasn't sure what to do with
org-export-resolve-coderef.
[...]
No, the whole body could be wrapped with an `or':
(or (org-element-map ...)
Jacob Gerlach jacobgerl...@gmail.com writes:
Patch attached for fuzzy links.
Thank you.
I don't really use code blocks, so I wasn't sure what to do with
org-export-resolve-coderef. Should the final
(when (re-search...
(cond ...
become
(or (re-search...
(cond ...
(error
No,
On Sun, Sep 28, 2014 at 3:03 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
Aaron Ecay aarone...@gmail.com writes:
The links issue (re-)raised by Jacob in
http://mid.gmane.org/caa6uvufm-1nwd06a5o3hwsveqmgqljncfk_ptohsehcvdjt...@mail.gmail.com
is a bit harder to deal with, since each backend
Hi Nicolas,
2014ko irailak 28an, Nicolas Goaziou-ek idatzi zuen:
Hello,
Aaron Ecay aarone...@gmail.com writes:
Attached is a revised patch. WDYT?
Looks good. Some small comments follow.
+(if value
+(progn
+ (push signature record)
+
2014ko irailak 28an, Nicolas Goaziou-ek idatzi zuen:
Hello,
Aaron Ecay aarone...@gmail.com writes:
This turned out to be very easy to change; attached is a patch.
Thank you. Please apply it.
Pushed.
--
Aaron Ecay
Hello,
Aaron Ecay aarone...@gmail.com writes:
Pushed.
Thanks.
--
Nicolas Goaziou0x80A93738
Hello,
Aaron Ecay aarone...@gmail.com writes:
Attached is a revised patch. WDYT?
Looks good. Some small comments follow.
+ (if value
+ (progn
+ (push signature record)
+ (delete-region
+begin
+
Hello,
Aaron Ecay aarone...@gmail.com writes:
This turned out to be very easy to change; attached is a patch.
Thank you. Please apply it.
The links issue (re-)raised by Jacob in
http://mid.gmane.org/caa6uvufm-1nwd06a5o3hwsveqmgqljncfk_ptohsehcvdjt...@mail.gmail.com
is a bit harder to deal
Hi Nicolas,
Thanks for the feedback.
2014ko irailak 23an, Nicolas Goaziou-ek idatzi zuen:
Hello,
Aaron Ecay aarone...@gmail.com writes:
Um...but the patch I sent works precisely by defining a macro translator,
which does get called for any unexpanded (because undefined) macros.
Hi Rasmus,
2014ko irailak 23an, Rasmus-ek idatzi zuen:
Hi,
Aaron Ecay aarone...@gmail.com writes:
You have two options. Either report an error, as you suggested, or
insert an obnoxious message in the output, e.g., UNKNOWN MACRO, à la
DEFINITION NOT FOUND. for footnote definitions. In
Aaron may I trouble you to add a flag so that if such errors occur
then the export fails?
From my perspective, if the document doesn't compile, then nothing
should succeed.
Compile includes export from my perspective.
On Mon, Sep 22, 2014 at 10:25 PM, Aaron Ecay aarone...@gmail.com wrote:
Hi
Hi Grant,
2014ko irailak 23an, Grant Rettke-ek idatzi zuen:
Aaron may I trouble you to add a flag so that if such errors occur
then the export fails?
From my perspective, if the document doesn't compile, then nothing
should succeed.
Compile includes export from my perspective.
Indeed,
While I expect that there's no code overlap with macro expansion, I asked
about similar stop on unresolved content behavior with respect to links
here: http://article.gmane.org/gmane.emacs.orgmode/90010/
That discussion died off so I thought I'd bring up the topic again here.
Would it be
Hello,
Aaron Ecay aarone...@gmail.com writes:
Um...but the patch I sent works precisely by defining a macro translator,
which does get called for any unexpanded (because undefined) macros.
Macros are not expected to be seen by export back-ends. It happens when
a macro is undefined, but this
Hi,
Aaron Ecay aarone...@gmail.com writes:
You have two options. Either report an error, as you suggested, or
insert an obnoxious message in the output, e.g., UNKNOWN MACRO, à la
DEFINITION NOT FOUND. for footnote definitions. In any case, this
should happen in org-macro.el, not in the
Hello,
Jacob Gerlach jacobgerl...@gmail.com writes:
While I expect that there's no code overlap with macro expansion, I asked
about similar stop on unresolved content behavior with respect to links
here: http://article.gmane.org/gmane.emacs.orgmode/90010/
That discussion died off so I
Hi Nicolas,
2014ko irailak 19an, Nicolas Goaziou-ek idatzi zuen:
Certainly not a message, due to asynchronous export.
Very good point.
2. Since this is a feature that many backends will want to use, should
we introduce a new “abstract” backend from which other backends can
inherit,
Hello all,
Currently, if a macro is not defined, it will silently produce an empty
string while exporting. This situation could arise for example if a
macro name is acidentally mistyped. I think it’s desirable to warn the
user in this case. The attached patch introduces a function to do so,
Hello,
Aaron Ecay aarone...@gmail.com writes:
Currently, if a macro is not defined, it will silently produce an empty
string while exporting. This situation could arise for example if a
macro name is acidentally mistyped. I think it’s desirable to warn the
user in this case. The attached
21 matches
Mail list logo
