LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
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]>
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 {<key>} <arg spec.> {\exp_not:N\prehook <code> \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