[PATCH] org-latex-compile timestamp checks

[PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

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

I’ve had some trouble with toggling latex fragment previews in a document on OS X. It would sometimes work, sometimes not, so I could just try a few times until it worked and get on with things. Looking into it more, the problem seems to be with the HFS+ filesystem’s second granularity on file timestamps. The Org code checks that the generated file is not older than a (current-time) obtained before starting latex compilation, but the truncated time of the generated file can indeed be older in the sub-second fields of the timestamp.

The attached patch simply compares timestamps truncated to 1-second precision. This does mean that there is the possibility of a false positive in the compilation test if a successful compilation is followed up by an unsuccessful compilation in less than one second. I do not know if anyone encounters such a scenario.

Anthony


[-- Attachment #2: 0001-lisp-ox-latex.el-PDF-generation-timestamp-check.patch --]
[-- Type: application/octet-stream, Size: 1468 bytes --]

From 806fdc4e77ec85dd786d18fc72f49be99899b9cc Mon Sep 17 00:00:00 2001
From: Anthony Cowley <acowley@gmail.com>
Date: Thu, 14 Jan 2016 18:13:45 -0500
Subject: [PATCH] lisp/ox-latex.el: PDF generation timestamp check

* lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
  filesystem by only considering 1-second clock resolution.

Previously, the call to (current-time) could return a timestamp with
a non-zero microsecond or picosecond fields, while the file attribute
always has zeros for these fields. The check that the generated file is
newer than the reference timestamp only succeeded when the time to
generate the file crossed a 1-second clock interval.

TINYCHANGE
---
 lisp/ox-latex.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a57677b..188c076 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3576,7 +3576,8 @@ Return PDF file name or an error if it couldn't be produced."
 	;; Check for process failure.  Provide collected errors if
 	;; possible.
 	(if (or (not (file-exists-p pdffile))
-		(time-less-p (nth 5 (file-attributes pdffile)) time))
+		(time-less-p (take 2 (nth 5 (file-attributes pdffile)))
+			     (take 2 time)))
 	    (error (format "PDF file %s wasn't produced" pdffile))
 	  ;; Else remove log files, when specified, and signal end of
 	  ;; process to user, along with any error encountered.
-- 
2.6.4


[-- Attachment #3: Type: text/plain, Size: 5 bytes --]

Re: [PATCH] org-latex-compile timestamp checks

[Rasmus]

Hi Anthony,

Thanks for raising this issue.

Anthony Cowley <acowley@gmail.com> writes:

> I’ve had some trouble with toggling latex fragment previews in a
> document on OS X. It would sometimes work, sometimes not, so I could
> just try a few times until it worked and get on with things. Looking
> into it more, the problem seems to be with the HFS+ filesystem’s
> second granularity on file timestamps. The Org code checks that the
> generated file is not older than a (current-time) obtained before
> starting latex compilation, but the truncated time of the generated
> file can indeed be older in the sub-second fields of the timestamp.
>
> The attached patch simply compares timestamps truncated to 1-second
> precision.

Isn't this a bug in Emacs file-attributes rather than Org?  If so, it
should be fixed in Emacs rather than worked around in Org IMO.

Maybe you could just check the log directly for failures rather than
checking the file attributes, if these are not reliable.

Also, what is the ‘take‘?  I don’t seem to have it in my Emacs...

Rasmus


-- 
Even a three-legged dog has three good legs to lose

Re: [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

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


> On Jan 15, 2016, at 7:13 AM, Rasmus <rasmus@gmx.us> wrote:
> 
> Hi Anthony,
> 
> Thanks for raising this issue.
> 
> Anthony Cowley <acowley@gmail.com> writes:
> 
>> I’ve had some trouble with toggling latex fragment previews in a
>> document on OS X. It would sometimes work, sometimes not, so I could
>> just try a few times until it worked and get on with things. Looking
>> into it more, the problem seems to be with the HFS+ filesystem’s
>> second granularity on file timestamps. The Org code checks that the
>> generated file is not older than a (current-time) obtained before
>> starting latex compilation, but the truncated time of the generated
>> file can indeed be older in the sub-second fields of the timestamp.
>> 
>> The attached patch simply compares timestamps truncated to 1-second
>> precision.
> 
> Isn't this a bug in Emacs file-attributes rather than Org?  If so, it
> should be fixed in Emacs rather than worked around in Org IMO.


Thanks for taking a look, Rasmus! The bug is in Org, not Emacs. One may perhaps assume the invariant that successive calls to `current-time` will return non-decreasing values. One might also assume the invariant that successive touches of different files will result in file attributes with non-decreasing timestamps. It is mixing the two that is the bug, and Emacs itself shouldn’t try to fix that. To be clear, the limiting factor in this comparison is the filesystem whose timestamp granularity is much coarser than the system clock.

We could do something like generate an entirely separate temporary file before compilation, and use its timestamp as the reference by which compilation output is evaluated. However, the approach of checking file freshness with a one-second granularity seems like a pretty good compromise.

> 
> Maybe you could just check the log directly for failures rather than
> checking the file attributes, if these are not reliable.
> 
> Also, what is the ‘take‘?  I don’t seem to have it in my Emacs…

Sorry about that. Believe it or not I had already rewritten those two lines — as simple as they are — trying to not include extra dependencies. I’ve attached an updated patch that uses subseq from cl.el. I hope that is okay.

Anthony

[-- Attachment #2: 0001-lisp-ox-latex.el-PDF-generation-timestamp-check.patch --]
[-- Type: application/octet-stream, Size: 1476 bytes --]

From d7960187c9b4be87ac8811810da3bb500837018c Mon Sep 17 00:00:00 2001
From: Anthony Cowley <acowley@gmail.com>
Date: Thu, 14 Jan 2016 18:13:45 -0500
Subject: [PATCH] lisp/ox-latex.el: PDF generation timestamp check

* lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
  filesystem by only considering 1-second clock resolution.

Previously, the call to (current-time) could return a timestamp with
a non-zero microsecond or picosecond fields, while the file attribute
always has zeros for these fields. The check that the generated file is
newer than the reference timestamp only succeeded when the time to
generate the file crossed a 1-second clock interval.

TINYCHANGE
---
 lisp/ox-latex.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a57677b..f803b7e 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3576,7 +3576,8 @@ Return PDF file name or an error if it couldn't be produced."
 	;; Check for process failure.  Provide collected errors if
 	;; possible.
 	(if (or (not (file-exists-p pdffile))
-		(time-less-p (nth 5 (file-attributes pdffile)) time))
+		(time-less-p (subseq (nth 5 (file-attributes pdffile)) 0 2)
+			     (subseq time 0 2)))
 	    (error (format "PDF file %s wasn't produced" pdffile))
 	  ;; Else remove log files, when specified, and signal end of
 	  ;; process to user, along with any error encountered.
-- 
2.6.4

Re: [PATCH] org-latex-compile timestamp checks

[Nicolas Goaziou]

Hello,

Anthony Cowley <acowley@gmail.com> writes:

> * lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
>   filesystem by only considering 1-second clock resolution.
>
> Previously, the call to (current-time) could return a timestamp with
> a non-zero microsecond or picosecond fields, while the file attribute
> always has zeros for these fields. The check that the generated file is
> newer than the reference timestamp only succeeded when the time to
> generate the file crossed a 1-second clock interval.
>
> TINYCHANGE
> ---
>  lisp/ox-latex.el | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index a57677b..f803b7e 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -3576,7 +3576,8 @@ Return PDF file name or an error if it couldn't be produced."
>  	;; Check for process failure.  Provide collected errors if
>  	;; possible.
>  	(if (or (not (file-exists-p pdffile))
> -		(time-less-p (nth 5 (file-attributes pdffile)) time))
> +		(time-less-p (subseq (nth 5 (file-attributes pdffile)) 0 2)
> +			     (subseq time 0 2)))

This sounds good. Thank you.

Although, I suggest to use `cl-subseq' instead of its alias. Also, it
may be worth commenting that trick right into the source.

Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
need a similar trick.

Rasmus, what do you think?


Regards,

-- 
Nicolas Goaziou

Re: [PATCH] org-latex-compile timestamp checks

[Rasmus]

Hi Anthony and Nicolas,

Anthony Cowley <acowley@gmail.com> writes:

> Thanks for taking a look, Rasmus! The bug is in Org, not Emacs. One
> may perhaps assume the invariant that successive calls to
> `current-time` will return non-decreasing values. One might also
> assume the invariant that successive touches of different files will
> result in file attributes with non-decreasing timestamps. It is mixing
> the two that is the bug, and Emacs itself shouldn’t try to fix
> that. To be clear, the limiting factor in this comparison is the
> filesystem whose timestamp granularity is much coarser than the system
> clock.

Thanks for carefully explaining exactly what is going on here.

> We could do something like generate an entirely separate temporary
> file before compilation, and use its timestamp as the reference by
> which compilation output is evaluated. However, the approach of
> checking file freshness with a one-second granularity seems like a
> pretty good compromise.

I think the approach is fine now.  See below.

>> Maybe you could just check the log directly for failures rather than
>> checking the file attributes, if these are not reliable.
>> 
>> Also, what is the ‘take‘?  I don’t seem to have it in my Emacs…
>
> Sorry about that. Believe it or not I had already rewritten those two
> lines — as simple as they are — trying to not include extra
> dependencies. I’ve attached an updated patch that uses subseq from
> cl.el. I hope that is okay.

Actually, it's part of cl-lib now (in the broadest understanding of
cl-lib).

Since this is a bugfix I guess you should use org-sublist (*shiver*) in
maint and cl-subseq in master.  We can’t use cl-lib in maint, right
Nicolas?

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Anthony Cowley <acowley@gmail.com> writes:
>
>> * lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
>>   filesystem by only considering 1-second clock resolution.
>>
>> Previously, the call to (current-time) could return a timestamp with
>> a non-zero microsecond or picosecond fields, while the file attribute
>> always has zeros for these fields. The check that the generated file is
>> newer than the reference timestamp only succeeded when the time to
>> generate the file crossed a 1-second clock interval.
>>
>> TINYCHANGE
>> ---
>>  lisp/ox-latex.el | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
>> index a57677b..f803b7e 100644
>> --- a/lisp/ox-latex.el
>> +++ b/lisp/ox-latex.el
>> @@ -3576,7 +3576,8 @@ Return PDF file name or an error if it couldn't be produced."
>>  	;; Check for process failure.  Provide collected errors if
>>  	;; possible.
>>  	(if (or (not (file-exists-p pdffile))
>> -		(time-less-p (nth 5 (file-attributes pdffile)) time))
>> +		(time-less-p (subseq (nth 5 (file-attributes pdffile)) 0 2)
>> +			     (subseq time 0 2)))
>
> This sounds good. Thank you.
>
> Although, I suggest to use `cl-subseq' instead of its alias. Also, it
> may be worth commenting that trick right into the source.

Yes, it should.

> Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
> need a similar trick.

Perhaps there should be an error check in ox-odt as well?  I guess the
only thing that could happen is that the zip/odt can’t be written, which
could happen if it’s open in windows, which is extremely picky with locked
files.  [I have had to use a windows machine at work].

> Rasmus, what do you think?

I looked at the source, and in the case of ox-latex.el it looks like we
cannot log at the log as org-latex-pdf-process can be a function.  As such
I guess file time stamp is indeed a fine proxy.

Thanks,
Rasmus

-- 
Spil noget med Slayer!

Re: [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

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


> On Jan 16, 2016, at 10:17 AM, Rasmus <rasmus@gmx.us> wrote:
> 
> Hi Anthony and Nicolas,
> 
> Anthony Cowley <acowley@gmail.com> writes:
> 
>> Thanks for taking a look, Rasmus! The bug is in Org, not Emacs. One
>> may perhaps assume the invariant that successive calls to
>> `current-time` will return non-decreasing values. One might also
>> assume the invariant that successive touches of different files will
>> result in file attributes with non-decreasing timestamps. It is mixing
>> the two that is the bug, and Emacs itself shouldn’t try to fix
>> that. To be clear, the limiting factor in this comparison is the
>> filesystem whose timestamp granularity is much coarser than the system
>> clock.
> 
> Thanks for carefully explaining exactly what is going on here.
> 
>> We could do something like generate an entirely separate temporary
>> file before compilation, and use its timestamp as the reference by
>> which compilation output is evaluated. However, the approach of
>> checking file freshness with a one-second granularity seems like a
>> pretty good compromise.
> 
> I think the approach is fine now.  See below.
> 
>>> Maybe you could just check the log directly for failures rather than
>>> checking the file attributes, if these are not reliable.
>>> 
>>> Also, what is the ‘take‘?  I don’t seem to have it in my Emacs…
>> 
>> Sorry about that. Believe it or not I had already rewritten those two
>> lines — as simple as they are — trying to not include extra
>> dependencies. I’ve attached an updated patch that uses subseq from
>> cl.el. I hope that is okay.
> 
> Actually, it's part of cl-lib now (in the broadest understanding of
> cl-lib).
> 
> Since this is a bugfix I guess you should use org-sublist (*shiver*) in
> maint and cl-subseq in master.  We can’t use cl-lib in maint, right
> Nicolas?
> 
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> 
>> Anthony Cowley <acowley@gmail.com> writes:
>> 
>>> * lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
>>>  filesystem by only considering 1-second clock resolution.
>>> 
>>> Previously, the call to (current-time) could return a timestamp with
>>> a non-zero microsecond or picosecond fields, while the file attribute
>>> always has zeros for these fields. The check that the generated file is
>>> newer than the reference timestamp only succeeded when the time to
>>> generate the file crossed a 1-second clock interval.
>>> 
>>> TINYCHANGE
>>> ---
>>> lisp/ox-latex.el | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
>>> index a57677b..f803b7e 100644
>>> --- a/lisp/ox-latex.el
>>> +++ b/lisp/ox-latex.el
>>> @@ -3576,7 +3576,8 @@ Return PDF file name or an error if it couldn't be produced."
>>> 	;; Check for process failure.  Provide collected errors if
>>> 	;; possible.
>>> 	(if (or (not (file-exists-p pdffile))
>>> -		(time-less-p (nth 5 (file-attributes pdffile)) time))
>>> +		(time-less-p (subseq (nth 5 (file-attributes pdffile)) 0 2)
>>> +			     (subseq time 0 2)))
>> 
>> This sounds good. Thank you.
>> 
>> Although, I suggest to use `cl-subseq' instead of its alias. Also, it
>> may be worth commenting that trick right into the source.
> 
> Yes, it should.

I’ve attached two remixes of the original patch: the first uses cl-subseq, the second uses org-sublist.

Anthony


[-- Attachment #2: ox-latex-timestamp.patch --]
[-- Type: application/octet-stream, Size: 1607 bytes --]

From 8e152704e3b0a3cc31ef46d31e32c7b914fd4401 Mon Sep 17 00:00:00 2001
From: Anthony Cowley <acowley@gmail.com>
Date: Thu, 14 Jan 2016 18:13:45 -0500
Subject: [PATCH] lisp/ox-latex.el: PDF generation timestamp check

* lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
  filesystem by only considering 1-second clock resolution.

Previously, the call to (current-time) could return a timestamp with
a non-zero microsecond or picosecond fields, while the file attribute
always has zeros for these fields. The check that the generated file is
newer than the reference timestamp only succeeded when the time to
generate the file crossed a 1-second clock interval.

TINYCHANGE
---
 lisp/ox-latex.el | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a57677b..eb1ba6c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3576,7 +3576,10 @@ Return PDF file name or an error if it couldn't be produced."
 	;; Check for process failure.  Provide collected errors if
 	;; possible.
 	(if (or (not (file-exists-p pdffile))
-		(time-less-p (nth 5 (file-attributes pdffile)) time))
+		;; Only compare times up to whole seconds as some filesystems
+		;; (e.g. HFS+) do not retain any finer granularity.
+		(time-less-p (cl-subseq (nth 5 (file-attributes pdffile)) 0 2)
+			     (cl-subseq time 0 2)))
 	    (error (format "PDF file %s wasn't produced" pdffile))
 	  ;; Else remove log files, when specified, and signal end of
 	  ;; process to user, along with any error encountered.
-- 
2.6.4


[-- Attachment #3: ox-latex-timestamp-maint.patch --]
[-- Type: application/octet-stream, Size: 1611 bytes --]

From 9275fd16c8ec51702a63bfc3e8e736bb787b624c Mon Sep 17 00:00:00 2001
From: Anthony Cowley <acowley@gmail.com>
Date: Thu, 14 Jan 2016 18:13:45 -0500
Subject: [PATCH] lisp/ox-latex.el: PDF generation timestamp check

* lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
  filesystem by only considering 1-second clock resolution.

Previously, the call to (current-time) could return a timestamp with
a non-zero microsecond or picosecond fields, while the file attribute
always has zeros for these fields. The check that the generated file is
newer than the reference timestamp only succeeded when the time to
generate the file crossed a 1-second clock interval.

TINYCHANGE
---
 lisp/ox-latex.el | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a57677b..848fe3a 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3576,7 +3576,10 @@ Return PDF file name or an error if it couldn't be produced."
 	;; Check for process failure.  Provide collected errors if
 	;; possible.
 	(if (or (not (file-exists-p pdffile))
-		(time-less-p (nth 5 (file-attributes pdffile)) time))
+		;; Only compare times up to whole seconds as some filesystems
+		;; (e.g. HFS+) do not retain any finer granularity.
+		(time-less-p (org-sublist (nth 5 (file-attributes pdffile)) 1 2)
+			     (org-sublist time 1 2)))
 	    (error (format "PDF file %s wasn't produced" pdffile))
 	  ;; Else remove log files, when specified, and signal end of
 	  ;; process to user, along with any error encountered.
-- 
2.6.4

Re: [PATCH] org-latex-compile timestamp checks

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Since this is a bugfix I guess you should use org-sublist (*shiver*) in
> maint and cl-subseq in master.  We can’t use cl-lib in maint, right
> Nicolas?

Absolutely.

>> Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
>> need a similar trick.
>
> Perhaps there should be an error check in ox-odt as well?  I guess the
> only thing that could happen is that the zip/odt can’t be written, which
> could happen if it’s open in windows, which is extremely picky with locked
> files.  [I have had to use a windows machine at work].

This makes sense, indeed.

Would you want to take care of applying the patches and updating the
various export back-ends accordingly, or should I?


Regards,

-- 
Nicolas Goaziou

Re: [PATCH] org-latex-compile timestamp checks

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>>> Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
>>> need a similar trick.
>>
>> Perhaps there should be an error check in ox-odt as well?  I guess the
>> only thing that could happen is that the zip/odt can’t be written, which
>> could happen if it’s open in windows, which is extremely picky with locked
>> files.  [I have had to use a windows machine at work].
>
> This makes sense, indeed.
>
> Would you want to take care of applying the patches and updating the
> various export back-ends accordingly, or should I?

My life is a bit stressful at the moment (deadlines).  I'm happy to do it,
and maybe I can do it in the weekend, but if you feel like taking doing it
I won’t stand in your way.

Rasmus

-- 
The right to be left alone is a human right

Re: [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

Rasmus writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>>>> Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
>>>> need a similar trick.
>>>
>>> Perhaps there should be an error check in ox-odt as well?  I guess the
>>> only thing that could happen is that the zip/odt can’t be written, which
>>> could happen if it’s open in windows, which is extremely picky with locked
>>> files.  [I have had to use a windows machine at work].
>>
>> This makes sense, indeed.
>>
>> Would you want to take care of applying the patches and updating the
>> various export back-ends accordingly, or should I?
>
> My life is a bit stressful at the moment (deadlines).  I'm happy to do it,
> and maybe I can do it in the weekend, but if you feel like taking doing it
> I won’t stand in your way.
>
> Rasmus

Just a friendly bump to make sure this doesn't get lost. I think the LaTeX patches should still apply; let me know if there's an issue tracker I could use to record the need for adjustments to other back-ends.

Anthony

Re: [PATCH] org-latex-compile timestamp checks

[Rasmus]

Hi Anthony,

>>>>> Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
>>>>> need a similar trick.
>>>>
>>>> Perhaps there should be an error check in ox-odt as well?  I guess the
>>>> only thing that could happen is that the zip/odt can’t be written, which
>>>> could happen if it’s open in windows, which is extremely picky with locked
>>>> files.  [I have had to use a windows machine at work].
>>>
>>> This makes sense, indeed.
>>>
>>> Would you want to take care of applying the patches and updating the
>>> various export back-ends accordingly, or should I?
>>
>> My life is a bit stressful at the moment (deadlines).  I'm happy to do it,
>> and maybe I can do it in the weekend, but if you feel like taking doing it
>> I won’t stand in your way.
>
> Just a friendly bump to make sure this doesn't get lost. I think the
> LaTeX patches should still apply; let me know if there's an issue
> tracker I could use to record the need for adjustments to other
> back-ends.

Short weekend...  Thanks for reminding.  Would you be interested in
providing patches for the other backends?  I’d be a bit troubled by fixing
a general issue for one backend only.

Rasmus

-- 
I feel emotional landscapes they puzzle me

Re: [PATCH] org-latex-compile timestamp checks

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Short weekend...  Thanks for reminding.  Would you be interested in
> providing patches for the other backends?  I’d be a bit troubled by fixing
> a general issue for one backend only.

FWIW, I applied the patch before reading your answer.

Regards,

-- 
Nicolas Goaziou

Re: [PATCH] org-latex-compile timestamp checks

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Rasmus <rasmus@gmx.us> writes:
>
>> Short weekend...  Thanks for reminding.  Would you be interested in
>> providing patches for the other backends?  I’d be a bit troubled by fixing
>> a general issue for one backend only.
>
> FWIW, I applied the patch before reading your answer.

Thanks!  I have added a TODO to my agenda regarding checking other
backends, but I'd not hold grudges against anyone who beats me to it.

Rasmus

-- 
Nothing's wrong with an email that ends in a minor key

Re: [PATCH] org-latex-compile timestamp checks

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Thanks!  I have added a TODO to my agenda regarding checking other
> backends, but I'd not hold grudges against anyone who beats me to it.

I took care of ox-groff, ox-man and ox-texinfo.

I let you improve zip handling in ox-odt, if you want to.

Regards,

-- 
Nicolas Goaziou

Re: [PATCH] org-latex-compile timestamp checks

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Rasmus <rasmus@gmx.us> writes:
>
>> Thanks!  I have added a TODO to my agenda regarding checking other
>> backends, but I'd not hold grudges against anyone who beats me to it.
>
> I took care of ox-groff, ox-man and ox-texinfo.

Thanks.

> I let you improve zip handling in ox-odt, if you want to.

OK.  I'll be traveling this weekend so I won't have time then.  Though it
should be quick now that I can look at yours and Anthony’s code.

Rasmus

-- 
Hooray!

Re: [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

Rasmus writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Hello,
>>
>> Rasmus <rasmus@gmx.us> writes:
>>
>>> Thanks!  I have added a TODO to my agenda regarding checking other
>>> backends, but I'd not hold grudges against anyone who beats me to it.
>>
>> I took care of ox-groff, ox-man and ox-texinfo.
>
> Thanks.
>
>> I let you improve zip handling in ox-odt, if you want to.
>
> OK.  I'll be traveling this weekend so I won't have time then.  Though it
> should be quick now that I can look at yours and Anthony’s code.
>
> Rasmus

Thank you both for following up on this! I had grep'ed the tree for other time comparisons and not seen any, but didn't read closely enough to see the reliance on file existence checks in the other back-ends.

Anthony