LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
William F Hammond <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Fri, 11 Jul 2003 11:30:34 -0400
text/plain (109 lines)
Martin Hensel <[log in to unmask]> writes:

> > For example, look at the source (suffix ".glm") of the manual in
> >
> The only difference to the LaTeX syntax I could see are the different
> treatment of command ends

The idea is for the markup to be convenient for those with LaTeX
habits as well as to be syntactically clean.

>   \tex; Directory

\tex; produces <tex/> at both first stage (SGML article) and second stage
(XML article).

But for gellmu "article", because the name "tex" is defined-empty, one
could also write

    \tex Directory

getting "<tex> Directory" at first stage and "<tex/> Directory" at
second stage.  With only a formal parse this would not work.

Alternatively, with "article" the markup "\tex{}" would yield
"<tex></tex> Directory" at first stage and "<tex/> Directory" at
second stage.

So in this case by the second stage all three forms are the same.
Note that the sgml form of "article", unlike the sgml form of html,
has case-sensitive names and allows any of "<foo>", "<foo/>", or
"<foo></foo>" when "foo" is defined-empty.

>   \sgml document types

Here one could have missed the earlier definition


So with macro substitution the
above resolves to

    \abbr{SGML} document types

Even so, the syntactic translation does not eat space, but SGML
parsing can have the effect of eating space.

The net result, however, is that as an author I make fewer missing
space mistakes in gellmu than in LaTeX.

> and the possibility that a space after a command with parameters is
> ignored (p. 11).
>   \anch[href=""]{W3C} HQ,

With "article" this involves an "advanced" mode feature: the space
after the right brace survives because the name "anch" is in the
variable gellmu-autoclose-list when the documenttype is "article".  So
the syntactic translator writes the closetag for "anch" before the
space.  If it did not write that closetag, SP would write it later
after seeing (and effectively swallowing) the space.

In basic mode for HTML the markup

    \a[href=""]{W3C} HQ

also works because there is no multiple argument/option syntax in
basic mode, so the option is the attribute list, and the sole argument
is element content.

> Did I miss something else?

Perhaps things that are absent.

If you write "\frac23", you'll generate "<frac23>", because there is
no obfuscated argument syntax, and, as with sgml/xml, numerals can be
used in command names.

In principle, command names may contain any Emacs "word" character.
However, the only illustration of this provided in present gellmu
"article" is "\étale{}", a five character French name, which is an
alternate form of (inline) emphasis.  (This message is UTF-8 encoded.)

Also it is required in gellmu advanced mode multiple argument/option
syntax that there be no white space separating a command name from its
first arg/opt or separating successive arg/opt's.  If you write

   \anch[href=""] {W3C} HQ,

the SGML won't parse.  But to avoid long lines, you can write


White space is a very sensitive matter for visible anchor text,
so for the particular case of "anch", one might not want to replace
the last "{W3C}" with


but with many other names this would be fine, too.

                                    -- Bill