@cfr I don't think the edit was warranted, but I would mark it as awkward phrasing if I was copyediting. Technically speaking, you're splitting the verb has | to be dealt with. It's more common (but still wrong) to split the infinite: has to | be dealt with. It would be best to say | has to be dealt with, but still – doesn't really warrant such a small edit.

@DavidCarlisle I found a bug and didn't get a cheque :) (Who knows, maybe it was a dupe.) I'd wager considering the minimal changes made in the last TeX update that there'll be very few given out again.

@DavidCarlisle @UlrikeFischer — yes, the best (only?!) thing to do is load T1 encoding locally. \newcommand\myfont[1]{{\fontencoding[T1]\fontfamily{emerald}\selectfont #1}} or whatever.

@DavidCarlisle / @JosephWright — I'm toying with the idea of following breqn in unicode-math and making all maths symbols mathactive and have them expand to an appropriate \mathchardef'ed control sequence. The advantage being (a) I can support breqn, and (2) more generally, can add "hooks" to symbols. E.g., have a glossary of maths symbols that doesn't require macro input. Anyway, ridiculous idea?

It would also lead to far more efficient switching for \mathfrak and so on -- rather than iterate through dozens of \mathcode's, can just set a switch that branches inside the expansion of the characters. I haven't done any testing, but looking at \tracingall around \mathbf in unicode-math is a bit scary.

I once mentioned to Hans/Taco that having MathCodeTables like CatCodeTables in LuaTeX would be a really Nice Thing for this sort of thing, but it obviously didn't stick in their minds :)

@WillRobertson one could naturally also create some EU1/EU2.fd-files for emerald. I didn't check if the enc-files would need much adjustment. But I don't think that one really need it. As the fonts are for decoration switching locally to T1 is quite ok.

@DavidCarlisle lualatesupport to do: module loading (for the kernel?), whatsit stuff (I'm still not convinced), interaction/compat/fallback with luatex/luatexbase. The latter seems to need discussion so I plan to get the module loading done then write to LaTeX-L.

@JosephWright That's not fair to make me curious ... But you reminded me of a question I wanted to sent to the latex team: Are there any plans for a standarized "ascii input for unicode"? Imho it would be useful if there was some \unicode{20AC}. It would make the input in styles easier then having to use \"a, \thaiChoChang, \cyra, \textalpha, \euro, \texteuro, \hebfinaltsadi. And would make life easier for sorting applications like xindy or biber. (There are some bits in hyperref and ucs).

@JosephWright whatsits not at all sure they are useful, but probably we should do it anyway just do complete coverage rather than pass judgement:-) module loading, not sure quite what you mean here, over require?

@JosephWright the main thing that module stuff adds over require is add a date checking feature to match \usepackage's date option, and in 20 years approximately no one has ever used that option. I'd just drop the whole thing.

@JosephWright Well as long as there is no kernel (where kernel includes fontenc) \ifxetex/\ifluatex I don't see how else you could load specific fontdefinitions through fd-files for xelatex and lualatex.

@JosephWright it's possibly useful but I suspect the lua side should use lua features. If all the lua code you are loading is luatex specific you can do as luatexregisternales/lualatexsupport do and just have a stub tex package that just has teh version information for \usepackage and then loads some lua. But for larger lua code the file inclusion mechanism and logging ought to be just lua facilities, so you can load off-the-shelf lua code

@JosephWright yes I wondered about fixing it last night, but fell asleep instead, and this morning been chatting to you here rather than write code. ...

@JosephWright agreed, it depends a bit whether they want to just tell people not to load lualatexbase in future or if they will want a lualatexbase that emulates everything that it did before (in which case could leave the module stuff to that) as see with etex.sty no easy answer what's best to do there

@JosephWright I don't think that fd-files should be cluttered with "if \directlua defined". Also if someone writes some special fd-file for xelatex he/she shouldn't be forced implicitly to adapt it to lualatex (I even don't know if it is always possible. I ran lately in a luaotfload problem with the deva script: github.com/lualatex/luaotfload/issues/277.)

@UlrikeFischer Well that's the question, really. We end up with two .fd files because we have two encodings, and that's because of the different syntax for the two engines. When we (the team) talked about this last there was a feeling we could provide a suitable wrapper for use in an .fd file that would take engine-independent input and expand to the correct thing. Needs one or two new commands to be added.

@JosephWright @DavidCarlisle: and there again we are at the "if the kernel provides ...". (But such a wrapper for font call don't solve the problem that there is no garanty that fonts work in both engines -- imho xelatex is still better for the indic scripts -- and no garanty that similar font settings call can/should be used for both engines.)

@UlrikeFischer yes but that's a general (but different) problem. As the engines develop and possibly diverge they may have different font shaping, different hyphenation or anything else, but marking that by having two names for the same (Unicode) font encoding doesn't seem optimal, as the font and its encoding is the one thing definitely shared.

@JosephWright @DavidCarlisle: But I didn't say this ;-). I only said that one needs first some kernel tools to be able to get around the differences in the engines. But you can't simply exchange xelatex mappings with lualatex feature files, so there also must be some way to indicate "this font setup is only for xelatex". Using the encoding axis to this purpose doesn't sound very logical but it worked rather good. There has been worser misuses of an nfss-axis ;-)

@egreg that would be a possibility but then all the stuff we didn't copy exactly breaks, local allocation, names for interaction modes \reserveinserts etc. the idea was that if you use \usepackage{etex} you get exactly what you get before so compatibility is increased, but you don't get the new fearures

@JosephWright yes same as good reason for adding extended allocation in the kernel and not making etex a no-op, but getting the exact balance still proves general tex rule that any change breaks something

@JosephWright in the original question etex was loaded by a package (tkz-berge) in the midst of a bunch of other packages. It took me some time to find the correct number of count allocations to get rid of all the packages. -- And I still don't understand why it then breaks the *\c@MaxMatrixCols in the array (using e.g. *{10} instead works fine).

@egreg oh I see it's etex (which redefines the meaning of the counts in count10 etc to be one out) I thought you meant the new kernel allocation was wrong (@UlrikeFischer, @JosephWright) I'll see if I can make etex.sty recover better in new formats)

@UlrikeFischer it isn't an infinite loop, just that matrix cols is a bit big:

> 32768.
l.14 \showthe\c@MaxMatrixCols

@UlrikeFischer, @JosephWright, @egreg, the count register has been allocated twice so been reset....

@DavidCarlisle The problem is probably in that \foreach works in a group, and the allocation macros do their job by local assignments. Indeed, if I use a standard \loop instead of \foreach, the reserved registers are jumped over.

It's always been teh case that you need to load etex.sty before you run out of classic registers...

... so before you just ran out, but now you start using extended registers but the different etex allocatation means that you get multiple allocations (here the latex cmax column counter is being over-written by etex's internal local allocation count. Given that it gave an error before, and gives an error now, i am minded to call it a feature

@JosephWright yes but question is whether we should detect that and try to recover or just let it go.

@JosephWright Maybe! I'd say that if we're seriously adding XeTeX/LuaTeX support to the kernel, we should add at the very least the standard \ifpdftex/\ifxetex/\ifluatex switches (perhaps under the names \ifengineXYZ?) … and on the topic of .fd files, I'm unsure whether we should continue with the bifurcated definition for unicode (EU1/EU2) or define some wrapper commands to unify them. ((Also need to pull xunicode.sty into fontenc in some form or another...))

There are two problems. The one is the allocation of count 256 when using `\foreach`, the other is the wrong value of \c@MaxMatrixCols. The second problem can also be reproduced with a normal `\loop` but with a different length \newcount\loopcnt \loop \ifnum \loopcnt<147 \newcount\a \advance\loopcnt by 1 \repeat

@JosephWright But like @UlrikeFischer says, perhaps that's shortsighted when we consider we might want separate setup for the same font in the two engines. OTOH… it is also a bad idea, probably, to have a font with the same name have different behaviour in the two engines!

That particular combination of packages makes the \count allocator \count10 be exactly the value of \insc@unt where the allocation flips to the extended range so it just manages to avoid a no room error in 2014 but still gets clashing allocation schemes in 2015. I think probably etex.sty can detect this....

@WillRobertson I guess my feeling is it should be possible to have one description of how to use a font for the 'user' and translate that properly into engine directives. Otherwise it suggests that there is a flaw in the engine font loading logic or similar.

@WillRobertson Certainly I don't like having two encodings. We could argue for engine-specific .fd files where that was explicit

@WillRobertson If you look at most of the current EU1/EU2 cases they are mechanical variations only

@JosephWright Well, the vast majority of fonts loaded with EU1/EU2 are (probably) dynamically created in fontspec… One argument for keeping them separate is that the syntax between the engines is coincidentally, mostly, similar. But what would we do, for example, about Graphite fonts that can only be loaded in XeLaTeX?

@WillRobertson the range of "available system fonts" depends on the search paths and the kinds of fonts the engines can read, that is likely to be different in principle.

@JosephWright as I say my guess is no, as I think people will want to load random bits of lua code which won't have that data so it's not really like loading tex code where ypu can say it should have a \Provides... line to play a full part in the system

@WillRobertson hmm I guess I should fork or clone or something that and play locally...

@JosephWright Imho neither EU1 nor EU2 are encodings like the other encodings. They don't describe a concrete set of symbols supported by the font, the enc.def-files don't describe slot positions. I always saw them as "engine instances" of the general unicode.

@JosephWright @UlrikeFischer Oh now finally I understand the MaxMatrixCols issue. It's etoolbox.... 2014 gives no error as etoolbox is loaded early, which loads etex.sty early so all allocation uses the etex scheme, in 2015 etoolbox doesn't load etex, so the kernel scheme is used and allocates counters in the 265-276 range then etex.sty is loaded and over-writes them. 270-276 getting set to 32768.

@JosephWright so if etex.sty detects count10 (etc) already past 255 then it knows another extended allocation scheme must be in place, does it give a warning and stop, give a warning but carry on and define its scheme, give an error rather than a warning?

@JosephWright normally I'd take a hard line as well, but in this case if you get a warning then you might get a later error eg \locbox was undefined, but in that case you were warned, but in the majority of cases the document will just work and in fact etex stopping is better than forcing it to load (so \extrafloats etc work)

@daleif No, with Davids changes their document should normally run fine. They only will get into problems if for some reason they really need etex.

@DavidCarlisle I would probably make it a bit clearer that it is not necessary to load etex. "You probably don't need etex and can safely ignore this message. If you want to force etex to load use ..."

@JosephWright @clemens @StefanKottwitz If anybody could make the images smaller? Just had a real crappy cup of coffee with somebody (well, the coffee was fine, the talk was ...) and now my motivation to do anything is approaching zero. And it is warm. And monday. Die Woche geht echt gut los. latex-community.org/forum/…

@LaRiFaRi Cool! We need helpers there. Just click: Unanswered posts (direct link here, or menu top right there) - besides the currently active threads there's a lot older to reanimate or to complete with an answer.

@JosephWright did you see the comment (Frank I guess) above the bit that's wrong? vvvv

% \end{macrocode}
% Next set of docstrip guards are a bit weird, essentially
% |\@addtotoporbot| ends up inside the kernel and the
% \texttt{fltrace} package and |\@addtotoporbot| shows up in the
% \texttt{flafter} package. Guess that could have been done a bit
% more obvious :-)

quite prophetic given that I then messed up exactly that point while trying to weave in the latexrelease guards in addition to 2ekernel,flafter and fltrace....

@Johannes_B -- yes, i did get the ping, and was investigating whether there was anything relevant in the list of mailing lists at tug.org. (there isn't.) but i live on a push-down stack, and it got pushed. i think a list will probably be a good approach, but i would like to have some discussion first in darmstadt. (oh, i do have to make a list of who to corner there.) if you have a good idea for a list name, please feel free. (i thought of "templates", but that may be too incendiary.)

@Gigili everyone needs to start somewhere but to start a thesis sized document without covering the basics up to \begin{equation} which is covered by the three page intro texdoc sample2e seems to be somewhat brave.

@SeanAllred -- \norm is not provided by amsmath (nor by mathtools to the best of my knowledge). where it does appear is as an example -- with definition in the preamble -- in some sample documentation, and some people simply assume more than is warranted. @Gigili -- whoever made the change at math.se did you a great disservice. just because a user is high-rep there doesn't mean that s/he is an expert in the conventions of latex packages.

@Gigili ignoring the image, juts looking at the markup, the spacing around \text you should not use align for a one-row equation with no alignment points, the spacing around `\text will be wrong and you should use left and right versions of \Vert not two || to get the double bar