Sender: |
|
Date: |
Sun, 17 Mar 2013 10:24:18 +0100 |
Reply-To: |
|
Message-ID: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
7bit |
In-Reply-To: |
<20130316121332.GA5586@csmvddesktop> |
Content-Type: |
text/plain; charset=ISO-8859-1; format=flowed |
From: |
|
Parts/Attachments: |
|
|
Hi Marc
> : I'd also like to strongly encourage developers to register their
> : prefixes by submitting them either directly to the team, to me or to
> : sending them to the list. I'll try to pick up new uses as they pop up on
> : the CTAN list, but may not catch everything.
>
> There may be a better way.
there may indeed. Guess what we are doing right now is feeling our way
through it to find it.
>
> Why don't the latex3 team provide a kernel method that people can use to
> register their prefixes? The idea is that this method takes the prefixes
> as input and writes them to some auxiliary file. When a package is uploaded
> to CTAN, all the CTAN team have to do is use the package once and add the
> output of the auxiliary file to the prefix database.
providing a kernel method might be a good idea to formalize and channel
things but I'm not 100% sure that the rest of the suggested work flow is
really improving the situation.
your suggestion moves the workload to the CTAN team and I don't think
this is possible or sensible. If at all it needs to be a solution that
would do the register update fully automatically.
for that reason I don't think that the introduction of another aux type
file is warranted it would be something only needed for managing the
register but required all over the place. In contrast, if you just have
a formal specification, you could regularly build the register by
scanning across all dtx ctan files.
> You can even make the kernel method reject existing prefixes. (Of course
> this would mean the method needs some way to access a local copy of the
> prefix database....) This may save the programmer precious time and
> troubles.
I don't think we want to reject prefixes. We encourage not to use
existing ones, but there will be a time when this is needed and wanted.
And in some cases reuse to "extend" a code base will also come into
play. And how would you want to communicated with a developer? if you
issue a warning then if it is deliberate you will need a way to get rid
of it and such a warning should not show up (imho) for a normal user. At
least not against the register as such. Perhaps on the level of what
prefixes got loaded into the document, but even then you would need to
resolve a situation where (for good or bad reasons) a prefix is shared
deliberately between packages.
so I guess food for more thoughts here, but a formal and parseable
interface on kernel level may be a good idea, even if we do not
directly use it to produce any external code or register updates/queries
from within TeX
cheers
frank
|
|
|