@DavidCarlisle no he meant the tex question - as he pinged all team members ...
@Johannes_B well align gives a probably better error message (! Paragraph ended before \align was complete.) , so in theory one can redefine equation. In practice one would have to investigate the side effects of such a change on existing documents. If the user really want this he/she should add an issue on the right page. I normally don't have to delete the aux-files to get correct references so I have no idea what is the problem there.
@Johannes_B Ok I can read the page in Internet Explorer, it would be possible (but tricky) to do something about the \par error, but really the aux file is almost always user error and there is nothing that can be done. If you get an error while tex is writing the file then (especially if you quit with x or crtl-c rather than scrolling past) the aux file quite likely has mismatched { or even half written command names if you kill tex from the shell before it flushes its write streams
@Johannes_B so when the aux file is read back in you get low level tex syntax errors and latex has no way to trap them
@UlrikeFischer @DavidCarlisle @Johannes_B Cert updated today. I didn't automate renewal yet, as whenever I got spare time I usually see if I can answer something there.
@UlrikeFischer That error message is possible at the expense of reading the contents of align as a macro argument, which I wouldn't do for equation. Possibly redefining \par inside equation could do better. I see this error popping up from time to time, but it doesn't seem so frequent.
@egreg I agree. Imho we should wait if a real issue pops up.
@KhaledHosny I think I made over the years more than 5 bug reports about hyphenation interfering with ligatures, dashes or not working as expected at all. The last one is e.g. github.com/u-fischer/luaotfload/issues/22 ...
@DavidCarlisle I pushed the hyperref test files. Imho the rest (in the ignore folder) is not useful. Some of the testfiles are rather long, I'm not sure if they really give stable tests, but we will see. I also added a few of the test files I made when handling some of the issues (the one starting with numbers). I did run the tests also with an experimental luatex and got failures in all pdf-tests due to different spaces:
@UlrikeFischer even though there is a oberdiek.luatex.lua in the current test directory, does Heiko's loader check that oberdiek.foo.lua is in an oberdiek directory?
@UlrikeFischer luatex-test2
@UlrikeFischer arggggggggggggggggggggggg
luatex.sty does
local script = "oberdiek.luatex.lua"
local file = kpse.find_file(script, "texmfscripts")
@UlrikeFischer which doesn't include current directory I think.
@UlrikeFischer which explains why my mktan build script has the comment # Lua need to be here for doc generation must fix this one day (I had to install the lua before running the doc) @JosephWright is going to have fun making l3build support this....
@UlrikeFischer because all your tlg have normalised paths as ../ but since the files are now local I globally removed the ../ and all the tex file paths now match but that lua one didn't as it's pulling the file from the installed tree (so testing the installed one not the one just extracted)
@UlrikeFischer it's a problem for the build as the paranoid consistency checks mean that the documentation for luatex.sty version zzz gives a fatal error if it is run with a different lua module version
@UlrikeFischer I suppose I should give l3build a local texmf.cnf that adds current directory to TEXMFSCRIPTS
@UlrikeFischer I could be persuaded to go back to that (although it's tricky to check that the correct file is found as any file found in any texmf tree gets normalised to ../foo an advantage of the local files is they show up differently in the normalised log
@DavidCarlisle You could perhaps add a step to install in a local texmf and nevertheless unpack in the current directory. Then the script would be found.
@UlrikeFischer my existing build script already moves everything to a tds structure (so it can make the zip..) so I'd just have to set that directory as a texmfhome, I guess...
@UlrikeFischer previously as I comment above I just always installed it in my default ~/texmf tree each time I built, before any tests, but I was hoping to avoid that, which presumably means getting l3build to use a non-standard texmf tree, just while testing?
@UlrikeFischer yes I remember that got added, will do that then I suppose (but if I have to do that anyway the benefits of using the local directory copies is less, perhaps I will just build the teds structure then test that, as you suggested...
@DavidCarlisle I do have (in luaotfload) a texmf.cnf in /support with TEXMFAUXTREES = ../../texmf,, and in build.lua checksuppfiles = {"texmf.cnf"} and my runs then find the lualibs files in this texmf.
@DavidCarlisle but l3build still copies all the source files from luaotfload, so they are in the current directory - I don't know if this can currently be avoided.
@UlrikeFischer if your l3build check config has installfiles={} sourcefiles={} unpackfile={} then nothing gets copied, that's what I originally had in oberdiek/build.lua so I could run l3build check without it trying to make everything
@marmot -- this is brilliant! i just got a comment on an edit i made to an upcoming tugboat article. i questioned the number of items reported; the comment: "I was once a mathematician, so can't count by definition". i shall observe editorial confidentiality and not divulge the identity of the author.
@marmot -- i sure wish i had some help today. yesterday, my cubicle was subjected to the semi-annual scrubdown, and i had to clear everything out beforehand. it took three plus days. now i have to put everything back. i've already done a lot of sorting of accumulated papers, but there's still a lot to go, so it's three more days at least before i'll be back to "normal". sigh. no ducks in the neighborhood to help with that.
@samcarter -- the "submitting paper to arxiv" question has been closed without an answer. although it's a bad question and legitimately closed, a "token" answer repeating the information in the comments would be more useful for other seekers of answers to such a question than the present situation. do you know if there's a site-wide policy on such matters?
@marmot -- but it looks very like the throat of a supersonic wind tunnel.
@barbarabeeton As far as I can see @samcarter was not among the ones who supported the closure. And I would not have closed that question either. TeX users may get the impression that the TeX community is snobbish and switch to some commercial typesetting system. The long-term effect might be that I'd be forced to write my papers and so on with Word, say. This is a horrible perspective.
@barbarabeeton Which wind tunnel? (And sorry to hear about your clean-up issues. We do have ducks and turtles in the neighborhood, but so far I've not seen any who was willing to help. What does "I was once a mathematician" mean. You can't lose your math skills over night, can you?)
@barbarabeeton Yes, but this is actually a bit annoying. It happened to me a few times. "Your code throws errors." -- "What are you talking about, it just runs fine." ...
@DavidCarlisle I see, so they are indeed very close to theoretical physicists. ;-)
@marmot -- the wind tunnel was in the aeronautical engineering building at johns hopkins university. (don't know if that one still is.) i worked there as a engineering draftsman for a couple of summers while i was in college. "b.c." -- "before computers".
@barbarabeeton We don't know what reality is but I'd like to argue that it is quite likely that the mathematician are closer to it than they might think. ;-)
@UlrikeFischer I thought it is that the user just did not realize that the code has errors because overleaf suppresses them, but the arXiv does not suppress them.
@marmot -- even if overleaf doesn't make it easy to review one's errors, i'm pretty sure the person who asked that question realized that there could have been errors. so reopening and giving it an answer does make sense to me. (many times i keep running even though there are errors; often i do get output that is useful for correcting those errors. but i always process from the command line, so (almost) nothing is hidden.
@samcarter -- we have a stuffed moose head made of chocolate-colored velvet, so it's a "chocolate moose". (but that doesn't translate so nicely to german.)
@barbarabeeton The question is not about how to avoid or correct errors. The OP knows that there are errors and that arXiv rejected. He wants to know if he can avoid the hassle to correct the errors by simply uploading the pdf (and he already knows the answer as he tried it). Before being able to help with the concrete errors one muss get the message through that there is no other way out ...
@UlrikeFischer -- then the answer should be "arxiv cannot handle files with errors, so all errors must be corrected before submitting files to arxiv". (not contradicting your suggestion, just using a sledgehammer to drive the message home.)
@TeXnician @samcarter In the guide TeXnician found there is: Wir fragen unsere chinesischen Freunde: Wann gibt es ein Paket für Pandabären? We need a panda in \tikzlings!
@marmot I really want to do it. I do not have many points to give, but you deserve them for responding quickly, simply, and being an excellent collaborator
@marmot how? I don't see "start a bounty" neither in my question nor in your answer
@manooooh I think you should save the bounty points for something really brilliant. (And I really do not lack reputation points, not that I care.) And I really don't know how to add a bounty. I did that, but I forgot.
I am writing styled text to an external file (using the newfile package). I can successfully style the text with many attributes, e.g., \large\mdseries\itshape. But, very puzzling to me, when I style the text with \footnotesize, I get an unexpected "Undefined control sequence" error, and I can't ...
@JosephWright I fixed it (just pushed Ulrike's tests a few minutes ago) I managed to smuggle a texmf.cnf into the testfile suppor. The problem was that Heko's lua module loader explicitly calls kpathse on the texmfscripts path which doesn't include . by default so even when everything copied to local directory it didin't work...
@JosephWright I wanted to get the tests to pass, then stage 2 is to stop generating luatex.sty/oberdiek.luatex.lua as it's all obsoleted by luatexbase/ltluatex anway
@JosephWright they all now pass. I can't really get l3build to do the build the bundle until I make it read the manifest but I want to leave it and get teh kernel updates done if I can
@JosephWright "really needed" is a hard word. But in general I would like "realistic" tests. Which means that if a file is search for the user with kpathsea in a texmf then I want kpathsea search in the tests too. With the texmfcnf setup + l3build install it actually already nearly works, only that I need to figure out a sensible method to prevent l3build to copy the source files to the test directory. Probably I will use a specific config for this.
@JosephWright yes, but as @DavidCarlisle's problem showed (and I have something similar with a kpathsea-search of lua-fonts), the current directory is not always the first location in the search path. And even if it is, you can't test the "normal" search pathes if everything is in the current directory.
@GuM "In this case"??? ;-(. Add an issue to the latex2e tracker.
@UlrikeFischer OK: we could either have an explicit 'this is the list of files to use in tests' variable, or a 'exclude these installed files from copying' variable
@JosephWright I just tried @DavidCarlisle's idea to set installfiles={} etc to empty in a config-file and then run l3build check -cconfig-main but this doesn't work. l3build nevertheless copies all the source files. Is this expected?
@UlrikeFischer ah it worked for me but I was using the main build (as I didn't want l3build to build anything so disabled all but check) I suppose the problem is that its building off the main config hmm..
@DavidCarlisle I managed to suppress the copying by using if options["target"] == "check" in the build.lua. But it only worked after I cleaned up the build folder. So I will have to find out, what in the build folder was used .. @JosephWright.
@UlrikeFischer yes but it's more that, you give me 100 or so tlg files, I change the build so they are wrong, and I read all the diffs and decide they are all white space and so OK. At that point all the correct tlg are in the build tree with the "wrong" names foo.log so I just need to copy the files to the test source area, suitably renamed, but save doesn't do that and you can't say saveall so it's simpler to write a shell script to do it. In practice that is always how I work,
@DavidCarlisle I know;-). Actually there was a discussion about a "saveall" option: github.com/latex3/l3build/issues/48. I just had a number of failures in tagpdf due to the new message format and imho some option to resave a bunch of files in one go would be nice. @JosephWright.
Class jurabook Warning: This class is designed for german documents only,
(jurabook) so please use 'german', 'ngerman' or 'babel' package.
(jurabook) I will proceed, but results will be unpredictable.
@DavidCarlisle people using \ifx like that shouldn't write classes, go away and then let me fight with it 10 years later ;-(. The class writes the argument of section both to the text and the toc which means that you can use \\ to insert line breaks. I had to rewrite all the stuff (and so discovered also the bug).
@UlrikeFischer Er… No, wait—I’m afraid I didn’t explain well what I meant. I had asked why commands like \small were not made robust, and this question was not rhetorical at all: I was asking whether this had been done on purpose, for some reason I didn’t know. Your answer and David’s indicated that that was not the case, and that was what I was referring to with my “in this case”.
In other words, with “in this case” I actually meant: “Given the fact that two answers (those given by the two persons I’m replying to) indicate that this has not been done on purpose, but is probably simply an oversight”, etc.
(“were not made” -> “had not been made”)
By the way, meanwhile I realized that declarations like \itshape and \mdseries has always been robust: this is clearly stated on p. 226 of the 2nd edition of Leslie Lamport’s book, which also clealy states that, instead, the size-changing declarations are fragile.
@GuM At the time LaTeX2e was released, memory available was very scarce and making a command robust requires two control sequences. Doing so reduces the string space available for labels, for instance. On some machines, loading amsmath could mean having room for just a few labels.
@GuM Thus the decision what commands to make robust had to be pondered.
