Would anyone here consider the catastrophic failure that ensues when who does \newenvironment{}{X}{Y} a bug in LaTeX? Motivation: LaTeX only checks for the existence of the macro that would be associated with the \begin part and then overwrites the meaning of \end as Y. If this is not a bug, what other examples would fall under this type of absurd definitions?

@Werner worth raising as issue in the latex github. we changed things not so long ago so that \newenvironment{group} did not over-write \endgroup so I'm a bit surprised \end didn't get checked here. I'll have to trace to see what it's doing

@Werner Hidden feature… ;-) Similar to a situation that was presented some days ago: \begin{tikzpicture}\pgfmathsetmacro\end{2}\foreach \x in {1,...,\end}{...}\end{tikzpicture}

@Werner hmm "not so long ago" % \changes{v1.2h}{1994/11/24}{Added test for \cs{endgraf}} maybe it was longer ago than I thought:-)

@Werner (@egreg) the problem is that with the empty string the test for the matching end command fails as \expandafter\string\csname\endcsname is not \ it is \csname\endcsname so removing a \ and adding end does not result in a test to see if \end is defined.

@DavidCarlisle Switch to e-TeX test?

@JosephWright possibly although would still need to be careful about csname\endcsname I think

@DavidCarlisle I meant explicitly test for an empty argument

@JosephWright or tell @Werner to use \NewDocumentEnvironment and get \NewDocumentEnvironment{}{X}{Y} ! LaTeX cmd Error: End of environment '' already defined. :-)

@JosephWright \newenvironment is assuming that this raises an error:

Hmm, the biggest problem in tex.stackexchange.com/q/632860/52406 might not be of TeX nature. 1) The first lines depend on $n$, but then all of a sudden $n$ becomes a summation index, and they depend on $N$ instead. Also, the problem that is asked for, the substitution, should be so standard if one is doing Fourier series, that one should not have to waste so much vertical space on it. Sorry for bothering you, I just felt had to write that somewhere...

@mickep Apart from the dubious derivation, people often confuse a printed document with the blackboard.

@egreg Sometimes we have students handing in photos of written blackboards. (I must admit that I have nothing against that as long as it is readable.) Stacking formulas as in the question above is not a good style (imo). Better explain by words why this or that hold. And of course I do not have to tell you that. :)

@barbarabeeton @samcarter ooh twitter.com/shouldhaveaduck/status/1490326592530235395

@egreg By the way, I saw that you answered tex.stackexchange.com/q/632798/52406, and you certainly gave OP what OP asked for. But I got curious, would you typeset it tight like this? (I usually do not work on differential forms and Hodge star operators and such things, so I do not know what is the standard.)

@mickep Neither do I, but looking at some examples it seems that it's used like that.

@PauloCereda ohh :)

The end of the world must be near -- no easybook update to be seen at ctan.org/incoming

@samcarter oh no

