Heiko Oberdiek wrote:

...

...

! Undefined control sequence. l.2 \pdfprimitive\show

Did I misunderstood \pdfprimitive? No, that should have worked. I will investigate.

Thanks.

I am an idiot. I was testing \pdfprimitive itself for expandability, instead of its argument. There is a very small patch possible, but I had better do some more tests before submitting it. Taco

On Tue, Apr 10, 2007 at 12:46:03PM +0200, Taco Hoekwater wrote:

...

I was testing \pdfprimitive itself for expandability, instead of its argument. There is a very small patch possible, but I had better do some more tests before submitting it.

Patch attached.

Thanks. As nearest way to restore a primitive that is redefined somewhere I found: \def\show{...}% some package \let\show\relax % prevents expansion if \show is expanded \def\show{\pdfprimitive\show} However \show remains a macro. Thus some kind of \pdfprimitivelet would be nice and complete the interface. Yours sincerely Heiko --

On Tue, Apr 10, 2007 at 02:00:00PM +0200, Heiko Oberdiek wrote:

As nearest way to restore a primitive that is redefined somewhere I found:

\def\show{...}% some package

\let\show\relax % prevents expansion if \show is expanded \def\show{\pdfprimitive\show}

I forgot e-TeX: \protected\def\show{\pdfprimitive\show} Yours sincerely Heiko --

As an aside, if I understand the function of \pdfprimitive correctly (that is, it allows access to a primitive whose name has been stolen), then it is (IMHO) singularly ill-named, in that it allows access to /all/ primitives (e.g., \show) rather than just PDF primitives ... If this is the case, is there any chance of a better choice of name in a future release ? ** Phil

On Fri, Apr 06, 2007 at 12:44:11PM +0100, Philip & Le Khanh wrote:

As an aside, if I understand the function of \pdfprimitive correctly (that is, it allows access to a primitive whose name has been stolen), then it is (IMHO) singularly ill-named, in that it allows access to /all/ primitives (e.g., \show) rather than just PDF primitives ... If this is the case, is there any chance of a better choice of name in a future release ?

The prefix \pdf does not mean PDF mode. It marks a primitive that adds a new feature, introduced by pdfTeX. (It's shorter than \pdftex). Rationale: A new primitive name can and will probably collide with some existing macro name. It's impossible to get and check all existing macro names. Thus each macro code provider would be forced to check new pdfTeX versions for collisions with new primitives to infinity. That's also impossible, because many packages have lost their maintainers. As long as we don't have real namespaces, the prefix method simulates a namespace. A macro code provider who just avoids names starting with \pdf is then out of trouble if new primitives are added. Yours sincerely Heiko --

Martin Schröder wrote:

2007/4/6, Philip & Le Khanh :

...

rather than just PDF primitives ... If this is the case, is there any chance of a better choice of name in a future release ?

Would you prefer a pdfTeX version that suddenly has a primitive \foo thus potentially breaking all documents already providing \foo ? :-)

(We've been over this, I am just reiterating my viewpoint here) Having \foo does not prevent \def\foo{} at all. It prevents \newcommand\foo, but \pdffoo prevents \newcommand\pdffoo, and depending on the purpose of a macro package, that can be just as bad. The LaTeX macro was written on the assumption that the engine would never, ever change. That assumption is faulty today and has been for quite a few years now, so I don't buy that we should cater for it in the executable. In LuaTeX I will follow the eTeX paradigm, and this particular command will be called \primitive. Only PDF-related commands will have a \pdf prefix. In any case, people that don't like new features can always stick to an old(er) version of (pdf)TeX, without developments taking place. Best wishes, Taco

Vladimir Volovich wrote:

"TH" == Taco Hoekwater writes:

TH> In LuaTeX I will follow the eTeX paradigm, and this particular TH> command will be called \primitive. Only PDF-related commands will TH> have a \pdf prefix.

and LuaTeX later is going to be merged into pdftex...

Not merged so much as superceded. There is a traditional pdftex 1.50 yet to come, and that will be around (and bugfixed) forever. LuaTeX's executable will continue to be named luatex, but it will internally present itself as \pdftexversion = 2 (as well as other version identifiers). General policy note: I feel free to make some changes that break compatibility on both the input and the output side, because the major version number (as well as the executable name) will be changed. If I did not have that liberty, lots of things would simply not be doable. I have already removed a few of the most recent extension primitives, because the functionality can better be handled by lua scripting. Think of \pdfelapsedtime and \pdffilesize. The syntax of the \font primitive in luatex has also changed, it now accepts a brace group as 'font identifier'. Without that change, I would have had to invent a completely new way of specifying fonts, and that would have been enormously confusing to both users and macro programmers. Luatex is *not* going to be identical to pdftex 1.xx. It will be as compatible as is reasonable, but such compatibility is not the first goal. The top spot is reserved for creating new functionality. The second spot is for creating a clean base for even more development. Compatibility comes somewhere below that. People that want 100% pdftex, should stick with pdftex.

if you will have renamed most of them (with stripped "pdf" at the beginning), it will create another messy situation.

so it seems safer to stick to the already used names, otherwise there

I will consider creating aliases, but since that can just as easily be done by a macro package (using \protected\def), it is not very high on my todo list. Looking back on how LaTeX has handled new engines in the past, it is a very safe bet to assume that a \usepackage{luatex} or a separate 'corona.fmt' will be required to make use of the new features, anyway. Best wishes, Taco

Vladimir Volovich wrote:

"TH" == Taco Hoekwater writes:

TH> Luatex is *not* going to be identical to pdftex 1.xx. It will be TH> as compatible as is reasonable, but such compatibility is not the TH> first goal.

but you mentioned that you plan to rename lots of existing non-PDF-related primitives by stripping the "pdf" prefix; this would merely create problem for macro-package writers... and it doesn't sound like it couldn't be avoided; on the other hand, avoiding renaming of existing primitives sounds like a reasonable way to improve compatibility. :)

