16

I just ran into a load-order conflict due to identical cs names and realized that this is the source of similar problems in the past that I've seen. Thinking about it, I can't imagine what other conflicts there could be, so that shows you how much I know. Anyway, now that I'm writing a package or two I need to understand this.

-------------- After Reading Answers ------------------

Well, I feel like my question was answered fully and to my complete satisfaction. Unfortunately, all of the answers contributed to my current understanding and feeling of satisfaction, and I don't feel that it would be fair to select only one as the 'correct' answer. So, until I hear a way out of this conundrum, I want to symbolically check all of the answers and thank everyone who took the time to answer me.

Thank you.

|improve this question
13

The most common problem, as you correctly said is duplicating macro names. This you can easily check with a commands like \@ifundefined or ifdefinable and other similar commands. The problem is similar to problems experienced in normal programming with globals. Generally globals are bad and with TeX programming they are used all over the place.

You can mitigate problems by namespacing your macros. For example you can use @bev@pagewidth, comfortably as it is unlikely that anyone has used this in another macro! This makes your macro names rather long which makes people from a Java background happy, but people from a `C' background get very unhappy.

LaTeX3 provides all sorts of methods and rules and regulations to namespace and create commands. It has a syntax as unique as that of TeX's own and although rather off putting at first - you can really be up and going over a weekend. The Team has put a tremendous effort in bringing it so far that you can use it right away - saving you lots of hours of work.

If you have to override any existing commands, be a gentleman save them first in a variable and restore them back at the end of your package's code.

Any changes to dimensions, glues, counters and the like are better defined locally.

The last item of concern is key value pairs using keyval here again if you use it you need to be careful with allocation of names. Also decide with which packages you want to interact so that you can avoid conflicts.

|improve this answer
  • A good example of the namespacing thing is that fancyvrb doesn't redefine verbatim but instead provides Verbatim. Neat. – Seamus Nov 25 '10 at 17:09
  • 1
    Good point. As a word of caution, because I've been bitten by this more than I cared to be, is to be extra careful that \@ifundefined will \relax what is being tested, so eTeX' \ifcsname is the better choice, but will yield false positives because somebody else might have already \relax'ed what you're checking for. (Since hardly anything still uses non-eTeX engines, I tend to consider usage of \@ifundefined outside of a group a bug.) – Ulrich Schwarz Nov 25 '10 at 18:06
  • Thanks for the advice. I'm a big believer in, and a consistent user of, namespacing my internal macros and variables, not so much on external. Pondering this, it would be nice if TUG had a searchable database of all the external macros defined in the whole texlive distribution. It wouldn't be hard to create, and for people writing packages it would be very useful. – bev Nov 25 '10 at 22:58
11

Packages that try to take control of what happens at Tex events like \shipout can conflict in nasty ways. Latex doesn't really have an orderly way to resolve these conflicts, so package writers need to work with each other.

Example: {hyperref} has had a number of conflicts with packages for this reason, see http://tug.org/pipermail/texhax/2010-June/015250.html

These examples aren't naming conflicts, because changing choice of names can't fix them. You need to change what you are doing.

Some possible other ways of getting package conflicts, that I haven't seen realised:

  1. Messing about with catcodes could cause conflicts in principle. You'd think that packages like {inputenc} that do hairy things with catcodes would be at risk here, but I don't know of any.
  2. Packages that run Postscript/PDF code through \special commands, like PGF does. Lots of room for conflict here, but I don't know of any actual package conflicts in practice.
|improve this answer
  • Interesting. I actually stopped using hyperref a few years ago because I got tired of all the problems it created. I read the link you cite and didn't understand what they were talking about (-> "trapping the anchors" ?), so this is the sort of info I was looking for. I'll open 'geometry' and see whether I can figure it out. Gracias. – bev Nov 25 '10 at 23:09
  • @bev: Sorry, never replied to your comment - I can fix that now. I don't think Ulrike's "trapping the anchors" is standard terminology: what she means here is that there is a race condition between to sections of Latex code about how hyperrefs will be expressed in PDF. – Charles Stewart Aug 24 '11 at 12:43
  • Thanks for taking the time to add another comment, Charles. My first thought was that Ulrike had joined the Royal Navy -- "Hard a'lee ya swabs! Clap on to the mizzen sheet, Mr. Stewart and avast trapping the anchor! Handsomely now! – bev Sep 28 '11 at 19:43
10

One common problem is the redefinition of auxiliary macros: e.g., hyperref redefines internals of the counter mechanism so that hyperlinks work, and all counters defined before \usepackage{hyperref} don't benefit, but I don't know if that would fall under "conflict" for you since it's not usually something that causes compilation to fail, just the results are not what one expected.

|improve this answer
  • That's the sort of info I need, so thanks Ulrich. But, on a meta level, that sounds like a 'yes' answer to my question. 'redefines internals' sounds like a perfect setup for a naming conflict. In your case, not cs, but same basic thing. – bev Nov 25 '10 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.