LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced 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
Mailing list for the LaTeX3 project <[log in to unmask]>
Sun, 17 Mar 2013 10:24:18 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=ISO-8859-1; format=flowed
Frank Mittelbach <[log in to unmask]>
text/plain (57 lines)
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