## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: Shortref mechanism

From:

Date:

Sun, 2 Mar 1997 13:48:57 +0100

Content-Type:

text/plain

Parts/Attachments:

 text/plain (36 lines)
 Frank Mittelbach <[log in to unmask]> wrote: >The above means that the shortref mechanism either has to be fully >expandable or that one can't use it to produce glyphs that might play >a part in ligature or kerning tables.   I cannot follow the details in your reasoning, but I can note that with deterministic parsing, the method generally used in LaTeX, conditional parsing have such limits.   But with non-deterministic parsing more general things can be done:   For example, I just made a definition command that can produce commands having optional arguments; in this general approach, I had to switch from LaTeX style deterministic parsing to non-deterministic parsing.   A command then picks down a look-ahead portion, like to the next space     \def\foo#1 { } %% Putting back the space consumed by the argument. It then examines this argument, and then has the opportunity of rejecting whatever non-parsed stuff unaffected, by returning (a part of) the _original_ look-ahead portion. Certainly, spaces do count in this approach. If the the only problem is the next character (like a brace) after the command or active character, perhaps you can combine, doing a simple one-token look-ahead, before the argument pickup; otherwise, TeX requires arguments to not have an extra "}", so one cannot enclose such a command in braces without at least one space occurs within those braces. (So there must be a look-ahead token that you can ensure to be on the same group level as the command.)   Actually, what is needed, is a simple extension of the TeX \def command:     \def\name{definition text}[exception text] If a command somehow is unable to process the parameter text, then the original input text (before the parsing of the parameter text began) is left unaffected, and the execution passes to the exception text.   Then stuff like optional commands could be implemented most easily, and perhaps the stuff you are asking for, too.   Hans Aberg