Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 14:16:29 +0200 Received: by mail.proteosys.com (8.12.10/8.12.2) with ESMTP id i9CCH5rT008450 for ; Tue, 12 Oct 2004 14:17:06 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.119.176]) by relay2.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i9CCAbuB026615; Tue, 12 Oct 2004 14:10:37 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B055.4D5F0C80" Received: from listserv (listserv.uni-heidelberg.de [129.206.119.176]) by listserv.uni-heidelberg.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i9BDwlpn011246; Tue, 12 Oct 2004 14:10:06 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8e) with spool id 664326 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 12 Oct 2004 14:10:05 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i9CCA5RP026657 for ; Tue, 12 Oct 2004 14:10:05 +0200 Received: from babbage.uvt.nl (babbage.uvt.nl [137.56.247.14]) by relay2.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i9CCAPuB026564 for ; Tue, 12 Oct 2004 14:10:27 +0200 (MET DST) Received: from pi2326 (pi2326.uvt.nl [137.56.45.40]) by babbage.uvt.nl (8.12.10/8.12.10/Debian-5-UvT-15) with SMTP id i9CCANQd029962 for ; Tue, 12 Oct 2004 14:10:23 +0200 In-Reply-To: Return-Path: X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft Exchange V6.5 X-OriginalArrivalTime: 12 Oct 2004 12:16:29.0285 (UTC) FILETIME=[4D8A8950:01C4B055] X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang at proteosys.com X-Spam-Status: No, hits=-0.0, required=5.0 tests=BAYES_44 X-Spam-Level: - x-spam-flag: No X-ProteoSys-SPAM-Score: 0 () x-spam-cookie: 8e882b0e746e7c1d10bd5091a37d2a13306bb6d3 Content-class: urn:content-classes:message Subject: Re: naming conventions LaTeX3 Date: Tue, 12 Oct 2004 13:10:51 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: naming conventions LaTeX3 Thread-Index: AcSwVU2qHSzXVJ5eTA+Uu9xPu33PTg== From: "Hendri Adriaens" Sender: "Mailing list for the LaTeX3 project" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4815 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B055.4D5F0C80 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Hi Morten, > That is not my experience. The times I've had to use the "w" type has = been > in situations where I needed to gobble a user command that happened to > take an optional argument. And in those cases the reason has been that = I > didn't use xparse. If I did I would define those user commands as > something like this: > > \documentclass{article} > \usepackage{xparse,ldcsetup} > \InternalSyntaxOn > > \def\MH_test_user_command:nn #1 #2 {#1,#2} > \DeclareDocumentCommand \usercommand { O{`opt'} m } > { \MH_test_user_command:nn {#1}{#2} } > > \begin{document} > \usercommand{uu} > > \usercommand[xx]{uu} > \end{document} > > Then gobbling is done on the internal macro when needed. > > Perhaps you can think of other cases - if so don't hesitate to post = them. Thanks for the example. Since I didn't finish reading yet, I don't have a clear vision on the implications of the naming convention. But when reading the document, I started to wonder whether it would be flexible enough or not. I can't think of explicit examples right now since I first have to finish reading all the details of the new implementation. But thanks for the message. It takes away a question that I had after reading this information. Best regards, -Hendri. ------_=_NextPart_001_01C4B055.4D5F0C80 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Re: naming conventions LaTeX3

Hi Morten,

> That is not my experience. The times I've had to = use the "w" type has been
> in situations where I needed to gobble a user = command that happened to
> take an optional argument. And in those cases = the reason has been that I
> didn't use xparse. If I did I would define those = user commands as
> something like this:
>
> \documentclass{article}
> \usepackage{xparse,ldcsetup}
> \InternalSyntaxOn
>
> \def\MH_test_user_command:nn #1 #2 = {#1,#2}
> \DeclareDocumentCommand \usercommand { O{`opt'} = m }
>    { \MH_test_user_command:nn = {#1}{#2} }
>
> \begin{document}
> \usercommand{uu}
>
> \usercommand[xx]{uu}
> \end{document}
>
> Then gobbling is done on the internal macro when = needed.
>
> Perhaps you can think of other cases - if so = don't hesitate to post them.

Thanks for the example. Since I didn't finish reading = yet,
I don't have a clear vision on the implications of = the
naming convention. But when reading the document, I = started
to wonder whether it would be flexible enough or not. = I
can't think of explicit examples right now since I = first
have to finish reading all the details of the new = implementation.

But thanks for the message. It takes away a question = that I
had after reading this information.

Best regards,
-Hendri.

------_=_NextPart_001_01C4B055.4D5F0C80--