LATEX-L Archives

Mailing list for the LaTeX3 project


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
text/plain; charset="us-ascii"
Thu, 1 Sep 2011 18:10:03 +0200
Mailing list for the LaTeX3 project <[log in to unmask]>
Mailing list for the LaTeX3 project <[log in to unmask]>
Ulrike Fischer <[log in to unmask]>
text/plain (49 lines)
Am Thu, 1 Sep 2011 16:44:17 +0100 schrieb Joseph Wright:

> On 01/09/2011 13:53, Ulrike Fischer wrote:
>> 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.
> That's broadly what I mean by 'LaTeX2e issues': having a value which is
> used directly at a user level, and in various files, is not good.
> You don't say if the value might alter again after you've
> \providecommand'd it. If not, then I'd be tempted to go with something like
>   \tl_new:N \l_<internal-thing>_tl
>   \cs_if_exist:NTF \<thing>
>     { \tl_set_eq:NN \l_<internal-thing>_tl \<thing> }
>     { \tl_set:Nn \l_<internal-thing>_tl { <default> } }
> On the other hand, if this variable in question has to be user-setable
> at any point, then you can't use an internal value and have to stick to
> a manual '\providecommand' approach.
> (I'm assuming that the variable in question is one that is already
> required by LaTeX2e constructs, and so 'simply do things differently' is
> not an option.)

The variable in question is my own command and I can do with it what
I want. That is not the problem. 

But as I now started to rewrite chessfss with expl3 I'm trying to
use clean code, to exploit its features and to avoid unnessary hacks
and compromisses. 

And after thinking more about it: I think the cleanest solution is
to export the commands in question in a .sty and to use
\RequirePackage to include them in the various files. Then they are
set exactly once and are only in one place.  

Ulrike Fischer