On Thu, Apr 7, 2022 at 12:10 PM Jérôme LAURENS < jerome.laurens@u-bourgogne.fr> wrote:

New CLI options --busy related to typesetting

luatex --busy=0 default behavior, nothing new luatex --busy=1 Instead of writing the pdf output to jobname.pdf, write to jobname.pdf(busy) At the end remove any jobname.pdf and move jobname.pdf(busy) to jobname.pdf luatex --busy=2 foo.tex If there is a jobname.pdf(busy) bail out with a diagnostic message « typesetting already in progress » Otherwise do like --busy=1

Actually, the pdf is removed at the start of the typesetting process such that it is no longer available during that whole time. When the typesetting is a bit long, it is not practical at all. For continuous typesetting neither. Considering that we work in general on the end of a document, the first pages will not change a lot but are no longer available.

synctex already supports this « busy » busyness such that the previous .synctex file is available during next typesetting process.

hm, perhaps you can process the command line as below \directlua{print(); print("==========================="); for k,v in pairs(arg) do print(k,v) end; print("==========================="); } hi \bye and use the wrapup_run callback . -- luigi

On Thu, Apr 7, 2022 at 9:30 PM Jérôme LAURENS wrote:

Yes, this does work on a per document basis, but what I request is a builtin feature that simply applies out of the box and is backwards compatible.

it's not clear what you want to achieve.... What does "busy" mean in this context ? -- luigi

On Thu, Apr 7, 2022 at 11:11 PM Jérôme LAURENS < jerome.laurens@u-bourgogne.fr> wrote:

Le 7 avr. 2022 à 22:53, luigi scarso a écrit :

On Thu, Apr 7, 2022 at 9:30 PM Jérôme LAURENS < jerome.laurens@u-bourgogne.fr> wrote:

...

Yes, this does work on a per document basis, but what I request is a builtin feature that simply applies out of the box and is backwards compatible.

it's not clear what you want to achieve.... What does "busy" mean in this context ?

It means that the output file is named jobname.pdf despite it is known to be incomplete and unusable during all the typesetting process. The output file should be named jobname.pdf only once it is really a complete pdf file. In the meanwhile its extension is pdf(busy), which means that it is a pdf file under construct.

It's a well established rule that one can use the file jobname.pdf *after* that the luatex process ends, and even in this case it doesn't mean that the pdf is complete and / or usable , even if the luatex process ends correctly. -- luigi

Sorry, last answer was too short… The problem is not that the new pdf output is not complete until the end of the typesetting process, the problem is that the old pdf is removed at the beginning of the typesetting process, whereas it could be removed only at the very last moment. This would be a big improvement in everyone’s workflow (overleaf uses that de facto). I agree that luatex callbacks can be used for that purpose, but it means that each people must have some basic lua skills and will have to modify all its documents one by one. Using the ‘--lua’ options is a bit better, except that every one must still duplicate the initialization file in each document folder. Anyways, this is rather far from a user friendly one click solution. As pointed out by Hans, adding a new command line option to luatex de facto breaks backwards compatibility somehow. If something possibly gets broken on extremely rare occasions whereas there exists a very simple fix, this is not really a problem compared to the benefits. Moreover, using ‘--output-busy’ instead of ‘--busy’ would help, and would be more explicit as well. This should be in the TODO list, not at the top, but not very far… BTW, I have found luatex roadmap on the web but no task list, was I unlucky ? JL

Le 8 avr. 2022 à 00:26, Jérôme LAURENS a écrit :

...

Le 7 avr. 2022 à 23:24, luigi scarso mailto:luigi.scarso@gmail.com> a écrit :

On Thu, Apr 7, 2022 at 11:11 PM Jérôme LAURENS mailto:jerome.laurens@u-bourgogne.fr> wrote:

...

Le 7 avr. 2022 à 22:53, luigi scarso mailto:luigi.scarso@gmail.com> a écrit :

On Thu, Apr 7, 2022 at 9:30 PM Jérôme LAURENS mailto:jerome.laurens@u-bourgogne.fr> wrote: Yes, this does work on a per document basis, but what I request is a builtin feature that simply applies out of the box and is backwards compatible.

it's not clear what you want to achieve.... What does "busy" mean in this context ?

It means that the output file is named jobname.pdf despite it is known to be incomplete and unusable during all the typesetting process. The output file should be named jobname.pdf only once it is really a complete pdf file. In the meanwhile its extension is pdf(busy), which means that it is a pdf file under construct.

It's a well established rule that one can use the file jobname.pdf *after* that the luatex process ends, and even in this case it doesn't mean that the pdf is complete and / or usable , even if the luatex process ends correctly.

