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

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

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Mon, 15 Sep 2008 07:12:11 +0100 Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]> Subject: Re: Suggestions sought MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <[log in to unmask]> Content-Type: text/plain; charset=ISO-8859-1 From: Joseph Wright <[log in to unmask]> Parts/Attachments: text/plain (42 lines) Lars Hellström wrote: > Joseph Wright skrev: >> >> I wonder if anyone can make a suggestion on how to solve a problem I'm >> finding rather tricky with my "keys" efforts. The issue is adding code >> to an existing macro. There are a number of scenarios, but I control >> the initial definition, > > In that case, I would *strongly* suggest designing your macro to be > extendable to begin with -- e.g. equip it with a helper macro that acts > as hook. This was my first idea. However, I'm struggling with the implementation, hence the question. > There might in rare cases be a need to pass parameters to this > hook (although storing them in helper macros is typically easier), but > there should never be a need to use delimited arguments. The idea here is that the user provides three things when creating a key: 1) Key name 2) Argument spec. 3) Code Obviously, the key name is used in a csname to make things work, while initially the arg spec and code are used to create the macro. The point is that when adding code, anything from the arg spec. (which could contain any number of parameters) is fair game. So my attempts to create a simple hook: \def:cpx {} {\exp_not:N\prehook \exp_not:posthook} fail when the added code contains #1, #2, ... My current approach at least does not give a TeX error under these circumstances (I've added a custom one to warn of a problem). I'm sure I'm mossing something, but my knowledge of TeX's approach to doubling # characters, etc., is clearly insufficient to find it. -- Joseph Wright