Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Wed, 9 Jul 2003 11:45:08 +0200 Received: by mail.proteosys.com (8.12.9/8.12.2) with ESMTP id h699j0PP019369 for ; Wed, 9 Jul 2003 11:45:06 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.9/8.12.9) with ESMTP id h699X5Gl005849; Wed, 9 Jul 2003 11:33:06 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C345FE.C83DAA00" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h68M02Y1007911; Wed, 9 Jul 2003 11:32:42 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 0702 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 9 Jul 2003 11:32:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h699WgM9013224 for ; Wed, 9 Jul 2003 11:32:42 +0200 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by relay2.uni-heidelberg.de (8.12.9/8.12.9) with ESMTP id h699WjGl005771 for ; Wed, 9 Jul 2003 11:32:45 +0200 (MET DST) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19aBJc-0007gW-00 for LATEX-L@listserv.uni-heidelberg.de; Wed, 09 Jul 2003 11:32:44 +0200 Received: from [212.159.37.164] (helo=MartinHensel.de) by mrelayng.kundenserver.de with asmtp (SSLv3:RC4-MD5:128) (Exim 3.35 #1) id 19aBJZ-0006rK-00 for LATEX-L@listserv.uni-heidelberg.de; Wed, 09 Jul 2003 11:32:42 +0200 References: <3BFEACE361F5BF429DD1DA593E3A7C0922406A@xch-nw-28.nw.nos.boeing.com> Return-Path: X-Mailer: Mozilla 4.75 [de] (Win98; U) X-OriginalArrivalTime: 09 Jul 2003 09:45:09.0140 (UTC) FILETIME=[C8EB9D40:01C345FE] X-Accept-Language: de,en X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -10.1 () QUOTED_EMAIL_TEXT,REFERENCES,USER_AGENT_MOZILLA_XM Content-class: urn:content-classes:message Subject: Re: Invitation for discussion: My suggestion for a LaTeX3 syntax Date: Wed, 9 Jul 2003 10:31:18 +0100 Message-ID: A<3F0BE0E6.E87B2479@MartinHensel.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Invitation for discussion: My suggestion for a LaTeX3 syntax Thread-Index: AcNF/skR4ArS36gURoeyRmwxLq3upA== From: "Martin Hensel" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4663 This is a multi-part message in MIME format. ------_=_NextPart_001_01C345FE.C83DAA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Wilson, Peter R" schrieb: > I read your proposal with interest. Thank you very much that you read it and for your question. > Your other major concern appears to be "the number of arguments > of \command{} [also environments] is unknown (the last {...} may > well be normal text)." However, I fail to see how your proposal > addresses that. Using named_arg=3Dvalue still requires an author to > know about the arguments, what they do, and which are required. > Additionally, authors will also have to remember the names of the > arguments. I feel that you are merely introducing unnecessary > overhead with no gain. My decision was made mainly in three steps. The first two are mainly concerned with better visual perception, the last one with the writer's and reader's memory. 1. Commands should enclosed in brackets. This decision was made to allow easier and faster visual regognition. You may be aware of Gestalt psychology that focuses on the priciples of perceptual organisation. Every book about perception should deal with this topic. Galitz [1] applies the Gestalt rules to text characters (among others). I used a combination of two perceptual priciples ('matching patterns' and 'closure') in order to improve command recognition. [ ] [ ] [ ] The human eye automatically recognises three entities of opening and closing brackets. (BTW, I used spaces here. In this case the proximity principle conflicts with the two other principles. When commands are enclosed, there will be no large space, so we will get rid of this conflict.) When looking at LaTeX code, the eye simply needs to look for a closing bracket in order to recognise the end of the command. This search is supported by fundamental psychological principles. With the current LaTeX2e (and TeX) syntax one has to scan for one of several possible delimiter characters. Very common are space, backslash, punctioation marks, and numbers. This should take much more mental effort and therefore a longer time to accomplish. There are two further points I want to raise at this point. Firstly, training and experience make you faster in recognising. The subscribers of this mailing list are surely very much familiar with the old syntax. Secondly, the old syntax had the advantage that one could use spaces to optically separate commands, but I avoided spaces as delimiters in order to avoid the special treatment of spaces after commands. ("It's really easy to forget to put in something like \ after a control word. I promise you that you will do it at least once while you're learning to use TeX." Doob: A Gentle Introduction to TeX) [1] Galitz, Wilbert o. (1997). The essential guide to user interface design: an introduction to GUI design principles and techniques. 2. Command parameters are included in the command enclosure. In order to find the end of a command with parameters one has to perform the following cognitive steps: current LaTeX: read the command name, remember how many mandatory parameters this command has, skip all existing optional parameters, skip as much {} enclosures as the amount of mandatory parameters With the new syntax one only has to look for end of current enclosure. This should be faster. Furthermore, it works as well when one does not know the command. 3. The combined position and named parameters Determining parameters by position is better if there is only a small amount of parameters that can be logically ordered. Named parameters are better when there is a large set of parameters and only a few are used. Furhtermore, such a command requires less mental effort when read, but it may require more effort to write it down. In my suggestion I simply combined the two ways in the hope that each of it would be used when it is most suitable. I hope you see that decision 2 and 3 are separate. In particular is it decision 2 that solves the problem with the diffent amounts of parameters, not the named arguments (3.). (I hope, I did not write too much.) Martin ------_=_NextPart_001_01C345FE.C83DAA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Invitation for discussion: My suggestion for a LaTeX3 = syntax

