Scenario 1

Actually I can do like this:

In mylistings.sty, I define

\def\tabsize{3}

\RequirePackage{listings}
\lstset{tabsize=\tabsize}


and in mytable.sty, I define

\RequirePackage{mylistings}
\RequirePackage{fancyvrb}
\fvset{tabsize=\tabsize}


Scenario 2

For some reasons, I don't like the scenario 1 above.

Instead I want to do as follows (of course it does not work now)

In mylistings.sty, I define

\RequirePackage{listings}
\lstset{tabsize=3}%example


and in mytable.sty, I define

\RequirePackage{mylistings}
\RequirePackage{fancyvrb}
\fvset{tabsize=listingstabsize}% I don't know the correct syntax. :-)


The question is how to implement the scenario 2?

-

2 Answers

Use the source, Luke. Look in listings.sty and see what happens when the tabsize key is encountered. It sets a macro \lst@tabsize. So this should work.

\makeatletter
\fvset{tabsize=\lst@tabsize}
\makeatother


But internals of a package aren't usually guaranteed to behave the same way in future versions. So there's a chance that this workaround can be broken in future versions. This is why Scenario 1 is the safer way to go.

-
Thanks for answering. I insist on choosing scenario 2 because it is a must. –  xport Jan 14 '11 at 18:33

Here are two (rather late) alternative answers.

You need to give some more intrinsic meaning to the tabsize key: currently, you use it to mean "tab size for listings" and "tab size for fancyvrb, but what you really mean is "tab size for mylistings", which happens to use that dimension in two other contexts. What I'm saying is that you should define your own macro that you call in both places:

\def\mytabsize{3}
% mylistings.sty
\lstset{tabsize = \mytabsize}
% mytable.sty
\fvset{tabsize = \mytabsize}


This is fine unless you expect that tabsize will be set for listings behind the scenes not by you; in that case, I think there is something wrong with your design.

I don't see this as a TeX question at all, but a programming question about how to manage a resource that is shared among different parts of the program. I have given the "static allocation" answer: that the base component of the program dole out resources to the various modules.

The other strategy is the "garbage collection" answer: require that your modules report their usage to a central authority that can keep track of how the resource is used. For that, you have to change the way they request resources. Most likely, you will define your own wrapper macros, having as a side effect that the keys you try to pass to the modules are saved in your own registry as well:

\usepackage{pgfkeys,listings,fancyvrb}
% This defines the registry-setup key
\pgfkeys{
/modules/new module/.style = {
/modules/#1/.is family,
/modules/#1/.unknown/.style = {
/modules/#1/\pgfkeyscurrentname/.initial = ##1
},
},
}

% Here we add two modules to the registry: a necessary first step!
\pgfkeys{
/modules/new module = lst,
/modules/new module = fv,
}

% This will set keys in the corresponding module, and save them in the registry.
\newcommand{\moduleset}[2]{%
\pgfkeys{/modules/#1, #2}%
\csname#1set\endcsname{#2}%
}

% This gets a key from the appropriate module in the registry
\newcommand{\moduleget}[2]{%
\pgfkeysvalueof{/modules/#1/#2}%
}

% This "copies" a key from one module to the other.
\newcommand{\modulecp}[3]{%
\edef\key{\moduleget{#1}{#3}}
\moduleset{#2}{#3 = \key}
}

% mylistings.sty
\moduleset{lst}{tabsize = 3}
% mytable.sty
\modulecp{lst}{fv}{tabsize}


The last two commands are, I think, exactly what you intend to write, so I think this is the better of the two options; it does not rely on internal properties of the packages, either. It is obviously more writing and probably not worth it for just one key, but if you're going to be working with a lot of interrelated packages, this is how you will want to tie them together.

-