Compilation fails in TeXLive 2021; possible fix

bcw commented 3 years ago

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:
- Check that you are using the latest version of kaobook.
- Check that your issue isn't already filed: https://github.com/fmarotta/kaobook/issues

Description

I am trying out the latest version of TeXLive (it came out on April 1, 2021; and no, it's not an April Fools Joke), but to compile any document (including unedited MWE below) with current kaobook now fails. The error is amssymb.sty:261: LaTeX Error: Command `\Bbbk' already defined., and running latexdef -c kaohandt -s Bbbk tells me

% newpxmath.sty, line 2159:
\DeclareRobustCommand{\Bbbk}{\mathbb{k}}

\Bbbk:
Compile error: LaTeX Error: Command `\Bbbk' already defined.

so apparently the problem is newpxmath now defines \Bbbk before amssymb gets the chance to do so. After some struggling (and learning how to read both LaTeX log files and the source), I've narrowed down the problem to lines 1037 and 1041 in kao.sty. Just like the comment in the previous conditional case for LuaTeX indicates, it seems amssymb now must be loaded first, due to amssymb.sty using ~\newcommand~ (edit: apparently it actually uses \DeclareMathSymbol, but the effect seems similar). I've tried moving the latter line first, and that fixes the issue for me. But is anyone else getting the same result, or are there any other problems with this?

Minimal Working Example

\documentclass{kaobook}
\usepackage[english]{babel}
\usepackage{blindtext}
\usepackage{kaobiblio}
\usepackage{kaotheorems}
\usepackage{kaorefs}

\begin{document}

\title{Bug Report}
\author{Author}
\date{\today}

\frontmatter

\KOMAoptions{twoside=semi}
\maketitle
\KOMAoptions{twoside=false}

\mainmatter
\setchapterstyle{kao}

\chapter{First Chapter}
\blindtext

\end{document}

Expected behavior: Document compiles.

Actual behavior: Error shown above.

Additional Information

If you'd like, let me know and I'll try to send a pull request, but I've never done that so far, and this change seems trivial enough that it might be faster and easier for both of us if you just do it. In any case, thank you for your great software, and the learning opportunity!

AlexanderZeilmann commented 3 years ago

Thank you for your nice bug report! Your proposed change also fixes the problem for me.

I think it is a good bug to try out creating pull requests, especially because the change is trivial. So it would be great if you could send a pull request. Please let me know if I can help you with it 😃

bcw commented 3 years ago

Thank you @AlexanderZeilmann for the encouragement, and trying the change I suggested. I had already forked the repo yesterday and deleted my original copy (planning on cloning the forked version to make the pull request - I bet there's a better way to change to a forked version, huh?), but there was some kind of network issue with GitHub and the cloning was unbearably slow, so I interrupted it and gave up until just a few hours ago.

Anyway, I just finished cloning it, made the change again, pushed it to my fork, and finally created pull request #136 . If you don't mind taking a look at it, I'd appreciate any comments (either here or there) on anything I might have done better. Like, I noticed you made a change and pull request that didn't use a branch - I didn't either, though maybe I should have? I'm not exactly clear about when it's best to do so, and when not. Thanks for the offer of help too, btw.

AlexanderZeilmann commented 3 years ago

I bet there's a better way to change to a forked version, huh?

When I create a new pull request, I normally delete my old fork, fork the repository again and make the pull request. This is a bit annoying, but probably the easiest way.

Sometimes it is necessary to update the fork after making a pull request. This is described here: https://stackoverflow.com/questions/7244321/how-do-i-update-or-sync-a-forked-repository-on-github#7244456

Regarding branches: I think for bigger projects (with many more contributors and a higher commit frequency) or larger code restructurings it is vital to work with branches. For small projects like kaobook and little changes like this, they are just too much overhead.

bcw commented 3 years ago

@AlexanderZeilmann OK, thanks. I did notice that the PR page says I would add more commits to it (if I needed to, which it looks like I don't in this case) by pushing to the master branch on my fork, so I can see how having a separate branch for the PR might allow me to fix any remaining problems without messing up the "main" version I'm working on (even if it was just a little change). I noticed that @tbm created a new branch just to fix a single typo, for example, and I can imagine that might have helped if there were other things he wanted to work on but discovered additional typos he missed.

And if we had used separate branches, would we still need to delete the old fork? Or just merge the upstream changes into our local masters, push back to github, and create a new branch for the new PR? (That's what Tim Keating's comment with 102 upvotes on the answer you just linked seems to indicate. I also just bookmarked this link in his following comment, which seems to address some of exactly what we're talking about. Nevertheless, I'm genuinely asking here, since using git's more collaborative development features is new territory for me and I don't really know who's right.)

As for it being "too much overhead", I think I've read somewhere in the Pro Git book on Git's official website that one of its main design goals was to make branches much more lightweight (on the filesystem) than other version control systems. I think some people even advise making and merging branches religiously for every single feature they implement or bug they fix (I usually don't go that far, though I may eventually). Or do you just mean that it takes executing too many git commands?

If the latter, I'm a bit spoiled in that regard since I use magit inside GNU Emacs, which makes a lot of common and not-so-common git tasks, including making and switching between branches (and commits), as easy as a couple of keystrokes, once you get both programs installed and set up properly (and learn how to use them). I still know a bit about how to do it the "hard way", using the commandline, but it's not something I usually bother with any more. I don't know what OS you use - I currently use Debian GNU/Linux - but Emacs has community-supported versions for both MacOS and Windows these days.

Anyway, thanks for your help and suggestions, I'm still going to think carefully about (and refer back later) to what you've said here - and I saw your comment in the PR page too, thanks - though it may be a while before I do much more with this (I'll keep an eye on the PR tho). I hope this gets accepted, and maybe it'll help some people learning the same stuff? I should probably also mention that I took a look through GitHub's Help pages before I did any of this, though it wasn't really clear to me what they were recommending about branches on forked repos - at least on open source projects - though I guess that's to be expected since it's now a Microsoft-owned business. 😜

fmarotta / kaobook