Option clash for packages hyperref and enumitem

[homocomputeris]

Hei!

I'd like to use skeldoc and highlight links in the PDF.
However, this code does not compile because of Option clash for package hyperref.:

\documentclass[]{article}

\author{Name}
\title{Title}
\usepackage{skeldoc}
\usepackage[colorlinks]{hyperref}
\begin{document}
Text.
\end{document}

While this one does compile:

\documentclass[]{article}

\author{Name}
\title{Title}
\usepackage{skeldoc}
\usepackage{hyperref}
\begin{document}
Text.
\end{document}

[mlhetland]

Hi!

Thanks for the MWEs!-)

Right, this is because skeldoc already uses hyperref, and supplies its own options to it. When you then use hyperref afterward, using other options (in this case colorlinks), you get the conflict error.

Instead, you could use \hypersetup to provide hyperref with other options, possibly overriding those used by skeldoc. That is, you could do something like:

\documentclass[]{article}

\author{Name}
\title{Title}
\usepackage{skeldoc}
\usepackage{hyperref} % Not really needed
\hypersetup{colorlinks}
\begin{document}
Text.
\end{document}

Note that while you don't need \usepackage{hyperref} (because it's already used by skeldoc), it might be useful to keep it, as you'll probably be removing hte \usepackage{skeldoc} command once the document is finished :-)

Just let me know if this ends up not doing what you want. I'll leave the issue open for now – I might want to address this either in the code some way, or perhaps in the docs.

[mlhetland]

I was a bit quick, there xD I remember now that there actually is a mechanism for overriding the options used by skeldoc; it's the hypersetup key. The default is hidelinks, i.e.,

\usepackage{skeldoc}

is equivalent to:

\usepackage[hypersetup=hidelinks]{skeldoc}

So you can just use this instead:

\usepackage[hypersetup=colorlinks]{skeldoc}

I guess it might be useful to have an option to turn off the importing of hyperref in skeldoc altogether, so you could use \usepackage[colorlinks]{hyperref} without getting any trouble (so that your code, apart from the skeldoc import, can remain as-is once skeldoc is gone – which it also can with the \hypersetup command, of course).

So, yeah, there is already support for configuring the use of hyperref. I guess that fixes the problem, but I'll still leave the issue open – because I'd really like to make it possible to just use options directly with \usepackage[…]{hyperref}, like you did. Either by switching off the import in skeldoc (which should be possible for other packages imported by skeldoc, too, for similar reasons) or perhaps in some other way. I'll look into it. But at least your particular problem should be solved, I hope?

[homocomputeris]

Thanks!
Is it possible to pass several options to skeldoc? pdfusetitle cannot be passed to \hypersetup. Can I use \usepackage[hypersetup=hidelinks,pdfusetitle]{skeldoc}?

By the way, I believe that there other packages that load hyperref, for example, glossaries(-extra). But they won't cause clash in this MWE. How do they avoid it?

[mlhetland]

OK, I was clearly not entirely awake when I answered you yesterday xD The skeldoc package doesn't take any options to \usepackage (partly because of some expansion issues that occur there that I'd rather not deal with). Instead, use \skelset to supply these options. When it comes to the hypersetup, that is stored and then executed automatically in a \hypersetup command at \begin{document}.

You can indeed pass multiple arguments to an option – just enclose them in braces, like hypersetup={foo,bar}. Whatever is found in the braces will simply replace the default used by \skeldoc. This will just be passed to \hypersetup, however. I guess (maybe) it ought to be used when importing hyperref, since there are options like pdfusetitle that only work there.

As for how glossaries and glossaries-extra do it: Without having studied the code in detail, it seems they avoid the issue by simply not importing hyperref. They use it (if it's available), but you have to do the importing. Or so it seems. That might be a sensible solution for skeldoc too, I guess; i.e., if you import hyperref, the numbers be come links (for example).

To solve your problem, specifically, I guess you could use pdftitle and pdfauthor instead (i.e., with \@title and \@author as arguments).

A better solution is probably to use something like the following:

\PassOptionsToPackage{colorlinks,pdfusetitle}{hyperref}
\usepackage{skeldoc}
\usepackage{hyperref} % optional

The last \usepackage is just so that if you comment out/delete the skeldoc import (once you're done filling out your document), you'll still get hyperref, with the options you passed to it.

This isn't entirely functional, however. Ideally, you should also be able to add \skelset{hypersetup=} to empty out the setup there, but currently skeldoc will happily call \hypersetup with an empty token list, and it seems \hypersetup doesn't like that (even though \hypersetup{} works just fine; I think the empty token list is interpreted as a key name – I guess that's essentially a bug in how I call \hypersetup, then).

You can always just add \skelset{hypersetup=colorlinks} or something, just to put something in there, and it should work. If you have that in \PassOptionsToPackage as well, you'll get a warning. You could always delete that option from there, but then of course you no longer get the right setup if you just delete the skeldoc stuff (which I'm just assuming is a natural thing to do once it's no longer needed).

So … I think this is a functioning workaround, though a better solution would be, well … better :-)

\documentclass{article}

\author{Name}
\title{Title}
\PassOptionsToPackage{pdfusetitle}{hyperref}
\usepackage{skeldoc}
\skelset{hypersetup=colorlinks}
\begin{document}
Text.
\end{document}

[wenlzhang]

I tried to insert Obsidian URIs with something like the following:
\skelpar{Refer to \href{Link}{Text} for more details.}

Using obsidian URI - Obsidian Help

However, I always got the following error messages:
File ended while scanning use of \skelpar . ...

If I replace \href{Link}{Text} with \url{Link} to only insert links, it does not work either, and it gives the same error.

So … I think this is a functioning workaround, though a better solution would be, well … better :-)

I tried to use this workaround, but it did not resolve the issue.

[mlhetland]

Hm, indeed. The workaround is primarily for sending options to hyperref. (I guess ideally, skeldoc should not mess with the hyperref options, and only change formatting locally, if possible. I guess I could look at that, eventually.)

I don't think that's directly connected to your problem, though. Here's a simple example document that should do what I think you're describing – and it works just fine on my end:

\documentclass{article}
\usepackage{skeldoc}

\begin{document}

\skelpar{Refer to \href{Link}{Text} for more details.}

\printskelnotes
\end{document}

Does this work for you? Could you perhaps. see if you could update the example to more closely mirror your document, so that you get the error you describe?

[wenlzhang]

Thanks for the clarification.

Does this work for you? Could you perhaps. see if you could update the example to more closely mirror your document, so that you get the error you describe?

Yes, the provided example document works for me as well.

If \skelpar{Refer to \href{Link}{Text} for more details.} is replaced by using an Obsidian URI, e.g. the following, then it gives the error as described above.

\skelpar{Refer to \href{obsidian://open?vault=my%20vault&file=my%20note.md}{Text} for more details.}

[mlhetland]

I see. The problem here is not related to skeldoc, but is caused by the fact that % is a comment character in TeX/LaTeX, so it's functionally equivalent to writing the following:

\skelpar{Refer to \href{obsidian://open?vault=my%

Because this does not include the two ending braces (for \href and \skelpar), you get your error.

This should be fixed by simply escaping the percentages, writing \% rather than % in your URL.

[wenlzhang]

This resolves the issue. Thanks for the help!

[mlhetland]

The same issue occurs with enumitem (and possibly other packages; I haven't checked). I guess a more general solution is needed, here.