LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 7 Jun 2012 18:41:32 +0200
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
From:
Lars Hellström <[log in to unmask]>
Parts/Attachments:
text/plain (81 lines)
Frank Mittelbach skrev 2012-06-07 11.54:
> Am 07.06.2012 10:15, schrieb Lars Hellström:
>>>> Other approaches I would find preferable to %<@@=foo> is to use
>>>> %%% lines (as an homage to mft) or explicit commands in the .ins
>>>> file; after all, most source files don't contain code for
>>>> multiple l3-modules.
>>>
>>> To be honest I don't like that much but perhaps this is something
>>> one just needs getting used to.
>>
>> Note that these are "/other/ possibilities I would actually find
>> preferable to assignment-guards"; you snipped my preferred realm of
>> solution without comment.
>
> sorry that was after midnight. You mean
>
>> FWIW, an alternative way of embedding extra directives into a .dtx
>> file that I have in production is to designate a specific docstrip
>> module as containing code that is directives for the stripper. If one
>> picks the very crude syntax for "directives" that each codeline in
>> the @@ module sets the current @@ replacement then the above could
>> become
>>
>> %<@@>foo
>> %<*pkg>
>> \@@_function:nn % Will be converted to \__foo_function:nn
>> \l_@@_variable_tl % Will be converted to \l__foo_variable_tl
>> %</pkg>
>
> Maybe I still don't quite understand directives but
>
> %<@@>foo
>
> doesn't really look much different to
>
> %<@@=foo>
>
> except that I think it is less readable but mileage may vary
>
> Perhaps you can expand on that once more?

The difference is that in %<@@> the guard is just a guard, guarding some 
piece of code which may perhaps be destined for some target, whereas in 
%<@@=...> it is something different that just happens to be shoehorned into 
the same syntactic realm. If docstrip sees %<@@=foo> it will check if 
"@@=foo" is true for any output file, which it most likely not the case and 
so nothing happens, but still: an incorrect interpretation is applied to the 
material.

If docstrip sees %<@@>foo it checks whether some output file has @@ true, 
and since none has it continues to the next line. My idea is that l3docstrip 
could treat the @@ module (\Module in the sense of doc.sty) somewhat like a 
stream of commands that it will react to immediately rather than write out 
to a file. %<@@>foo is, as I wrote, a rather crude syntax to employ here; 
more flexible syntaxes could be

%<@@> \AtAtReplacement{foo}

or

%<@@> @@ = foo, sourceencoding = latin1

where the latter (contents is keyval list) illustrates having and setting 
other parameters[*] besides the @@ replacement. Of course, there's no 
particular need to call the docstrip module @@ as well in these cases.

[*] I tend to be very much back and forth regarding whether it would be 
useful to support encoding conversions as part of docstripping. It's 
probably not so much use for pure-TeX projects, but mixed language projects 
could be another matter.

In the case where I'm employing this kind of "directives module" (with 
terminal "docstrip.tcl::catalogue"), I use it as an in-.dtx catalogue of 
things that can be generated from the .dtx. The reasons this became more 
practical than using a traditional .ins file was because (i) the version 
numbers of certain generated files had to be included in the file name (/so/ 
not the (La)TeX way) and (ii) it in this case turned out that the natural 
unit for a source file corresponded to many small generated files.

Lars Hellström

ATOM RSS1 RSS2