Changed \newcommand for \providecommand to avoid problems with latex-…

[susuhahnml]

…class-ceurart

[tortinator]

Hallo @susuhahnml , I guess it's a reasonable fix but perhaps its time do redesign our macros rather than patching them.
Eg. we could use \providecommand in general ... but I have to refresh my memories on the differences.
And we should check with @rkaminsk , what he thinks.

[rkaminsk]

It might actually be better to see that there is a redefinition. Because the name clash might be due to completely different commands. next is also a pretty generic name. Maybe temporalnext or similar might be better to avoid clashes. I also tend to start commands with an upper case letter. This avoids clashes with a lot of packages.

One can also manually workaround such issues with \let, \undef, \def, and co.

Edit: Here some reference: https://tex.stackexchange.com/questions/18541/two-conflicting-packages-in-one-document-doable.

[tortinator]

After reading the stackexchange, I would prefer name clashes and fixes rather than an implicit solution.

However, adding \let\next\relax after \newcommand{\next}{...} throws an error though I hoped this would simply undo the definition.
Any idea?

BTW, this is not the only clash, viz \C is next 😞

[rkaminsk]

However, adding \let\next\relax after \newcommand{\next}{...} throws an error though I hoped this would simply undo the definition.

Have you tried \let\next\undefined?

EDIT: The etoolbox package also has an \undef command.

[tortinator]

However, adding \let\next\relax after \newcommand{\next}{...} throws an error though I hoped this would simply undo the definition.

Have you tried \let\next\undefined?

Yes, this was even my first choice 😞

EDIT: The etoolbox package also has an \undef command.

Yeah, but this would buy me another package

[tortinator]

After all, it might be easier to offer all these commands via \providecommand...

[rkaminsk]

Just be aware that you won't be able to use them if you use the "wrong" packages. Better rename the commands instead of using \providecomand.

[tortinator]

Just be aware that you won't be able to use them if you use the "wrong" packages.

I guess, we had to look at our macros as convenience packages and also load them last

[rkaminsk]

Just be aware that you won't be able to use them if you use the "wrong" packages.

I guess, we had to look at our macros as convenience packages and also load them last

I would not do it like this. But it's your project... 😄

[rkaminsk]

We could use the prefix \ASP<command> to avoid such things.

[tortinator]

Just be aware that you won't be able to use them if you use the "wrong" packages. Better rename the commands instead of using \providecomand.

Well I just checked we offer 233 macros, and renaming them all would need a unique prefix like potassco or whatever
Hnce I'd sitll go for \providecommand as we do in comments.sty already

[rkaminsk]

Just be aware that you won't be able to use them if you use the "wrong" packages. Better rename the commands instead of using \providecomand.

Well I just checked we offer 233 macros, and renaming them all would need a unique prefix like potassco or whatever
Hnce I'd sitll go for \providecommand as we do in comments.sty already

I would do exactly this. Since you are using submodules, you can just do it. It won't break any existing projects.

[susuhahnml]

I think the prefix would have been good at the start, but right now ` \providecomand` would be a fix whitout breaking existing projects. I also agree that it can cause some hidden errors due to a redefinition we won’t be aware of… But I guess we cant have it all. Since the clash was with `\next` it took me longer to find it because I was blaming the tikz library as well, but when the class changed it worked. I guess tikz also uses something like` \providecomand` to avoid this issue with this common command and that is why we needed to load our `dtel` as-macro before since it currently uses `\newcomand`.

…

On 11. Jul 2021, at 03:33, Roland Kaminski ***@***.***> wrote:  Just be aware that you won't be able to use them if you use the "wrong" packages. Better rename the commands instead of using \providecomand. Well I just checked we offer 233 macros, and renaming them all would need a unique prefix like potassco or whatever Hnce I'd sitll go for \providecommand as we do in comments.sty already I would do exactly this. Since you are using submodules, you can just do it. It won't break any existing projects. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[rkaminsk]

Here is one workaround. I also tried to patch the ceurart but my TeX knowledge is a bit lacking to do this kind of stuff.

\documentclass{ceurart}

\let\oldnext\next
\let\next\undefined
\include{dtel}
\let\ASPnext\next
\let\next\oldnext

\begin{document}
\begin{itemize}
\item \(\ASPnext\) test1
\item test2
\end{itemize}
\end{document}

[susuhahnml]

This fixes the clash, with \input insted of \include tho. :) But overall is probably a good option while we discuss how to tackle this problem in general.

[rkaminsk]

This fixes the clash, with \input insted of \include tho. :) But overall is probably a good option while we discuss how to tackle this problem in general.

Sorry, I always mix this up when writing things from scratch. It has to be \input, \include is invalid in the preamble.

PS: Since the macros only contain commands, they could actually become a style.