we use luatex to clean up some of the mess that crept in; it makes no sense to carry around this burden forever; as taco said: pdftex will be around forever, and for straightforward open type support xetex is also an option also, in order to support luatex beyond its 'compatibility with pdftex 1.* level' macro packages need to be adapted substantially anyway; if this is no option, pdftex is a good alternative Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On Sat, Apr 07, 2007 at 02:12:40PM +0100, Philip & Le Khanh wrote:

Yes, that was the decision we took with e-TeX, and I do not think that with the benefit of hindsight the decision was a mistaken one. All you are doing by using a "pdf" prefix is /reducing/ the chances of a namespace clash, not eliminating the possibility.

No, it's more, it avoids future name clashes: If a macro author avoids the name space of macro names starting with the "pdf" prefix, then he is not bothered by new primitives. Of course it does not prevent conflicts with old macro code. Hyperref's \pdfbookmark is a prominent example. Luckily pdfTeX named its primitive \pdfoutline.

But I am not against the idea of a prefix per se; I am more concerned that the choice of "pdf" as the prefix for functionality that has nothing to do with PDF can only mislead the innocent user.

Also keep in mind, that names consisting of words, not protected by prefixes or special characters ("@" in LaTeX) interfere with user land macro names. Primitives are seldom intended to be used in user land directly. Most are hidden inside higher level markup macros (LaTeX, ConTeXt, ...). If an "innocent" user deals with these primitives directly, he left his "innocence". Some time ago there was also a discussion about prefix names. The costs for a new prefix for stuff that is useful also for DVI mode are high: * Inconsistency if some macros have the new prefix, others not. And the "cosmetic" naming problem remains. * Or severe compatibility problems, if primitives are renamed that exist for a long time. Yours sincerely Heiko --

On Sat, Apr 07, 2007 at 07:53:52PM +0200, Hans Hagen wrote:

??? wrote:

...

2007/4/6, Philip & Le Khanh :

...

rather than just PDF primitives ... If this is the case, is there any chance of a better choice of name in a future release ?

Would you prefer a pdfTeX version that suddenly has a primitive \foo thus potentially breaking all documents already providing \foo ? :-)

if a document provides \foo, then a nw primitive \foo is never seen because the document obscures it; actually, the user won't even notice;

If the document uses \newcommand, then the user will get an error. If the user uses a package that uses the new foo, this package will probably break. ...

only when a macro package uses \foo there could be a problem but that's seldom the user's concern

Some will generate bug reports that could have been avoided in the first place. Yours sincerely Heiko --

On Sat, Apr 07, 2007 at 11:10:51PM +0200, Hans Hagen wrote:

Heiko Oberdiek wrote:

...

If the document uses \newcommand, then the user will get an error. If the user uses a package that uses the new foo, this package will probably break. ...

\let\mynamespacedprimitive=\primitive \let\primitive\undefined

And the package that wants to use \primitive? A command name cannot be defined and undefined at the same time.

\pdfsomething can be in use as well, you never knw what users have defined

Yes, but it can be considered as reserved namespace. Thus if someone writes a package using \pdfsomething and pdfTeX later introduces a new primitive \pdfsomething, the package author cannot complain.

when etex came around \protected and \unexpanded were examples of a command that had a great potential for clashes (context had both already defined but i just use saved meanings then); such is live, such is progress

And calling for unnecessary trouble and bug reports. Yours sincerely Heiko --