If people were given a choice, this de facto rule would certainly be not so well established.

JL

...

-- luigi

_______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl mailto:dev-luatex@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-luatex https://mailman.ntg.nl/mailman/listinfo/dev-luatex

I see. This should be documented properly, thus I should not have wasted my time and yours.

Le 8 avr. 2022 à 09:11, Hans Hagen a écrit :

On 4/8/2022 8:23 AM, Jérôme LAURENS wrote:

...

Sorry, last answer was too short… The problem is not that the new pdf output is not complete until the end of the typesetting process, the problem is that the old pdf is removed at the beginning of the typesetting process, whereas it could be removed only at the very last moment. This would be a big improvement in everyone’s workflow (overleaf uses that de facto).

In a work flow one can rename and such. In context that has been done for decades so I bet overloeaf can also do it. Workflows are not part of 'tex the program' as they differ and fighting built-in heuristics is a pain (already).

...

I agree that luatex callbacks can be used for that purpose, but it means that each people must have some basic lua skills and will have to modify all its documents one by one. Using the ‘--lua’ options is a bit better, except that every one must still duplicate the initialization file in each document folder. Anyways, this is rather far from a user friendly one click solution.

It should be no big deal to make it part of the macro package used (likely latex); just add the few lines of (lua) code needed to do it as part of th enormal lua related initializations. That way (1) users don't notice and (2) some --flag can be used that doesn't conflict.

...

This should be in the TODO list, not at the top, but not very far… BTW, I have found luatex roadmap on the web but no task list, was I Per 1.10 LuaTeX is frozen because otherwise it's hard for macro package writers and users to keep up with the changes. As extensions can be done in Lua it also moves the responsibility to those who use it while the luatex team handles bug fixes and integration in tex live. That site is mostly there for historic reasons.

Hans

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl ----------------------------------------------------------------- _______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-luatex

On Fri, Apr 8, 2022 at 8:23 AM Jérôme LAURENS wrote:

Sorry, last answer was too short…

The problem is not that the new pdf output is not complete until the end of the typesetting process, the problem is that the old pdf is removed at the beginning of the typesetting process, whereas it could be removed only at the very last moment. This would be a big improvement in everyone’s workflow (overleaf uses that de facto).

Ah ok, this is the problem...well in this case the solution should be to open a tempfile to write the pdf data and when finished rename the tempfile. No need for command line switches. I cannot use a jobname-related name, because the format can choose the same name to write its data: it has to be a tempfile name generated by the operating system, and also it must be deleted after the termination of the program -- in any case, i.e error or abort -- because otherwise we can have tons of useless files that waste space. I can look at these kinds of requests because it can be an optimization -- something that does the same thing but better -- modulo that I have not to upset the code too much. Indeed, another constraint is that the source code of pdftex /xetex / luatex should be comparable. -- luigi

On Wed, May 4, 2022 at 8:11 AM Jérôme LAURENS wrote:

The busy pdf can be named \jobname.pdf(busy), similar to \jobname.synctex(busy)

'(' and ')' need to be escaped in bash and , as written before, the format can choose the same name to write its data. So it has to be a temp name, something like \jobname-<tempname>, where <tempname> is given by the OS. -- luigi

On Wed, May 4, 2022 at 12:37 PM Jérôme LAURENS < jerome.laurens@u-bourgogne.fr> wrote:

How do you manage \jobname-<tmpname> when the process has been killed ?

Indeed, this is the problem.

In bash, quotes are already used to escape spaces in file paths such that ‘(‘ and ‘)’ should already be escaped for free.

sure, indeed ls 'foo.pdf(busy)' is ok while ls foo.pdf(busy) it is not -- a useless complication if one has to manage files at command line. Just avoid '(' etc, e.g. foo.pdf_busy_ is fine. -- luigi

On Wed, May 4, 2022 at 2:21 PM Jérôme LAURENS wrote:

You must also compare with `ls foo-<tmpname>` which is really another level of complexity. Next usage is far more efficient

...

ls foo.pdf* rm foo.pdf+TAB completion+arrow down?+enter

However, if things are correctly implemented, you’d never even need to worry about \jobname.pdf(busy) at all, should it be from the CLI or from the desktop. The only purpose of \jobname.pdf(busy) is eventually to be deciphered, and this is far easier for most people, who only know ‘_’ for math subscript (I had already tested on my students for "synctex(busy)").

Only tools that clean things up (« Remove aux files » ) could eventually manage a new file extension but that is not a requirement.

Hm, I think I am missing the point... the filename of the "busy pdf " would be hardcoded in luatex, there is no need for '(' etc. -- luigi