> I actually think this idea of a "document shorthand" such as this, being a
> macro with no arguments (or perhaps with a very simple macro replacement
> rule -- say anything expandable that doesn't rely on counters or position in
> the document) should be a somewhat formal construct that we define.
>
> [snip]
>
> But besides the interface improvement with avoiding the spaces behaviour,
> such a "shorthand" system could also be used in post-processing to convert
> a document with author shorthands into an "expanded" document that doesn't
> require the macros.

I agree. Each author can freely input a file with his favorite
shorthands. Then before sending it out to coauthors, he can cleanse
it, replacing each shorthand by its definition. This would avoid
having huge preambles at the beginning of a file, where in fact only a
few definitions are used in the text. A less ambitious goal would be
to only include those macros that are used in the text (I finally
figured most of that one out).

I've written last week some dirty code for replacement in TeX source.
I am not yet completely sure what is possible to allow, and what is
not possible. But a few thoughts:

- these shorthands need to be context-independent (e.g., impossible to
check whether we are in math mode or not when replacing them)

- they don't really need to be expandable. For example, we can replace
\foo/ by 1, 2, 3, ..., numbering the first, second,... occurences of
\foo in the source. For example, it can be used for expanding acronyms
with special treatment at the first occurence (of course, only do that
when the text is ready).

- contradicting my first point: it is possible to do something similar
to "div p" in css, namely, "\def_in{document itemize}\foo/{...}" could
define \foo/ to expand to {...} if it is inside an itemize environment
inside the document environment.

The ability to detect for example whether we are in math mode or not
depends on how precise the LaTeX3 syntax is. If we require something
like \DeclareMathEnvironment (or whatever), then it is easy.

>     \def\ie/{i.e.}
> Perhaps a trailing semicolon would be a better idea; I'm not really sure

Possible issue with "/": if a package tries to be clever with / in
math mode, and sees / before expanding \ie, it could cause endless
trouble.

Bruno