# choosing macro names so as to avoid namespace conflicts

I wish to choose names for macros in a manner that is least likely to conflict with names of other macros (including macros in packages that are not included in a document). Therefore, simply compiling the document with an invocation of a command and determining whether errors are thrown is not a desirable solution because the macro name may, in fact, be used in a very common package that has not been included in the compiled document. I suppose an ideal solution would be a LaTeX macro search engine that searches all packages in some database or archive (e.g., CTAN). I could then check a desired name for potential conflicts. Another useful solution would be a compiled table of all macros from packages in some archive or archive subset. Such a list would probably require some form of curation, though it could also be automatically generated. A final thought is that one could restrict the search to installed packages on one's machine.

-
\newcommand will flag an error if the macro already exists. providecommand will create your definition of the macro, provided that there was no previous definition; otherwise it will leave the original definition alone. –  Brent.Longborough Feb 7 '12 at 10:27
See the topic "Is this command defined?" (tex.ac.uk/cgi-bin/texfaq2html?label=isdef) for a detailed answer to your question. –  Mico Feb 7 '12 at 11:27
Is this for your own document or for a package you write and like to provide to other people? –  Martin Scharrer Feb 7 '12 at 12:20
I guess the related post (tex.stackexchange.com/q/12362/10127) isn't quite what I had in mind. I may define a name that is unique among loaded packages and use said command hundreds of times in a document. Then if I load another package that does define a command with the same name, I need to change the hundreds of instances where that command was used. I would prefer to test whether a name is used on a broader scale (e.g., all packages on my machine or some subset of all published LaTeX packages). A macro search engine or a compiled table would be more useful to me than \newcommand. –  user001 Feb 9 '12 at 6:12
I reopened your question. It would be good if you would make the intention clearer in the question title, and perhaps edit the question text a bit, such that readers would understand it the way you explained in the comment. –  Stefan Kottwitz Feb 10 '12 at 7:40

This isn't possible, I'm afraid. Macros can be defined (or, more generally, a control sequence can be given a meaning) in many different ways.

Just yesterday, while discussing with another member of this community, we came across a macro \gla defined by some package. In the .sty file there is no line such as

\let\gla=...
\def\gla{...}
\newcommand{\gla}{...}
\DeclareRobustCommand{\gla}


or variations thereof. Indeed the control sequence \gla doesn't appear once in the whole package. Oh, boy! How is that command defined, then?

The package wants to define a bunch of similar macros: \gla, \glb, \glc and maybe others and their definition should follow the same scheme, say

\let\gla\glw@gla
\let\glb\glw@glb


and so on, where the internal macros have already been defined. So, instead of repeating those definitions over and over again, the developers wrote

\def\glw@assign@level#1{%
\edef\temp{\noexpand\let
\expandafter\noexpand\csname gl#1\endcsname
\expandafter\noexpand\csname glw@gl#1\endcsname}%
\temp
}


and then they call one of

\glw@assign@level{a}
\glw@assign@level{b}
...


inside some other macro, so that \gla is defined only in the environment where it's needed. More precisely, there is no direct call of those last commands, but rather there's some macro that contains

\glw@assign@level{#1}


and the parameter #1 will be substituted at run time.

The conclusion is that's impossible to build a huge database of all defined macros, unless all package writers submit to it a list of all the macros their package defines. And this is hardly possible: some packages provide commands that in turn generate macros according to some scheme, but what macros are actually generated may depend on the user's choice.

What can a user do, then? Define your macros to have a meaningful name; avoid "shorthands" (that are impossible to remember after a couple of months); use a prefix; finally, hope for the best. :)

In my experience it happened only a handful of times that some of my personal macros came to conflict with a new version of some package or some newly loaded one and were invariably macros whose name had not been chosen according to my own recommendations. :)

-
Seeing the definition of \glw@assign@level makes me want to reconsider the days I spent browsing C headers files trying to find the real definition underneath all the macros as quite pleasurable in comparison. –  Frg Feb 27 '12 at 13:48
@Frg With LaTeX3 it would be \cs_new:Npn \glw_assign_level:n #1 { \cs_set_eq:cc {gl#1} {glw_gl#1:} }. Within standard (La)TeX it could be \def\glw@assign@level#1{\expandafter\let\csname gl#1\expandafter\endcsname\csname glw@gl#1\endcsname} or, with the help of etoolbox, \def\glw@assign@level#1{\csletcs{gl#1}{glw@gl#1}} –  egreg Feb 27 '12 at 13:55
Is there no way to run TeX or a modified version thereof that logs each macro definition? We already know which commands are used to define commands. To address the \gla problem you've described: is there really no way to log each addition to the hashtable of definitions if a package is loaded (variation in package options aside)? Finally, what about LaTeX3? –  Lover of Structure Mar 16 '13 at 20:14
@LoverofStructure You can trace definitions in the log file with \tracingassigns=1 and \tracingcommands=3; but this information is not available at the user level. –  egreg Mar 16 '13 at 21:59
In that case, wouldn't it be very easy to trace all command definitions for all packages and document classes on CTAN, with supervision only needed for some details like package options? It should then be very easy to dump the result into a publicly accessible database, in a form like the OP suggested. –  Lover of Structure Mar 17 '13 at 0:58