## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Show All Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Re: Guidelines on the new hook management Joseph Wright <[log in to unmask]> Thu, 23 Jul 2020 10:19:24 +0100 text/plain (84 lines) On 23/07/2020 03:00, Henri Menke wrote: > Dear list, > > Inspired by issue #900 on the PGF/TikZ repo [1], I'd like to kick off > the discussion on how to correctly integrate the new hook management > system into existing LaTeX package codebases. > > In a naïve adaptation, two code branches would be maintained, with and > without the new hook management. This is quite tedious for maintainers, > especially when trying to integrate this properly into existing CI. > > For me as PGF/TikZ maintainer it is also of paramount importance to > avoid anything similar to the oberdiek-split and iftex-merge > clusterfucks. Back then I had to fix the CI every other day without any > guidance whatsoever from upstream, which was a massive sink of my time. > > Obviously there has to be some transition at some point. Hence I'm > asking how to properly integrate and coordinate the migration this time. > > Kind regards, > Henri > > [1] https://github.com/pgf-tikz/pgf/issues/900 Hello Henri, First, an paragraph aside about the oberdiek split and iftex merge changes. Both of those were mainly issues in TeX Live packaging, which is separate from the case here, which is about the macro layer. As such, the impact of the earlier changes was mainly felt by package authors using CI set-ups. There are a couple of ways of setting up a CI: you can have a frozen set of packages (libraries) available, or you can update to see 'what your users get'. Like me, you've gone for the latter: there are advantages to both, but updating does leave you at the mercy of third-party changes. One could I guess set up parallel tests to 'focus in' on where the issues come from, but that is likely overkill here. (The number of packages to track is sufficiently small to know where things come from.) On the matter in hand, all that is needed is to test for the new mechanism being available, and to use it when it is. That is potentially as simple as      \@ifundefined{AddToHook}        {           % Old code        }        {\AddToHook{...}{...}} if you are using LaTeX, or for code that must work format-neutral      \long\def\@firstoftwo#1#2{#1}      \long\def\@secondoftwo#1#2{#2}      \ifx\AddToHook\undefined        \expandafter\@firstoftwo      \else        \expandafter\@secondoftwo      \fi        {          % Old code        }        {\AddToHook{...}{...}} (I'll cover the possible targets for \AddToHook in a separate email, as it goes with the tex4ht mail in this thread). I've used the \@firstoftwo approach here as I'm allowing for the 'old code' containing unbalanced conditionals. One might of course define the hook 'payload' in a macro and do something like      \protected\def\my@hook@payload{...}      \@ifundefined{AddToHook}        {          \g@addto@macro\document{\my@hook@payload}%        }        {\AddToHook{begindocument/end}{\my@hook@payload}} I've already adjusted beamer in light of the above need, see https://github.com/josephwright/beamer/commit/877c44cc5fd32ef0736fbe66f88a53995c8e1850: beamer used to mess with \document, not with \shipout. Joseph