LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

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
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 22 Jan 2009 10:39:30 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
 > > 1) Loosening of the 9-argument restriction on user-written macros: this
 > > is a thoroughly antequated and very limited restriction.
 > 
 > Two things here.  First, keyval-type methods already do this, and to be
 > honest a macro which needs say 15 arguments in a row seems a bit
 > daunting to me!  Second, the low level #1, #2, etc. business is from the
 > engine (no idea about LuaTeX).

it may be an antequated restriction, but we will not lift on the programming
level it nor do we think it is very limiting. As Joseph said, macros with more
than 9 positional arguments are not really sensible as a user interface anyway
in fact anything there with more than 3 or 4 arguments is questionable in my
eyes.


 > > 2) Arguments to user macros resolved by #1, #2, etc.: See 1) above.  
 > > There are many ways of refering to arguments and the
 > >  #1 #2 etc is very limiting

on the programmers level that is adequate enough (and fast). On the
designer/user level other methods are (and will be) available.

 > > 3) Arguments specified positionally only: It should be possible to 
 > > specify argument by name=value pairs.
 > 
 > Again, keyval-type methods do this, and allow you to store input as
 > named macros (which is pretty close to what you ask).  The template
 > module does some of this, although I've made the case for a more general
 > keyval module with my "keys3" attempt.

for the designer level we already have a key value interface and I'll expect a
user interface to support that kind of specification as well. As Joseph said,
we are looking at providing a more general key/val interface so something like
the template mechanism might get some changes generalizations eventually.

But agreed this is essential on those two interface levels (document designer
and document user).

frank

ATOM RSS1 RSS2