@samcarter no chocolate :(

@DavidCarlisle -- This question (tex.stackexchange.com/q/632894) reports a bad link pointer when a theorem starts a new page; the link goes to the end of the previous page Since I thought that might be a problem with amsthm, I tested that. But it's okay with amsthm, so the basic theorem mechanism in the core is faulty. Please check.

@PauloCereda sad day!

@barbarabeeton imho not much one can do now. The \refstepcounter is probably too early. Such problems can only be resolved by rewriting the commands with proper hyperref support in mind (and this is also true for ams code, e.g. github.com/latex3/hyperref/issues/8)

@barbarabeeton the core knows nothing of links so it would be hyperref,

@barbarabeeton the user can presumably fix any bad case that arises by putting \clearpage before the theorem so the page break happens before the link anchor is seen

@PauloCereda best not to feed chocolate to ducks, it spoils the taste of the meat

@DavidCarlisle -- Okay, thanks. Again, history and backward compatibility. But I did try a test with amsthm to decide whether I should forward a note to AMS tech support. I'm personally not happy with the \clearpage approach though. Could leave a short page, which will get other complaints.

@DavidCarlisle oh no

@barbarabeeton I just posted an "it's not @UlrikeFischer's fault" answer

@barbarabeeton the issue only arises if the page break happened at that point automatically so if as a final edit you do \clearpage at the same point nothing too bad will happen (if flushbottom is needed could use \pagebreak instead of \clearpage but I'm not sure that always works, probably would

@Skillmon At the moment the plan is just l3keys, but that's largely because this is mainly aimed at packages 'transitioning'

@DavidCarlisle What do you think about allowing executing gnuplot on texlive.net?

Asking for a friend because of tkz-fct on tikz.fr

@StefanKottwitz I did wonder about allowing pygmentize for minted as well, but currently I'm relying on not allowing shell-escape and gnuplot can probably execute arbitrary code if you ask it to, so I'm not sure.... it's easy enough to add them to the white list of allowed programs of course.... apart from it not being allowed it's not installed, although I could fix that I guess... gnuplot: command not found

@DavidCarlisle ooh, arbitrary code. sudo gnuplot get beer

@StefanKottwitz it's your host, you get the beer

@DavidCarlisle Ooh, sure. With peanuts, Sir?

@StefanKottwitz and crispy duck pancakes

@DavidCarlisle Manageable! I know a duck who doesn't read the fine print before clicking the "Compile with TeXlive.net" button.

@StefanKottwitz meanwhile doing a tlmgr update --all at texlive.net, as I was there. 232 updates....

@DavidCarlisle easybook

@StefanKottwitz @PauloCereda will be pleased

@StefanKottwitz sourceforge.net/p/gnuplot/bugs/726

@DavidCarlisle Ok!

@DavidCarlisle -- I'm in the process of updating the links to the UK TeX FAQ. I've fixed about 30, and there are about a hundred more to go. I've limited myself to no more than ten a day (that already pollutes the front page terribly), so that means it'll take about two more weeks to get through them all. I'm checking every change as I go.

@barbarabeeton Ok thanks, I really don't care about the front page I never use it the page tex.stackexchange.com/questions (from the questions menu item) always seems far more useful and in a sensible order

@barbarabeeton while checking can't hurt, if the link is wrong after that change it must have been wrong before, it will not have broken just because of a change in the dns.

@DavidCarlisle -- I realize that, but think it's still better than getting a "not found" or "can't connect". Do you think it's worth an announcement in my next TUGboat column about the url change?

@barbarabeeton yes it might be good, the official url has been texfaq.org for a longtime but no doubt there are still places linking to tex.ac.uk

@barbarabeeton yes but what I mean is you could probably do a global replace without checking, for the \\ changes got the edit time down to 5 sec a page (the system will not let you post faster than that) which meant we could do hundreds of pages at a time, so the front page has a short term hit but soon passes.

@DavidCarlisle -- I'm not real good at scripts, so someone else would have to exhume the double-slash scripts, rework them, and run them. I'm still finding the tex.ac.uk in comments; I suppose there's no way to fix those, so when it looks important, I've added a new comment with the new url.

@barbarabeeton yes thanks, a human eye will always be better. If your search had found thousands it would probably be worth scripting it but for <200 as you say fixing things by hand and is probably good. incidentally if you come across anything that seems outdated, and we should fix at the faq let us know, many of the answers there are embarassingly old.

@DavidCarlisle -- okay, will do. I've already updated one meta entry to say "formerly maintained by Robin Fairbairns". How is Robin anyhow?

Btw. as other sites (latex.org etc.) now have a lot of deprecated links to, I'll run commands like UPDATE posts SET post_content = REPLACE(post_content, "www.tex.ac.uk", "texfaq.org") just together with the new FAQ page naming convention. In any case there's no hurry for older posts, just good to fix links in the long run.

@barbarabeeton out of contact as far as I know

@DavidCarlisle -- If you hear anything, do let me know, please.

@DavidCarlisle and @JosephWright -- Any chance of adding a brief history of the FAQ on the FAQ site? That would be really nice. (I'll mail you a copy of what I've written for TUGboat; it could do with a few more historical facts.)

@barbarabeeton yes we could have some more "about" page details..

@DavidCarlisle -- Thanks. Is the ID at the bottom of a page supposed to match the ID in the url? I've found one that doesn't quite. If they're supposed to match, I'll record any I encounter that don't, and report.

@barbarabeeton yes should do

@DavidCarlisle -- Ok. Here's the one I noticed so far: "startup" has "Q-startup" at the bottom of the page.

@barbarabeeton yes they all have Q-

@DavidCarlisle -- Ok. You know about that, and it's generic, so I'll only report other differences. Thanks.

@JosephWright and it's locking out the other keyval solutions (or rather: forces them to again use non-userlevel functions, I bet I can hack things to get this working, but this shouldn't be necessary here, imho)

@Skillmon Well yes but ... the entire idea is to get stuff supported at the kernel level so there is a single interface

@Skillmon Do you really fancy finding names that look 'like' \DeclareOption for each keyval implementation? It's hard enough finding one or two good ones :)

@JosephWright but I already know a good one that I like (even though it's a bit minimal at times) :)

@Skillmon Really? That I know of, in release code there are none for keyvals :)

@Skillmon Guess I'll need to read in the obvious place

(also, I know a bloke who wrote some package that provides an interface for package options for pgfkeys)

@Skillmon Yes, but it currently doesn't cover this area

@JosephWright true, but it could.

@Skillmon It would be .. work

@JosephWright not if there was an interface for this. Then it would be the following effort: Add a single macro for this option to pgfopts, add three lines of documentation. Done.

@Skillmon You miss the work :)

