# Define a no-op color name which is always the current color

Using xcolor I like to define a named color which actually does not change the current color. So \textcolor{mycolor}{text} should print text in the currently active color. In other words: I'm looking for a way to define a no-op color.

I'm not talking about the special color name '.', which refers to the currently used color. Using \colorlet{mycolor}{.} will simply define mycolor to the color used at that moment. However, having a names alias of '.' would do the trick.

About the background: In my ydoc bundle which I used for the package manuals of mine I use predefined styles for certain repeatable used items. For example package names are formatted using \pkg{name} which uses \pkgstyle internally to format the name. This style macro uses, beside other things, the color pkg to color the package names. By default I do not want to have the package names colored in a different way, so the pkg is defined to be black. This is fine for normal, black text, but if \pkg is used inside a colored text the package names are still black. Some goes for all other macros like this which all use this generic set of macros.

My question is now if it is possible to define a named color with xcolor which actually does not change the current color. This would allow to disable the use of a special color without redefining the style macro to not include \textcolor. It would be nice if this special no-op color could be copied using \colorlet to other color names as well.

A MWE would be the following. The word 'test' should always have the same color as 'before' and 'after'. The definition of \myformat should not be changed, only the definition of mycolor.

\documentclass{article}
\usepackage{xcolor}
\colorlet{mycolor}{.}% Wanted: Always be the currently active color
\newcommand{\myformat}[1]{\textcolor{mycolor}{\ttfamily #1}}
\begin{document}

before \myformat{test} after

\color{blue}
before \myformat{test} after

\color{red}
before \myformat{test} after

\end{document}

-
I don't understand. Why special color '.' cannot be used? –  Leo Liu Nov 25 '11 at 17:37
Although this does not answer the general question, in this specific case one could redefine \textcolor to gobble its colour argument #1 and only typeset the text part #2. And, this redefinition could be done within \myformat to localize it. –  Werner Nov 25 '11 at 17:38
And I'm sure you know that you can use \colorlet{mycolor}{.} in the definition of \myformat. So I still cannot understand your purpose. Is there any special reason make ydoc prevent using such techniques? –  Leo Liu Nov 25 '11 at 17:43
@LeoLiu: I want that by default no color is used, i.e. the current color is not changed, but the user should be able to redefine the pkg color to a specific color. So basically, if no color is defined I don't want a \textcolor to be used (or at least it should not do anything), but if a color it defined it should be used. \colorlet{mycolor}{.} would simply define mycolor to be the current color, like black, but if the color changes . would then be the new color, but mycolor would still be black. –  Martin Scharrer Nov 25 '11 at 17:51
@Werner: I don't want to redefine the formatting macro, but rather able to disable the color change by redefining the named color. –  Martin Scharrer Nov 25 '11 at 17:55

I think you know this:

\documentclass{article}
% Users cannot touch these
% But users can change pkgcolor
\usepackage{xcolor}
\newcommand\pkg[1]{%
\textcolor{\ifcsname\string\color@pkgcolor\endcsname pkgcolor\else .\fi}{#1}}

\begin{document}

The package \pkg{ydoc} is good.

{\color{red}
The package \pkg{ydoc} is good.}

\colorlet{pkgcolor}{blue}

The package \pkg{ydoc} is good.

{\color{red}
The package \pkg{ydoc} is good.}
\end{document}


Thanks egerg for \csname\string\color@xyz\endcsname.

But I prefer a key-value interface:

\documentclass{article}
% Users cannot touch these
% But users can use \ydocset to change pkgcolor key
\usepackage{xcolor}
\usepackage{keyval}
\makeatletter
\define@key{ydoc}{pkgcolor}{%
\def\pkg@color{#1}}
\newcommand\ydocset[1]{\setkeys{ydoc}{#1}}
\ydocset{pkgcolor=.}
\newcommand\pkg[1]{%
\textcolor{\pkg@color}{#1}}
\makeatother

\begin{document}

The package \pkg{ydoc} is good.

{\color{red}
The package \pkg{ydoc} is good.}

\ydocset{pkgcolor=blue}

The package \pkg{ydoc} is good.

{\color{red}
The package \pkg{ydoc} is good.}
\end{document}

-

When one says \definecolor{xyz}{...}{...}, xcolor defines the macro

\\color@xyz


that is, more precisely,

\csname\string\color@xyz\endcsname


In particular \csname\string\color@.\endcsname is a macro expanding to the current color; so

\expandafter\let\csname\string\color@mycolor\expandafter\endcsname
\csname\string\color@.\endcsname


would seem a way to go. However, as you observe, this is like \colorlet{mycolor}{.}.

A way out seems to be to add the definition of the requested pseudocolor to \XC@display:

\makeatletter
\preto\XC@display{\XC@bcolor\XC@let@cN{\string\color@mycolor}\XC@current@color}
\makeatother
\colorlet{mycolor}{.} % initialization


Not very satisfying, I guess.

-
No, this doesn't work. It basically is the same as \colorlet{mycolor}{.}, i.e. it just copies the current color. The problem is that . is redefined every time the color is changed. I also tried \expandafter\def\csname\string\color@mycolor\expandafter\endcsname\expandafter{‌​\csname\string\color@.\endcsname} to always use the current definition of ., but this causes warnings by xcolor that the color definition is incompatible, because it expands the macro once to check its definition. –  Martin Scharrer Nov 25 '11 at 18:02
It works. Anyway I feel painful to hack into xcolor.sty. And it may be unsafe. –  Leo Liu Nov 25 '11 at 19:00
@LeoLiu I'm not satisfied, too. Probably the best way is to make a feature request. –  egreg Nov 25 '11 at 20:16