Re: forwarded message from Jeff Licquia
Henning Makholm writes:
> > [example of the complex way removed]
>
> I thought I argued in quite a level of detail why it is the *only* way
> that is allowed by the renaming rule. If you think my arguments are
> wrong, could you please explain why in more detail than just
> dismissing them as "the complex way"?
sorry, i thought that I made this clear later on.
>
> > Do you know about the suggested way of forking given in cfgguide.tex?
>
> No.
>
> There is a texmf/doc/latex/base/cfgguide.dvi on my local machine. It
> contains a document with the title "Configuration options for LaTeX2e"
> dated 17 October 1998.
yes, that one.
> As the last section of that file there is a very brief example of
> how the last step of the "complex way" I described in my previous
> posting - namely how to get the renamed article.cls loaded while
> still allowing the user to define his own .cls files - could be
> carried out.
yes it explains a scenario for two of the five or so file types of LaTeX.
> > LaTeX only knows about a very small number of file types that are
> > "loadable via interfaces and by rewriting that example to cover the
> > three missing ones (only deals with .sty and .cls there) you have a
> > simple way to fork which consists of making a new kernel by adding
> > 20+ lines of code
>
> It's not simply a matter of rewriting the *example*. There is no
> \@cloextension hook to use, at least not in article.cls 1999/09/10
> v1.4a - the entire construction of the .clo file's name is hardcoded
> in the class file, so I'd still have to change the mechanism there,
> which cascades my name-change requirements up as I described in my
> previous posting.
well it is a matter of rewriting the example, though not trivially to cover
all possible case. The best solution is either to provide something like
\@cloextension inside the kernel, or to rewrite the LaTeX file parser to not
only recognise area path base and extension of a file name but to do something
about them. Now i wans't suggesting that this should be left to somebody who
wants to fork, I was suggesting that this example (being written in 1995) is
not general enough and would need to be updated by us to be completely
general.
> That is, unless I do something really gross like
>
> \let\orig@iinput\@iinput
> \def\@iinput#1{\def\reserved@a{#1}\def\reserved@b{size12.clo}%
> \ifx\reserved@a\reserved@b
> \def\reserved@a{mysize12.clo}%
> \fi
> \expandafter\orig@iinput\expandafter{\reserved@a}}
>
> which I still think is beyond the capabilities of the hypothetical
> forker who knows what he want to change in size12.clo.
well, not this way :-) but there is no disagreement ... for the discussion
assume that the example given there is general so all you have to do when you
want to fork is to copy it from the file apply it and make your own non-latex
format
> > of course that isn't the only way to fork it is one suggested way not a
> > requirement or anything.
>
> If there was a *general* way to do this kind of replacements, and
> not one that worked only for .cls and .sty files, I'd be inclined to
> be statisfied with that as a forking device.
that would be fine and that is what i was trying to say --- basically your
example made me understood that your description and code for it was
incomplete
> As you've pointed out, there are other and normally more desirable
> ways ways to achive modified behavior in "small" cases, but as long as
> the possibility to do an all-out fork is present, the rest is just
> extra bonus.
>
> > (which is documented and even referred to in the license)
>
> It seems that I'm referring to a wrong licence. I thought we were
> talking about the draft that C.M. Connelly posted in
> http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00007.html
> The character combination "cfgguide" does not appear in his posting.
> Do you have an URL reference to the license you're talking about?
sorry ...
LPPL 1.2 contained cfgguide in place of modguide in the paragraph starting
"We, the LaTeX3 Project, believe that the conditions below give you the
freedom to make and distribute modified versions of The Program ...
when discussing 1.3-draft on LATEX-L somebody suggested that we most certainly
meant modguide at this point (and me not thinking straight) just changed it
without further reflection. but modguide is only giving some rationale not
explaining how to do things (and is referred to in cfgguide) so i simply made
the wrong decision then.
so the 1.3-draft you seen indeed doesn't have it but it is already changed
back (and i remarked on that at some point in the whole discussion. not that i
really expect you to have noticed that.
> > it boils down to a simple change of a few numbers in the right file
>
> Yes, ideally. But as I've explained, the need to then change the name
> of that file cascades up the file-invocation chain until one reached
> the kernel.
well, not if all file types are mapped in the way outlined but not properly
done in cfgguide. agreed?
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: