Re: Error during PDF export but the PDF file is exported

2022-10-21 Thread Pascal Quesseveur
>"IR" == Ihor Radchenko  writes:

  IR> Pascal, could you please try the latest main and see if the
  IR> problem is fixed?

Unfortunately I can't try at the moment. I have followed the link

https://list.orgmode.org/thu03t$16vt$1...@ciao.gmane.io

and FWIU it should work fine as it takes the file modification time
instead of current-time in org-compile-file as I did in my first
attempt.


-- 
Pascal Quesseveur
pques...@gmail.com



Re: Error during PDF export but the PDF file is exported

2022-10-20 Thread Ihor Radchenko
Max Nikulin  writes:

> On 20/10/2022 12:12, Ihor Radchenko wrote:
>> 
>> What I wanted to say is that
>> `current-time' is good enough if we export to local file.
>
> Since the patch was not posted to the mailing list, I may be wrong due 
> to some rather wild assumption.
>
> Paul Eggert convinced me that generally it is a bad idea to compare wall 
> (system) time and file time. They may have different resolution or may 
> have significant offset.  Notice that the following pending patch 
> modifies time handling in `org-compile-file', however I have not tested 
> it for remote files:
>
> Max Nikulin. [PATCH v2] org-macs.el: Do not compare wall time and file 
> modification time. Sun, 9 Oct 2022 15:18:04 +0700. 
> https://list.orgmode.org/thu03t$16vt$1...@ciao.gmane.io
>
> I am sorry that I did not join to this thread earlier.

You are right, that patch should fix this problem as well.
For some reason, I only remembered that patch as something that concerns
tangling. Now, applied.

Pascal, could you please try the latest main and see if the problem is fixed?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: Error during PDF export but the PDF file is exported

2022-10-20 Thread Max Nikulin

On 20/10/2022 12:12, Ihor Radchenko wrote:


What I wanted to say is that
`current-time' is good enough if we export to local file.


Since the patch was not posted to the mailing list, I may be wrong due 
to some rather wild assumption.


Paul Eggert convinced me that generally it is a bad idea to compare wall 
(system) time and file time. They may have different resolution or may 
have significant offset.  Notice that the following pending patch 
modifies time handling in `org-compile-file', however I have not tested 
it for remote files:


Max Nikulin. [PATCH v2] org-macs.el: Do not compare wall time and file 
modification time. Sun, 9 Oct 2022 15:18:04 +0700. 
https://list.orgmode.org/thu03t$16vt$1...@ciao.gmane.io


I am sorry that I did not join to this thread earlier.



Re: Error during PDF export but the PDF file is exported

2022-10-19 Thread Ihor Radchenko
Pascal Quesseveur  writes:

>>"IR" == Ihor Radchenko  writes:
>
>   IR> I think that creating a temporary file locally is excessive.
>
>   Perhaps, but I couldn't find another way.

I think we are miscommunication. What I wanted to say is that
`current-time' is good enough if we export to local file. The whole
route with creating temporary file and getting its attributes is only
needed in remote directory.

>   IR> You could guard the logic behind `file-remote-p'.
>
>   FMU file-remote-p works onnly when there is a handler on path for
> operation file-remote-p, which is not true in the general
> case. Otherwise that function returns nil.

If file-remote-p does not work, I doubt that we can export to that
directory at all.

>   OTOH it is possible to reserve the creation of a temporary file only
> when the file is not already present.

It is also an option.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: Error during PDF export but the PDF file is exported

2022-10-19 Thread Pascal Quesseveur
>"IR" == Ihor Radchenko  writes:

  IR> I think that creating a temporary file locally is excessive.

  Perhaps, but I couldn't find another way.

  IR> You could guard the logic behind `file-remote-p'.

  FMU file-remote-p works onnly when there is a handler on path for
operation file-remote-p, which is not true in the general
case. Otherwise that function returns nil.

  OTOH it is possible to reserve the creation of a temporary file only
when the file is not already present.


-- 
Pascal Quesseveur
pques...@gmail.com



Re: Error during PDF export but the PDF file is exported

2022-10-19 Thread Ihor Radchenko
[Adding Org mailing list back to the loop. Someone forgot reply all in
the earlier messages]

Pascal Quesseveur  writes:

>>"IR" == Ihor Radchenko  a écrit :
>
>   IR> No, if there is an error when running LaTeX. No PDF file might be
>   IR> produced in some scenarios. And we need to clearly communicate such
>   IR> scenarios to the user.
>
> Here is a patch to org-macs.el (from Emacs 28.1) that works for me. I
> have checked with files on a server whose current date was behind my
> PC. I also checked with a sync server and with local files.

Thanks!

I think that creating a temporary file locally is excessive. You could
guard the logic behind `file-remote-p'.

Also, can you prepare a proper patch? See
https://orgmode.org/worg/org-contribute.html#first-patch

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: Error during PDF export but the PDF file is exported

2022-10-16 Thread Ihor Radchenko
Pascal Quesseveur  writes:

> From time to time I work on files mounted from a remote host which is
> late compared to my pc.  Then I encounter errors when producing files
> from Org:
>
> File xxx wasn't produced
>
> But the file is produced and is up-to-date. The error message comes
> from org-compile-file. In that function the test is to compare the
> date at the start of function with the date of the produced file. I
> don't know if it's still the case in recent versions, but I think it
> could be changed. For example, instead of using the date at the start
> of the function, we could use the date of the file if it already
> exists
>
> (time (if (file-exists-p output)
> (file-attribute-modification-time (file-attributes output))
>   '(0 0 0 0)))

Confirmed.

Sorry for the late reply.
This kind of use-case is indeed not considered by our code.
However, your suggestion will only provide a partial fix - when an older
file already exists in the remote folder.

May be there a way to get time on remote server?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at