6

As shown in Issues with leipzig and glossaries used together, there is a problem when using the package leipzig with the glossaries package since the leipzig package relies on deprecated commands from glossaries.

The answer to the question solves the issue, but the answer suggests modifying the .sty file, which I would rather not do.

I have tried to patch the \SetLeipzigDisplayStyle command, but I have not been successful. According to egreg's answer to Please tutor the usage of patchcmd and xpatch, one should use xpatch when trying to patch a command with an optional argument. \SetLeipzigDisplayStyle is such a command, but trying to patch it with \xpatchcmd does not work for me. How can I fix the issue without resorting to (copying and) modifying the .sty file?

MWE

% !TEX TS-program = arara
% arara: pdflatex
% arara: makeglossaries
% arara: pdflatex
% arara: pdflatex

\documentclass{article}

\usepackage{expex}

\usepackage[nomain,nostyles]{glossaries}
\usepackage{glossary-inline}
\usepackage{leipzig}
\makeglossaries

\usepackage{xpatch}
\xpatchcmd{\SetLeipzigDisplayStyle}{%
    \defglsdisplay[#1]{\leipzigfont{##1}##4}%
    \defglsdisplayfirst[#1]{\firstleipzigfont{##1}##4}%
}{%
    \renewcommand*{\glstextformat}[1]{\leipzigfont{#1}}%
}{}{}

\begin{document}

\ex
\begingl
\gla mulle//
\glb \First\Sg:\Dat{}//
\endgl
\xe

go.\Pst{}

\printglossary[style=inline,type=\leipzigtype]

\end{document}

You can see that it still produces the problem noted in Issues with leipzig and glossaries used together.

enter image description here

Community
  • 1
Adam Liter
  • 12,567
  • @GonzaloMedina I'm not getting that error I don't think? I just tried searching the .log file for that error and nothing comes up. – Adam Liter Mar 02 '15 at 03:27
  • @AdamLiter: Your patch merely seems to attempt to redefine \SetLeipzigDisplayStyle. Why not just redefine it then rather than patching it? Also, do you want to redefine it to ..##1.. rather than ..#1..? – Werner Mar 02 '15 at 04:53
  • @Werner That's a good point ... and probably the more sensible thing to do ... :) I can't seem to get that to work, either, though. \renewcommand*{\SetLeipzigDisplayStyle}[1]{\renewcommand*{\glstextformat}[1]{\leipzigfont{#1}}} doesn't work, which is why I ended up trying to patch it. I'm sort of curious why patching doesn't seem to work, but also, at this point, any solution would be fine. As for #1 vs. ##1, I'm honestly not sure what the difference is. Does this have something to do with glossaries? I was just trying to change it to the accepted solution in the linked question. – Adam Liter Mar 02 '15 at 05:07
  • @AdamLiter You're not trying a patch, as the text you want to substitute is the whole replacement text of the macro. So, if this patch were successful, it wouldn't be different from doing \renewcommand. – egreg Mar 02 '15 at 07:39
  • @AdamLiter Sorry about that. Most probably some leftover auxiliary file I had on my machine. – Gonzalo Medina Mar 02 '15 at 13:58
  • leipzig 2.0 is now available on CTAN (2017-06-16), and it fixes this issue (among others). However, if you are still using leipzig 1.0/1.1, then you can hack this by using \glsunsetall in your preamble. The reason you see PSTpastpst is a combination of bugs, but mostly because leipzig thinks you want the full abbreviation printed, as if on first use. (It's printing the short form correctly in smallcaps, then printing the long and short forms without smallcaps). Using \glsunsetall unsets the first use flag that is used by glossaries. – Natalie Weber Jun 17 '17 at 16:42

1 Answers1

3

I don't think it's possible to do patches with etoolbox when the search text contains ## (note that xpatch is built upon etoolbox).

Also, the requested patch is just equivalent to

\renewcommand*{\SetLeipzigDisplayStyle}[1]{%
  \renewcommand*{\glstextformat}[1]{\leipzigfont{#1}}%
}

so it's not clear why you're looking for a patch.

By the way, xpatch is not strictly needed for the particular purpose, as \SetLeipzigDisplayStyle is not defined with an optional argument.

If you insist in doing a patch,

\usepackage{regexpatch}
\xpatchcmd{\SetLeipzigDisplayStyle}
  {\defglsdisplay[#1]{\leipzigfont{##1}##4}%
   \defglsdisplayfirst[#1]{\firstleipzigfont{##1}##4}}
  {\renewcommand*{\glstextformat}[1]{\leipzigfont{#1}}}
  {}{}

does the job.

But if I subsequently add

\newcommand*{\test}[1]{\renewcommand*{\glstextformat}[1]{\leipzigfont{#1}}}

\ifx\test\SetLeipzigDisplayStyle\message{EQUAL}\fi

I find EQUAL in the log file, so patching is indeed not necessary and a redefinition should be used.

Probably

egreg
  • 1,121,712
  • Whether this will do the job connected with the interaction between leipzig and glossaries is beyond the scope of the question. The proposed patch doesn't seem to solve the problem to begin with. – egreg Mar 02 '15 at 08:39
  • Shouldn't it be \renewcommand*{\SetLeipzigDisplayStyle}[1]{%, not \renewcommand*{\SetLeipzigDisplayStyle}{%? But anyway, you're right about the patch not seeming to solve the problem. What I really don't understand though, is why patching/\renewcommandinging \SetLipzigDisplayStyle in the preamable doesn't solve the problem, but copying and modifying the definition in the .sty file does. Shouldn't they have the same behavior? I guess that's a new question, but I'm really puzzled. – Adam Liter Mar 02 '15 at 15:55
  • Using your test in a .tex file that is using a modified version of leipzig also returns EQUAL in the .log file, but the behavior is different. I'm so confused. – Adam Liter Mar 02 '15 at 16:01
  • @AdamLiter I fixed the source; but I don't find differences between the behaviors with \regexpatchcmd and \renewcommand – egreg Mar 02 '15 at 16:31
  • I also don't see any differences in behavior with \regexpatchcmd and \renewcommand, either, but if you copy and modify the .sty file itself so that \SetLeipsigDisplayStyle is defined as \renewcommand*{\glstextformat}[1]{\leipzigfont{#1}}% inside the .sty file then the undesired behavior goes away, even though your conditional test returns EQUAL in the .log file in all three cases. – Adam Liter Mar 02 '15 at 16:37
  • Do you have any idea why there would be such differences in behavior? I thought patching or renewing a command was as good as changing it in the .sty file. I intend to accept your answer at some point, but I was curious if you happened to have any insight. Or should I just ask a new question? And for what it's worth, I agree that the accepted answer to the other question probably isn't really the right solution. According to the glossaries manual, \defglsentryfmt replaced both \defglsdisplay and \defglsdisplayfirst. But this is the first time I've ever looked at glossaries. – Adam Liter Mar 02 '15 at 19:12