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
Condense Mail Headers

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

Print Reply
Content-Transfer-Encoding:
7bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Martin Hensel <[log in to unmask]>
Date:
Wed, 9 Jul 2003 10:31:18 +0100
Content-Type:
text/plain; charset=us-ascii
MIME-Version:
1.0
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (93 lines)
"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=value 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

ATOM RSS1 RSS2