"Wilson, Peter R" schrieb:
>     I read your proposal = with interest.

Thank you very much that you read it and for your = question.

>     Your other major concern = appears to be "the number of arguments
> of \command{} [also environments] is unknown = (the last {...} may
> well be normal text)." However, I fail to = see how your proposal
> addresses that. Using named_arg=3Dvalue still = requires an author to
> know about the arguments, what they do, and = which are required.
> Additionally, authors will also have to remember = the names of the
> arguments. I feel that you are merely = introducing unnecessary
> overhead with no gain.

My decision was made mainly in three steps. The first = two are mainly
concerned with better visual perception, the last one = with the
writer's and reader's memory.

1. Commands should enclosed in brackets.

This decision was made to allow easier and faster = visual regognition.
You may be aware of Gestalt psychology that focuses = on the priciples
of perceptual organisation. Every book about = perception should deal
with this topic. Galitz [1] applies the Gestalt rules = to text
characters (among others).
I used a combination of two perceptual priciples = ('matching patterns'
and 'closure') in order to improve command = recognition.
[  ] [  ] [  ]
The human eye automatically recognises three entities = of opening and
closing brackets.
(BTW, I used spaces here. In this case the proximity = principle
conflicts with the two other principles. When = commands are enclosed,
there will be no large space, so we will get rid of = this conflict.)

When looking at LaTeX code, the eye simply needs to = look for a closing
bracket in order to recognise the end of the command. = This search is
supported by fundamental psychological = principles.
With the current LaTeX2e (and TeX) syntax one has to = scan for one of
several possible delimiter characters. Very common = are space,
backslash, punctioation marks, and numbers. This = should take much more
mental effort and therefore a longer time to = accomplish.

There are two further points I want to raise at this = point. Firstly,
training and experience make you faster in = recognising. The
subscribers of this mailing list are surely very much = familiar with
the old syntax. Secondly, the old syntax had the = advantage that one
could use spaces to optically separate commands, but = I avoided spaces
as delimiters in order to avoid the special treatment = of spaces after
commands. ("It's really easy to forget to put in = something like \
after a control word. I promise you that you will do = it at least once
while you're learning to use TeX." Doob: A = Gentle Introduction to TeX)

[1] Galitz, Wilbert o. (1997). The essential guide to = user interface
design: an introduction to GUI design principles and = techniques.


2. Command parameters are included in the command = enclosure.

In order to find the end of a command with parameters = one has to
perform the following cognitive steps:

current LaTeX: read the command name, remember how = many mandatory
parameters this command has, skip all existing = optional parameters,
skip as much {} enclosures as the amount of mandatory = parameters

With the new syntax one only has to look for end of = current enclosure.
This should be faster. Furthermore, it works as well = when one does not
know the command.


3. The combined position and named parameters

Determining parameters by position is better if there = is only a small
amount of parameters that can be logically = ordered.

Named parameters are better when there is a large set = of parameters
and only a few are used. Furhtermore, such a command = requires less
mental effort when read, but it may require more = effort to write it
down.

In my suggestion I simply combined the two ways in the = hope that each
of it would be used when it is most suitable.



I hope you see that decision 2 and 3 are separate. In = particular is it
decision 2 that solves the problem with the diffent = amounts of
parameters, not the named arguments (3.).

(I hope, I did not write too much.)

Martin

------_=_NextPart_001_01C345FE.C83DAA00--