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.

Le 7 avr. 2022 à 14:32, luigi scarso a écrit :

On Thu, Apr 7, 2022 at 12:10 PM Jérôme LAURENS mailto: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

Le 7 avr. 2022 à 22:53, luigi scarso 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.

-- luigi

Le 7 avr. 2022 à 23:24, luigi scarso 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

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 -----------------------------------------------------------------

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

I see.

This should be documented properly, thus I should not have wasted my time and yours. hm, we cannot come up with all possible examples of usage (running on a different is a comparable topic that has come up but is not for the engine to handle) ; lua is documented well (arg) and callbacks are mentioned in the luatex manual so that's where it ends for us and where imagination of the user begins;

there have been plenty of (progress, development, usage) articles and presentations over the dev period and beyond and we don't see it as our task to come up with possible (generic) solutions for everything in principle we are only responsible for usage in context and discussions about solution for that happen on other mailing lists fixing bugs is of course another matter and gets our attention but here also the tex live release schedule nowaways determines when somethign gets done 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 -----------------------------------------------------------------

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

Le 8 avr. 2022 à 11:19, luigi scarso a écrit :

On Fri, Apr 8, 2022 at 8:23 AM Jérôme LAURENS mailto:jerome.laurens@u-bourgogne.fr> 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

How do you manage \jobname-<tmpname> when the process has been killed ? In bash, quotes are already used to escape spaces in file paths such that ‘(‘ and ‘)’ should already be escaped for free.

Le 4 mai 2022 à 09:26, luigi scarso a écrit :

On Wed, May 4, 2022 at 8:11 AM Jérôme LAURENS mailto:jerome.laurens@u-bourgogne.fr> 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 _______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-luatex

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. JL

Le 4 mai 2022 à 13:08, luigi scarso a écrit :

On Wed, May 4, 2022 at 12:37 PM Jérôme LAURENS mailto: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