LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Fri, 11 Jul 2003 11:30:34 -0400
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=iso-8859-1
From: William F Hammond <[log in to unmask]>
Parts/Attachments: text/plain (109 lines)
Martin Hensel <[log in to unmask]> writes:

> > For example, look at the source (suffix ".glm") of the manual in
> > http://www.albany.edu/~hammond/gellmu/glman/
>
> 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

    \newcommand{\sgml}{\abbr{SGML}}

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="http://www.w3.org/"]{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="http://www.w3.org/"]{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="http://www.w3.org/"] {W3C} HQ,

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

\anch[
href=
"http://www.w3.org/"
]{W3C}
HQ

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

{
W3C
}

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

                                    -- Bill

ATOM RSS1 RSS2