@Skillmon Nope - you need to document in the package all of the interfaces it formally supports. The ltkeys documentation explicitly has to cover .if, .code, etc., depending on what we add, as the entire point is to provide non-expl3 key handing for options. Same for pgfopts if one wanted to opt in there: I'd have to document which handlers I was formally supporting, with details

@JosephWright the work the kernel team would have doesn't look like that much more compared to the work it has anyways with the l3keys support (but obviously I could be mistaken here, since I haven't looked at the way you used that to support this).

@Skillmon There's \DeclareOption*-equivalents still to do, and that would need to be covered by others - I have to implement yet

@Skillmon but what interface do you have in mind? And why do you think that it is important to support more keyval systems? Imho document options are normally quite simple, so what would you need pgfkeys for?

@UlrikeFischer we don't need pgfkeys, but we already have pgfkeys. It's that simple. And extending the mechanism to resolve option clashes to other packages doesn't seem like a bad thing, imho.

@Skillmon Going forward, for packages package based around pgf I'd recommend using the new kernel key option handler to get a consistent package interface, the options can set up pgfkeys if that is needed without actually using pgfkeys to implement the option parser itself.

@JosephWright also agreed (except for something like debug, this makes sense to be load time, imho)

@Skillmon Even there: most other programming languages don't have 'load a library with options', just 'load a library'

@JosephWright sure, but LaTeX has (and that's totally not my fault)

@UlrikeFischer Interface I have in mind:

@Skillmon yes I saw that but I don't understand it. Should that be used by normal users?

@UlrikeFischer no, by package authors, either by authors of packages like pgfopts or my expkv-opt, or by package authors using one of those.

@UlrikeFischer I think the idea is to install in a package

Is main down only for me or for you as well?

@Skillmon On and off

@Skillmon on and off

LOL

@Skillmon I guess the thing missing here is a motivation beyond 'because one can' - I was reasonably serious with 'don't use package load options' - the main target is existing packages which can move option to be 'softer' - the fact it uses l3keys behind-the-scenes doesn't mean one needs to know l3keys to use it

@JosephWright for the other thing it would/could be existing packages as well, just reducing the burden of migration. If a package currently uses pgfkeys I don't see why its option handling should be rewritten from scratch. And also, yes, 'because one can' is another great reason for me :P

@JosephWright also, the ltnews are written in a way that one could read that this will be added to the behaviour of l3keys2e, as I said, I haven't looked at the code, just at ltnews.

Oh, and as I said, I'm confident I could hack into this; and I will, I like the idea of resolving option clashes this way, I'd just rather not.

@JosephWright I get an error if I try to use .code with the new code and this here looks a bit wrong:

 \@@_tmp:nn
    { code }            { code }
    { legacy_if_set:n } { if }
    { tl_set:N }        { store }
    { usage:n }         { usage }

shouldn't that be { .code:n } in the second line?

@Plergux -- Have just seen an announcement of blizzard warnings for Reykjavik, from the U.S. Embassy. Hope all goes well. We've almost recovered from ours. There are still snow piles along some streets, left by the plows, and we had an ice storm last night, so now they're ice covered. But the days are getting longer. Stay warm.