Hello,
Sébastien Miquel writes:
> I think native compilation compiles the lamdba in
> =org-latex-export-to-pdf= and that there is no way to get back this
> original lambda (the code) from within =org-export-to-file= or
> =org-export-async-start=. Quoting the lambda prevents this
> compilation.
Sébastien Miquel writes:
> Rasmus Pank Roulund writes:
>>> This is most likely due to native compilation which compiles the
>>> unquoted lambda. Once compiled, it (presumably) fails to be passed to
>>> the external emacs process.
>> Ah, interesting. Is this a bug or a feature?
>
> I think the
Hi,
Rasmus Pank Roulund writes:
This is most likely due to native compilation which compiles the
unquoted lambda. Once compiled, it (presumably) fails to be passed to
the external emacs process.
Ah, interesting. Is this a bug or a feature?
I think the bug's with org-mode. As I explain
Timothy writes:
> Hi Tim,
>
>> I’m wondering if this could be a problem when exporting to latex if the
>>underlying latex process encounters errors and is waiting for user
>> input before
>>it can continue (which happens if there are problems in the tex
>> source latex is
>>trying to process)?
Sébastien Miquel writes:
> Hi,
>
> Nicolas Goaziou writes:
>>> I don’t really understand why this bug happens to be honest.
>> The patch is already an improvement, but the beast is still lurking,
>> indeed.
> This is most likely due to native compilation which compiles the
> unquoted lambda.
Hi,
Nicolas Goaziou writes:
This is not really the same fix.
Indeed, but I tested it and it does work.
You're quoting a lambda, which should
not be required if the problem disappeared. IOW, the true fix probably
belong in the `org-export-async-start' function.
What happens is as follows
Hello,
Sébastien Miquel writes:
> Attached is a patch that applies the same fix where affected.
Thank you. It mostly looks good, but I have one nit.
> - (lambda (file)
> - (run-hook-with-args 'org-icalendar-after-save-hook file) nil
> + '(lambda (file)
> +
Hi,
Nicolas Goaziou writes:
I don’t really understand why this bug happens to be honest.
The patch is already an improvement, but the beast is still lurking,
indeed.
This is most likely due to native compilation which compiles the
unquoted lambda. Once compiled, it (presumably) fails to be
Hi Tim,
> I’m wondering if this could be a problem when exporting to latex if the
>underlying latex process encounters errors and is waiting for user input before
>it can continue (which happens if there are problems in the tex source latex is
>trying to process)?
>
> It might be worth checking
Nicolas Goaziou writes:
> Hello,
>
> Rasmus writes:
>
>> When I try to export documents asynchronously with ox-latex, I always get
>> a bug in the “org-export-processFOO” files. The last sexp is always
>> something like this:
>>
>> (funcall '#
>> "test.tex")
>>
>> where the “#” and “’”
Hello,
Rasmus writes:
> When I try to export documents asynchronously with ox-latex, I always get
> a bug in the “org-export-processFOO” files. The last sexp is always something
> like this:
>
> (funcall '#
> "test.tex")
>
> where the “#” and “’” are mixed around. This happens even with
Hi there,
When I try to export documents asynchronously with ox-latex, I always get
a bug in the “org-export-processFOO” files. The last sexp is always something
like this:
(funcall '#
"test.tex")
where the “#” and “’” are mixed around. This happens even with a very
simple
12 matches
Mail list logo
