Use pgfkeys instead of kvoptions

[wget]

Hi there,

Since your package makes high use of Tikz and the latter is using pgfkeys internally, I was wondering why not use that keyvalue implementation instead of kvoptions you are currently using. This would require to remove that package from the requirement list (I checked pfdkeys is actually loaded when compiling your package :( ) and I think pgfkeys is easier to use and more featureful than kvoptions.

What do you think of this? Personally I have learned pgfkeys in a few hours using the pgfkeys manual included in the one from the TIKZ.

In LaTeX, there are several keyvalues implementations. If you want to have a good overview of the available implementation, this (small, only 13 pages) article is a must read.

Regards,

[tweh]

Hi William,

actually I can’t tell why I decided to use kvoptions when implementing menukeys. I also considered switching to pgfkeys but it won’t bring much advantages for the current implementation, so never touch a running system is why I don’t want to switch. I really want to reimplement menukeys completly from scratch with LaTeX3 and without catoptions because the latter brings many disadvantages (but is necessary at the moment …). Unfortunately I don’t have the time for that at the moment :-(

Regarding this I’d close your request, okay?

Regards,
Tobi

[ralessi]

Hi Tobias,

I think that catoptions doesn't work anymore in combination with the hook management mechanism of the latest LaTeX 2020-10-01. (Now published.) As an example, this simple mwe fails to compile:

\documentclass{article}

\usepackage{menukeys}

\begin{document}
hello
\end{document}

The error message is clearly related to catoptions:

ERROR: Extra \endgroup.

--- TeX said ---
\document ->\endgroup 
                      \let \BeforeStartOfDocument \@firstofone \cpt@beforest...

Thanks,

Robert

[tweh]

Yes. I know, but unfortunately I have no spare time to fix this issue at the moment …

[ralessi]

Yes. I know, but unfortunately I have no spare time to fix this issue at the moment …

I understand, thank you for your answer. Meanwhile, I noticed that compiling with `--nonstopmode` gives the expected ouput—I can live with this! Besides, `catoptions` may be the culprit.

[tweh]

Yes. catoptions is a huge problem in the new LaTeX version.

However --nonstopmode doesn’t solves this it just hides the error in a log file ;-)

[ralessi]

Yes. `catoptions` is a huge problem in the new LaTeX version. However `--nonstopmode` doesn’t solves this it just hides the error in a log file ;-)

Yes, I know, I just wanted to recompile part I. of a book which compiled a couple of days ago, and unfortunately this had to be done before Monday.... What has to be done for part II. remains to be seen!

[ralessi]

For what it's worth, commenting out line 4342 of catoptions.sty seems to solve this issue, like so:—

--- /usr/local/texlive/2020/texmf-dist/tex/latex/catoptions/catoptions.sty	2014-08-30 23:38:44.000000000 +0200
+++ catoptions.sty	2020-10-05 08:31:58.703138854 +0200
@@ -4342,7 +4342,7 @@
 \robust@def*\BeforeStartOfDocument{\grightaddtocs\cpt@beforestartdoc}
 \new@def*\cpt@beforestartdoc{}
 \gleftaddtocs\document{%
-  \endgroup
+  %\endgroup
   \let\BeforeStartOfDocument\@firstofone
   \cpt@beforestartdoc
   \let\BeforeStartOfDocument\@notprerr

[tweh]

Good to know. Thanks!

[Skillmon]

@ralessi two things (and I hope this doesn't sound unfriendly; it isn't meant unfriendly, I promise):

1. In case you haven't noticed yet, the catoptions requirement was removed and menukeys should now work with new LaTeX versions (if you find anything not working please open a new issue).

2. Which brings me to the second point: The incompatibility of menukeys with LaTeX versions starting from 2020-10-01 was really a separate issue and shouldn't have been reported in this but in a new thread (which it eventually was on October 8th). Reporting back issues is much appreciated, but managing the list of issues is easier if the issues stay as separate as possible, I hope you understand this. Thank you for reporting back.

[ralessi]

@Skillmon Yes, I confirm the issue is gone, thank you for your help. Regarding your second point, I may have mistakenly inserted a comment here instead of opening a new issue. I did that because @tweh mentioned the many problems he encountered with `catoptions` earlier. And since this package was obvioulsy the culprit of `menukeys` not working anymore, I thought this was a good place to mention one more reason to drop it. I had no idea this might lead to confusion. Sorry.

[Skillmon]

@ralessi no harm done. I just have to ignore the parts in this thread not about pgfkeys vs. kvoptions :)

[ralessi]

@Skillmon Thank you. And by the way (even though off topic), I am a great admirer of `expkv-*` which I used exclusively in `ekdosis`. Switching to `expkv` is planned for my other packages too. So thanks twice!

[tweh]

Since some parts of menukeys have now been ported to LaTeX3 (to drop catoptions) it might be a good idea to use l3keys for options rather than pgf …

[Skillmon]

@tweh Before making a final decision about the used key=value frontend, I'd like to port more things to LaTeX3 (you mentioned in some other thread that you intended to do so). I'd say that then the decision isn't that pressing, but we have to have at least parts of it in pgfkeys for the TikZ based output.

But we could have coding options and parsing options through l3keys and only the output-related things through pgfkeys (since, if we switch to expl3 for internal programming, all the variable names will be expl3 conform, so then using l3keys feels more naturally).

[tweh]

I’m fine with any solution ;-) as a first thought I’d say that using only one frontend would be better but since pgf/TikZ and expl3 in some cases need some special treatment (since expl3 ignores spaces and breaks : for TikZ), it might be a good idea to use pgf for some options an expl3 for others.

[Skillmon]

I'll have to make myself more familiar with the code, and certainly have to port more things to LaTeX3 (if that's an end-goal for upcoming releases) before I can make an educated decision here. I hope to find a bit of time this weekend to start tackling this.

[tweh]

I wanted to port the whole package to L3 for a long time but didn’t had the time. However I was thinking about a more or less complete reimplementation with a new frontend for styles etc., since the current interface isn’t pretty well …