TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using a class classX that accepts class option optionX. Thus, I can write:

\documentclass[optionX]{classX} ...

Now, as I understand it, being a class option, after classX processes this option, optionX is globally defined. All well and good, except that subsequently, for packageY that also accepts optionX (same option name, however semantically unrelated), the two lines

  1. \usepackage{packageY}

  2. \usepackage[optionX]{packageY}

both (erroneously) produce the same effect. All would be well if I could undefine optionX before executing \usepackage{packageY}. (At this point I should also note that, lest anyone be worried about how this might affect classX's subsequent performance, there's no need for the slightest concern -- classX has no need of this option remaining defined after executing its class \ProcessOptions).

So, to the heart of my question, would anyone with better TeX\LaTeX knowledge than I, have any idea how to go? FYI, I've tried several of the usual suspects: \let\optionX\@undefined along with several clueless stabs at \let\<prefix>@optionX\@undefined after scouring source2e.pdf.

(JW: sadly I don't think I can hold back for LaTeX3's promised encapsulated namespaces solution. sigh.)

share|improve this question
To make it clear: you don't want to muck about with the class or package files themselves, but want to put a command (or something) in between the class being loaded and the package being loaded that "switches off" the option. Am I right? – Loop Space Aug 10 '10 at 15:14
Incidentally, although classX has no need of this option, packageZ might need to know that classX was used with that option. So even when an answer is forthcoming, use with caution! – Loop Space Aug 10 '10 at 15:15
up vote 5 down vote accepted

The relevant macro seems to be \@classoptionslist. It's a comma separated list of options passed to the class. So redefining it by stripping out the unwanted options will remove them from the view of later packages.

Test document:





Test package:


\DeclareOption{draft}{\message{^^JGot draft^^J}}
\DeclareOption{wibble}{\message{^^JGot wibble^^J}}


With reference to a comment I left to the actual question, I would make any redefinitions of @classoptionslist a local thing (save the real value before modifying it and restore it once the package is loaded) to avoid problems with other packages that might want to know the full list passed to the class.

For how to actually do the modification, see this question about iterating over a list.

share|improve this answer
The kernel includes the slightly-odd macro \@removeelement for removing elements from comma-lists. It's rather awkward to use, so I'd go for the expl3 \clist_remove_element:Nn instead if this is an option at all. – Joseph Wright Aug 10 '10 at 16:09
Many thanks Andrew for your energy and knowledge with showing me some light, and you too Joseph for the heads-up about \@removeelement and \clist_remove_element:Nn. Greatly appreciated both! – Geoffrey Jones Aug 11 '10 at 6:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.