Lines: 47
References: <1rb2vdciob67d$.dlg@nililand.de>
            <4E5F75C0.8030105@morningstar2.co.uk>
            <fqvtzpmiulpq.dlg@nililand.de>
            <CAArVCkS_716t0s6Rm08Hp1buCPQHX69B9ZDMGig10_w8h9i4QQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
User-Agent: 40tude_Dialog/2.0.15.41de
Message-ID:  <1l4jyzmu3jnoc.dlg@nililand.de>
Date:         Thu, 1 Sep 2011 16:51:03 +0200
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: Ulrike Fischer <news3@NILILAND.DE>
Subject: Re: Internal equivalent of \providecommand?
To: LATEX-L@listserv.uni-heidelberg.de
Precedence: list
Status: R

Am Thu, 1 Sep 2011 16:07:07 +0200 schrieb Philipp Stephani:

> 2011/9/1 Ulrike Fischer <news3@nililand.de>:
>> Am Thu, 1 Sep 2011 13:08:32 +0100 schrieb Joseph Wright:
>>
>>> On 01/09/2011 11:57, Ulrike Fischer wrote:
>>>> Is there an expl3 equivalent for a \providecommand?
>>>>
>>>> I could do
>>>>
>>>> \cs_if_free:NT \mycommand {\cs_set:Npn \mycommand {...}}
>>>>
>>>> but I don't find it very elegant to have to type \mycommand twice.
>>
>>> At the code level, the answer is 'no'. Within a module, we'd expect all
>>> functions to be well-defined: if they 'might' be needed, they should
>>> exist. (See for example the fact that a lot of internal aux functions
>>> are created simply to mark the name as taken.)
>>
>>> Now, there is the reality that LaTeX2e stuff is often not so
>>> well-designed and does sometime rely on 'might exist' functions. There,
>>> I'm afraid the construct you've pointed to is the way to go.
>>
>>
>> Well my command (it is more a variable so \tl_set would perhaps be
>> more correct) must exist and that's why I'm using \providecommand:
>> To make sure *that* is exists. I'm not relying on a "might exist"
>> command but try to ensure that it is a "does exist" command.
>>
>> The problem is that it must exist in various encoding definitions
>> files for fontenc, in the sty (chessfss) and that its "value" can be
>> set/changed by the user -- which means that I have no control over
>> the location where the default value should be set. I have to set it
>> in various places in such a way that it doesn't overwrite user
>> settings.
> 
> Wouldn't it be more appropriate to use a key-value option with default
> value then?

What would it help? I still would have the problem that this could
overwrite a setting of a user. 


-- 
Ulrike Fischer