@PauloCereda that usually typesets :q or moans at you to add other random letters to really plead to get out, it never actually quits as far as I can tell.
And I got this weird error that may shed some light.
! LaTeX Error: Trying to overwrite `smyt56.new.tex'.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
...
l.15 ...econtents}[overwrite,noheader]{smyt56.dat}
You can't write to the file you a reading from!
Data is written to screen instead.
@UlrikeFischer Just to clarify, the package installed a binary link called lualatex-dev, which points to luahbtex. Except that the latter doesn't actually exist, as far as I can see.
@DavidCarlisle The file I'm currently testing with is smyt56.new.tex. The file I'm trying to write to (using filecontents) is smyt56.dat. They aren't the same file. They might be considered to have the same jobname, if smyt56 is the jobname in both cases.
@PauloCereda I've got more than one irritable response from him.
@PhelypeOleinik @UlrikeFischer @DavidCarlisle --- maybe I'm misunderstanding the problem, but I think that when I do \includegraphic{"Figure 1".pdf} (or \includegraphic{"Figure 1.pdf"}) I use the file Figure 1.pdf --- I agree that it's better avoiding spaces in filenames, but I just publish in a journal that wants the figure files named like that...
And the " problem is that in principle " is forbidden in VFAT... so I think windows is doing some nasty trick (once you got all nasty with case insensitivity, one trick more or less...). But in *nix it's a legal char for names. Even worse than space, I agree.
@Rmano in a current latex \includegraphic{Figure 1.pdf} should work. And I don't see how a journal can force you to use such a name or why they should do it. Simply tell them that it doesn't work for you, and if they insist they should by you a new computer.
@UlrikeFischer Yep. It was nowhere in the rules but then forced me to call the figures like that when uploading them... and then the compilation would fail without the quotes :-(
@FaheemMitha any mwe? If there is a bug in filecontents it could get fixed before the next release if it's reported now but soon it will be too late for code changes
@UlrikeFischer no I think keep with same plan as last time generate it so users can access it but don't load it, I may ping Uwe again before tl2020 see if we can get an update for robust commands as well as that
% Should not be needed after \textsf{xcolor} updates
% \begin{macrocode}
% \RequirePackage{xcolor-patch}[2019/12/15]
% \end{macrocode}
?
maybe add .... users can explicitly load to fix Gray color model until then
@UlrikeFischer
e43eaf3 (HEAD -> master, origin/master, origin/HEAD) commented out xcolor-patch, as documented at the last release
596287c don't build tds.zip for this simple structure
3c07861 over and under full boxes in doc
d1184be extra level of expansion to avoid errors if using default link colors in hyperref
