I have the following command written in my preamble
\renewcommand{\d}{\;\ensuremath\mathrm{d}}
but get the error
LaTeX Warning: Command \d invalid in math mode on input line 11.
This only happens on a couple of my documents, and I can't figure out why. This also happens when I redefine \a, \b, \c to other things (like vectors).
There are two issues, really. The first is that it is an extremely bad idea to redefine basic TeX and LaTeX macros unless you absolutely know what you are doing.
The second is that \; is not valid outside maths mode.
Perhaps you want something like
\documentclass{article}
\begin{document}
\newcommand{\drm}{\ensuremath{\;\mathrm{d}}}
\drm
\end{document}
This is a response to the OP's comment
@YanZhou aha! it was another package. Turns out hyperref redefines them.
NO! It is not. hyperref is not doing this at all. Describing it this way is just wrong. I cannot emphasise this strongly enough: hyperref is not redefining these macros.
Redefining \d to be \mathrm{d} or making \a or \c into macros for vectors is not at all like what a package such as hyperref is doing.
What we see in hyperref's puenc.def, for example, are lines such as
\DeclareTextCommand{\d}{PU}[1]{#1\83\043}% U+0323
and
\DeclareTextCompositeCommand{\d}{PU}{\@empty}{\textdotbelow}%
These are telling TeX what \d does when the PU encoding is being used. This is fine because this macro is designed to be encoding-dependent. This is what you are meant to do if you are writing a new encoding which should support \d.
hyperref is not redefining \d. This is (or should be!) a new definition because the PU encoding doesn't even exist until hyperref sets it up.
What hyperref is doing, rather, is defining a new output encoding. Output encodings have to define certain things and may define more. hyperref is not overwriting existing definitions because the definitions it gives for \c and \d are part of the definition of the new encoding and that encodings definitions are isolated from the definitions of the same macros for other encodings.
That is, what hyperref is doing is fine. What you are trying to do is a Very Bad Idea. It is a Very Bad Idea precisely because these kinds of macros play a fundamental role in the typesetting process and redefining them will come back to bite you sooner or later.
\d or \c, etc. (Of course, this is implied in your first point, but making it more explicit for new users seems advisable.) ... of course, I now see that @YanZhou already made this point above..!
– jon
Jun 23 '16 at 01:14
\a. But that's not the case here, the overwriting is deliberate. If you're going to overwrite a primitive or low-level macro, it is no worse because the macro has a single-lettered name. It is no better to say \renewcommand\end{...} than \newcommand\e{...}....
– cfr
Jun 23 '16 at 01:31
\def\d{...}, which is (I think) exactly what the OP is doing with the (re)definitions of \a, \b, \c, \d. So: sometimes people even do \def\b{\begin{<env.>}}, etc. Thus, the deeper problem (from a motivation perspective) is the single-letter redefinitions for shorthands, even if, from a TeX perspective, the deeper problem is actually the redefinition of (La)TeX internals. Both are reasons not to redefine \d --- and this should be stressed to new users.
– jon
Jun 23 '16 at 02:31
\def\d{...}. The OP told us exactly what the OP is doing and that is \renewcommand\d{...}. The OP knows these are redefinitions: ... when I redefine \a, \b, \c to other things .... So whatever you think is exactly what the OP is doing, that is not what the OP said the OP is doing. The usual issue is the one you describe - people use \def and don't know. People don't use \renewcommand and not know. (OK. It is possible. But that's not what seems to be happening here and would be most unusual.)
– cfr
Jun 23 '16 at 02:37
\renewcommand to define a brand new command, simply because they took a \renewcommand somebody else had done for them as a model for defining any and all new commands :P (P.S. just an anecdote, I agree with you that our OP knows what they're doing and that what they're doing is not what they should be doing. I would say, though, that it's the one letter commands that people are most likely to want to define over and the least likely to understand the potential problems with that.)
– Au101
Jun 23 '16 at 02:49
a and a particular encoding is active, which character it should use from the font. (It is actually more complicated than this, but this will do for now.) In addition to mapping individual characters like a, TeX can map macros like \d. And in addition to mapping to a single character, it can map to a combination of characters. In the case of puenc.def, the output encoding defined isn't used in the usual way but is used by hyperref, I think ...
– cfr
Jun 24 '16 at 00:20
hyperref works, so I'm not sure exactly how these are used. But you are also, of course, overwriting or trying to overwrite these macros in whatever other encodings you are using. I don't know what you mean by 'corrupt' but you should absolutely correct this and recompile the PDF, yes!!! I don't know exactly what damage this will do, but these macros cannot be safely changed.
– cfr
Jun 24 '16 at 00:24
\d{}, for example, is used to create the dot under accent. At least, that's what it does in OT1 and T1, for example. (See the fontenc documentation for details.) You might think that if you don't need this accent, you can overwrite it. However, it is really not at all safe to do this however certain you are. Apart from anything else, \d{} may be used differently in other encodings and your document will use many different encodings (yes, even if you're using a unicode engine, this is still true). Do you know what they all are or whether \d is important for you in any?
– cfr
Jun 24 '16 at 01:15
\renewcommand (which I switched to \def initially to get under the character limit). But I am not convinced that this necessarily indicates the degree of 'knowing' that you are ascribing to the OP. It could be as you say, but the subsequent comment suggests a less strong form of 'knowing'. & knowing that you are redefining (and not merely defining) something in order to create a shorthand macro does not impact whether the motivation to create single-character shorthands is good or bad practice. It's just, IMO, bad practice. Also likely dangerous.
– jon
Jun 24 '16 at 02:09
\value. I think you're right about single letter macros being bad generally. But it really matters that people get why and don't just get the single-letters-bad bit.
– cfr
Jun 24 '16 at 03:01
\R for \mathbb{R} etc. The only issue is that you should not redefine the internals of the system that you are using. redefining \c is bad for the same reason that redefining \box is bad, the fact that c is one letter is not really relevant.
– David Carlisle
Jun 24 '16 at 08:18
\def or \renewcommand(!) in a real .tex file (and not just for a quick test), and (2) if you don't know when and why it might be a bad idea. When either or both of those conditions hold, the motivation to create single-letter macros is, generally, a bad idea. And I think both conditions hold in the OP. I certainly don't recommend redefining \box (or \value, or ...) either. I'd also add that single-character macros names tend, generally, to lead to (unintentional) obfuscating of code, which makes it undesirable in the long run.
– jon
Jun 25 '16 at 00:08
\def or \renewcommand rather than \newcommand. If somebody will use \newcommand then they can use available single letters for macros without needing to know that much because if they get an error, they can just reject that choice. Knowing this is a much more general method than avoiding single letters, because the same method will protect other macros such as \value and \box. Otherwise, the rules are just arbitrary-seeming.
– cfr
Jun 25 '16 at 00:59
\cwas predefined by tex for another purpose and possibly redefined by packages likefontspec. It is generally a very bad idea to define a global single letter macro in latex (or any programming language for that matter) – Yan Zhou Jun 23 '16 at 00:55hyperrefis absolutely 100% not doing that. Please see my answer below. You are overwriting basic macros at your peril.hyperrefis not overwriting anything. If you were lucky, it would overwrite your redefinitions. Unfortunately, that is not happening - at least, not reliably, anyway. – cfr Jun 23 '16 at 02:09