# Indexing hangs with pgfkeys

The following code hangs pdflatex with no errors:

\documentclass{article}

\usepackage{tikz}
\usepackage{makeidx}

\newcommand{\propertydef}[2]{\pgfkeys{/assume/#1/.code=#2} \pgfkeys{/assume/#1/.value forbidden}}
\newcommand{\property}[1]{\pgfkeys{/assume/#1}}

\propertydef{Name}{some concept}

\newcommand{\defi}[1]{\index{#1}\emph{#1}}

\makeindex

\begin{document}
Works: \index{\property{Name}}\emph{\property{Name}}.
Does not work: \defi{\property{Name}}.
\end{document}


It can be made to work either by commenting out the "does not work" line, or by removing \makeindex. What is the problem, and how can I make the "does not work" line to work?

The idea is to use the \defi macro to define a new term, which automatically adds the term into the index, as well as prints the term with emphasis. The twist is that the name of the term comes from association to a label defined with pgfkeys.

• I've got the impression that this should be done with glossaries rather – user31729 Jul 3 '16 at 10:20
• I've deleted my answer -- the \DeclareRobustCommand leads to wrong sorting! – user31729 Jul 3 '16 at 11:39

EDIT

The problem is not \index but \pgfkeys. If you try to use \edef\mycmd{\pgfkeys{/assume/Name}, pdflatex also hangs. Therefore, the command must be protected to use it in \index, but then it will be sorted as \property instead of as some item. To get the correct sorting you must expand it first but that gives the problems, so there is no way out with this approach.

Since you are using pgfkeys only to create an internal TeX command through \pgfkeysdef and not to use keys, it might be better to do it directly to get the desired result, disregarding pgfkeys. The way to create commands with user supplied info is through \csname. To get the correct sorting, the argument must be first expanded in \index, which can be done now.

In the following code I have added a \index{some item} to show that the sorting in the index is correct. The form \index{\property{Name}} works, but gives the wrong sorting as I have commented earlier. I have also provided pagebreaks to show that the indexing is ok now, although it can be seen better in the .idx file. This are the images of both:

And this is the full code:

\documentclass{article}

\usepackage{makeidx}\makeindex

\newcommand{\propertydef}[2]{\expandafter\def\csname assume#1\endcsname{#2}}
\newcommand{\property}[1]{\csname assume#1\endcsname}
\newcommand{\defi}[1]{\index{#1}\emph{#1}}

\propertydef{Name}{some item}

\begin{document}

A different approach: use of \verb|\csname|.
\index{some item}

\pagebreak

Works with wrong sorting:
\index{\property{Name}}\emph{\property{Name}}.

\pagebreak

Works with correct sorting:
\expandafter\index\expandafter{\property{Name}}\emph{\property{Name}}.

\pagebreak

This works with correct sorting also:
\defi{\property{Name}}.

Same as:
\defi{some item}.

\printindex

\end{document}


OLD SECTION

You have to \protect fragile commands in \index:

This works: \defi{\protect\property{Name}}.


It will, however, give you two entries if used along with \index{\property{Name}}

• The resulting index seems not to be in correct order. I think this is the same problem as with Christian Hupfer's (now deleted) answer using DeclareRobustCommand. – kaba Jul 8 '16 at 14:30
• @Kaba It is sorted in both cases as \property {Name}, which is what has been entered. Only in the second one, a space has been added by the \protect. The macros are expanded at the end, not for sorting. – Raoul Kessels Jul 8 '16 at 14:54