References: <534042.27913.qm@web56906.mail.re3.yahoo.com>,
            <4D19B128.4080209@imf.au.dk>
            <1770264784.31063.1293534026745.JavaMail.fmail@mwmweb011>,
            <C650B5DA-BFBF-4223-AB6C-8CC78693336F@yahoo.de>
            <1477280164.3360115.1293538024193.JavaMail.fmail@mwmweb010>,
            <DA3074FF-707A-49B9-A32D-4FBA63281505@yahoo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Importance: normal
Sensitivity: Normal
Message-ID:  <1937220271.3737477.1293582964683.JavaMail.fmail@mwmweb010>
Date:         Wed, 29 Dec 2010 01:36:04 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Uwe Lueck <uwe.lueck@WEB.DE>
Subject: Re: [texhax] Defining a command which runs differently based ion input argument
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <DA3074FF-707A-49B9-A32D-4FBA63281505@yahoo.de>
Precedence: list
Status: R

"Philipp Stephani" , 28.12.2010 17:08:27:
> Am 28.12.2010 um 13:07 schrieb Uwe Lueck:
>> "Philipp Stephani" , 28.12.2010 12:19:02:
>>> Am 28.12.2010 um 12:00 schrieb Uwe Lueck:
>>>> That is much worse with LaTeX's square brackets for optional arguments, as some scholars use square brackets for ellipsis or redactional insertions (I experienced this several times):
>>>> 
>>>>   Title-like\\ % imitating the manuscript's line break and spacing
>>>>   [unreadable] ipsum dolor sit amet
>>> 
>>> That would be fixed if \@ifnextchar didn't swallow space tokens. [...]
>> 
>>    Lorem\\% NOTE: exactly as the manuscript! 
>>    [unreadable] dolor sit amet
>
> Or
>
> Lorem\newline % with extra space
> [unreadable] ipsum

or maybe it's the *comment* character's fault!? 
It might be an *active* character, analyzing the situation ... 
or an *interactive* character, asking "are you trying to fool me?"

> I know there are many issues with the TeX lexical analyzer and parser, 
> and the extremely complex rules about spaces is one of them, 
> but not ignoring space token would at least fix a small number 
> space-related problems.

hm, more seriously: TeX offers many possibilities to the programmer, 
it's the latter's fault ...

(Ahm, in wiki.sty, http://ctan.org/pkg/nicetext, I have implemented 
 some analysis of "first tokens of an input line" to call 
 LaTeX list environments.)

Indeed, I originally used the occasion to express my anger 
about Leslie Lamport's choice of square brackets as 
"optional argument delimiters". 

Sometimes it has seemed to me that "angle brackets" 
would be the better "optional argument delimiters". 
I am thinking of ednotes, ArabTeX, PicTeX ...
But really, it depends on the document's subject matter ...

I really wondered if LaTeX3 could offer the choice to authors 
which should be the optional argument delimiters.

More generally (aiming at future TeXs), there really might be 
more *category codes*, so you could have 
(i) category codes for "optional argument delimiters"
(ii) category codes for "group delimiters", independently of 
"mandatory argument delimiters" 
(i.e., one certain character could work like \begingroup, 
 and another like \endgroup; and then think of \hbox\bgroup 
 vs. "\hbox{" ... "box content delimiters")

Less seriously, with *ternary* computers, we might have 
27 category codes instead of only 16 ...

Cheers, bling, 

    Uwe.