@HenriMenke amsmath's extra support for nested accents.... I only have tl2020 and 2021 easily to hand @JosephWright do you still have the older ones, is this recent?
@HenriMenke no but possibly \someaccentoperator{ \someotheraccentop{base}_{subscript} } makes sense mathematically and they probably all mess up the same way.
@DavidCarlisle Aha! With amsmath the definition of \widehat is \mathaccent"0362\relax but the definition of \hat is \mathaccentV{hat}05E. Looks like \mathaccentV messes something up.
@HenriMenke yes mathaccentV is the "fix stacking of double nested accents code" but it could probably detect the subscript and revert to the standard latex version which is just the \mathaccent primmitive
@JosephWright not sure ther3 is a right or wrong on whether # should be doubled, just need to document which it is, but if you want to not double I think it's OK to use \expanded, not sure I buy the argument that etoolbox has not gone beyond etex, pure etex hasn't been distributed for years and since we (almost)_ have \expanded being used already in teh format it should be available for packages I think.
@JosephWright is a format without expanded I think doubling is more natural as it is basically append+edef and edef requires doubling (even if you managed some slow token by token expanded emulation of expanded to not require ## I don't think I'd use it here)
@DavidCarlisle Indeed: I guess the issue is that PL added the idea in the first place (things like \AtBeginDocument avoid it by never providing an \edef version)
@JosephWright at the start of 2e we did change several things to use \the\toks@ (\@ifdefined?) to avoid the ## but in all cases that didn't involve a visible edef just the one added to expand the \the once.
@DavidCarlisle e-TeX+ makes things more straight-forward, but it's a question of whether I can allow \expanded - it's a define change-of-scope (etoolbox for example doesn't use \pdfstrcmp, so it's string test is non-expandable. But perhaps that's just an age thing)
@JosephWright I think so, it's clear that it shouldn't have used \expanded when it was written, but now not so clear. It is supposed to make extensions easily available, but it's odd if it doesn't use extensions that are freely used in the format code.
@UlrikeFischer Since it accesses backend internal variables it would probably belongs into the LuaTeX backend-pdf file. We could also just throw it into expl3.lua to avoid adding a separate Lua file for the backend and to have it defined before the backend is loaded...
It might be a start for a bigger project though: Define Lua accessors (and manipulators?) for all expl3 data structures (or at least the ones where it's reasonable).
@JosephWright I started some experiments with that. I like the architecture much better, but since GitHub doesn't seem to like caching containers I fear that there will be quite some overhead at the start.
@MarcelKrüger For me the lack of a cache is a real issue: it's fine if you want stuff that is from a massive package-based network, but I don't want to hammer CTAN for every test
@MarcelKrüger What's better about the architecture?
@JosephWright You have more control and it's more composable.E.g. I'm pretty sure that Travis uses some Container setup too, but Actions allow you to actually control which Containers run. Similarly release management is very extensible while Travis basically only has a list of fixed things it implements. And you can e.g. write a `l3build1 workflow once instead of replicating it in every repo.
@JosephWright You can emulate it through containers though. Create a repo which regularly creates a container with the current TeX Live, then use that container in Actions. Then there is no need to access CTAN all the time.
@JosephWright Also there is a cache action, I'm not sure how usable it is for us though.
@MarcelKrüger Ah, but that would mean all the repos have the same packages ... I quite like the idea that each test rig is really just the required set up
@JosephWright I thought about trying it in luaotfload and see how it goes there. Then we can relatively easily adapt it to the remaining repos on a short notice if it becomes necessary.
@JosephWright I also did some experimenting when they cut my credits (github.com/Rmano/quack, probably too low level for you), then they refilled me... but I am happy to use "test with a distro setup" for my packages, so I didn't explore caches...
@JosephWright yes, I supposed it. But it seems to me that you can cache directories, so maybe doing a "portable" install and then an update... where I saw this? I suspect in one of your repos...
@JosephWright Normally they only create the cache if it didn't exist yet, but it might be possible to provide a cache key which always changes but indicate that we still want to load existing caches. Not sure if that really works though.
@AlanMunn Well yes - the funny thing is that v1 was only about for something like 18 months
@samcarter_looks_forward_TUG'21 That was a v2 option, but early v2, and I renamed it for (I think) v2.2 - I missed that one in the initial v3 release as it's not in the v2 manual any more - but that was not deliberate
@samcarter_looks_forward_TUG'21 I did think about having v1 support in v3, but I really feel people should update their input at this point
@JosephWright Although I basically agree, the problem is that sometimes users have no control over the version they use. Try sending something to IEEE that depends on a reasonably recent version... (things are a bit better now thanks to overleaf, though).
@Rmano I'd use the kernel mech if you want to do that: make a copy of the .sty and let the kernel handle the loading - that's what I've done for v2 fallback (I could have done if on a more granular level, but essentially I've always used semantic versioning, so newer v2.x can be dropped in for older v2.x)
@Rmano I guess I'd look at the TL version in 'LTS' Linux releases - they might still have say TL'18, but not nowadays much older
@Rmano It's more for me that there are about 130 options in v1, of which almost all got renamed in v2, and which I've tightened up again for v3, so there's lots of rather dull code
@barbarabeeton read on down, Henri came to that conclusion as well, but probably amsmath shouldn't make the outoput that bad even if the input is a bot strange (especially as it produces more or less sensible output without amsmath)
@DavidCarlisle -- Yes, I saw that later. But I've just tried testing this on the tug box. (pdflatex has a fatal format file error, so I tried xelatex instead,) With xelatex, it looks okay, modulo the dot too far to the right. Peculiar. (Output the same with plain xetex.)
@barbarabeeton it's a 32bit machine? (for the format error)
@barbarabeeton are you sure you didn't correct the accent nesting? I get the same weird output with pdflatex xelatex and lualatex (as I'd expect, as it is a macro level issue not due to the engine's math layout)
@DavidCarlisle -- Ah, okay. I thought that was a bit odd. I don't think I ever saw that while I was at AMS. If it had happened, someone surely would have complained. When I left, production was still running under TeX Live 2017, and amsmath was the version that was turned over to you guys, no subsequent changes.
@HenriMenke Doesn't it, though, mean you have to spawn the shell multiple times? (I guess I'm also more comfortable have the profile and install script as independent files in their own right, not in what I think of something that should look more-or-less like a keyval list)
@MarcelKrüger Yes, but I suppose I like the idea that each install should itself be specific: 'this line installs the test system itself, etc., as then you can easily copy-paste the script and know what to modify. It's a personal preference
@MarcelKrüger I know that one can argue the time business here: comments for a single list mean only one tlmgr call, so it's faster
@MarcelKrüger In the end it's not too bad either way, of course: testing siunitx takes about 2 minutes, most of which is the tests themselves, whereas for something like LaTeX itself, the time is all about the tests
@HenriMenke In the grand scheme of things, all of these setups are similar - provided you are using a minimised-ish TeX setup, it's quite fast to install (someone suggested using a TL image, but that would be ... big)
@HenriMenke @MarcelKrüger was wondering if that works properly: does it update the cache after tlmgr update?
@HenriMenke I use /tmp/texlive only because there was an issue in expanding ~ in the profile file when I first set up on Travis-CI, and it means handily my VM clears things out every boot
@JosephWright given that the main program being used is tex and we are all installing bleeding edge upstream texlive, the stability level of the OS is probably a bit arbitrary isn't it?
@JosephWright We have dependencies on system fonts and on my system they get updated quite often, so having old versions in the CI is annoying. But normally it shouldn't matter for most TeX testing since it's pretty system independent.
@JosephWright Since nothing beside the TL version should have an influence, changing it every now and then feels might actually be an advantage: If something gets messed up, we probably introduced unwanted dependencies.
@JosephWright Something completely different I was thinking about: As the whole TeX Live pdftex format issue showed, there are people who build their LaTeX formats on Linux and then use them from Windows. Do we handle this in expl3? Especially is \sys_if_platform_windows:TF true in that case?
@JosephWright Yes, I almost have it (but for laziness I didn't try to adapt the circuititikz-x.y.z.sty in the proper format). (Sorry for the delay, I had to run away for unrelated things)
@JosephWright Right, especially since determining the platform requires opening files and therefore isn't very fast. But we should document this clearly since it goes against TeX Live conventions.
@PauloCereda Well, that's what we are doing by writing it into the format but when people use the format on another system the information changes, so the memorized data is wrong.
@PauloCereda It can be scripted with Lua, so I obviously love it. I can't really compare it with recent vim versions though since I haven't used vim in recent years.
