X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil] [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) Date: Tue, 12 Jun 90 09:47:53 CET From: Rainer Schoepf Organization: Inst. f. Theor. Physik d. Univ. Heidelberg Subject: More on hooks To: LaTeX-L Mailing list In-Reply-To: Message of Mon, 11 Jun 90 21:38:38 GMT from Status: R X-Status: X-Keywords: X-UID: 134 >> Re hooks: does it matter whether a hook is a macro or a token register? >> That is an implementation decision. >I cannot think of anywhere that it matters (provided you dont need to >many of them, so that you run out of toks registers!). >Yes, I was partly wanting to know about implementation details (how >wicked of me) but I agree that it is there properties that are more >important. > At the moment, I am thinking of hooks as token registers, but as only 256 token registers are available this might not be sufficient (on the other hand, 256 is a huge number, isn't it?) >> At the moment I cannot see a need for something like \subtract@fromhook, >> not in the concept of hook I have in mind. If you find yourself wanting >> this, you've already made a mistake )-; >or I am just thinking of something different to you: without you fully >specifying your hook as an "abstract data-type" how can i tell if it >is me or you who is mistaken!! >So please let us know what you intend: for example, will additions >always be local, or always global, or will both be allowed, or will >some hooks always be changed locally and others always globally. > I suppose I deserve what I got...anyway, here's what I have in mind: The concept of a hook first occured to me when writing extensions to the Multics Emacs editor. My way of seeing is therefore somewhat influenced by this. 1) General A hook is a sort of a secret entrance to the code, but in controlled way and place. The programmer who writes a package specifies a point where additional commands (macros,...) may be executed that are to be specified by the user of this code (not the end user!). This is basically what TeX's \every... token registers are. In practice this is only partially true: consider the different ways they are used (e.g., \everyhbox vs. \everypar, \everycr). 2) Questions of locality As Chris pointed out, some things need to be permanently in the hook, whereas other things may be needed only locally, or even only once. From what I said above (the programmer of a package offers a way to extend his code in a controlled way) the choice of how a hook is used/set should be done by the original programmer. Let me first concentrate on those hooks that are exclusively of one type, i.e. either always globally set, locally set, or to be reset after use. All three types are easily to implement: I'm not sure how the interface should look like, but for these cases it might be a good idea to provide commands like \new@global@hook, \new@local@hook, \new@one@time@hook. On the other hand one could equally have one \new@hook command and have several \addto@xxx@hook commands. Actually, both possibilities seem too complicated to me, but I haven't had a better idea yet. I think that most of the hooks we will devise are of one specific type (with respect to locality). Some of them, however, are of "mixed" type, as, e.g., \everypar is in current LaTeX. For these hooks we will probably need three \addto@xxx@hook commands in order to specify how the additional material will be used. However, I'm not very happy with this, for at least two reasons: - implementation is a mess (how do you add something globally when the hook has been changed locally in the current group) - the original programmer of the code loses the control on how the hook is used. After all, the programmer who allowed the use of the hook had specific intentions. I agree with Chris that you need some sort of \subtract@from@hook to give complete flexibility, but I doubt that we need this, and that it will do much good. Rainer