Hello,
\def\show{Hello World}
\pdfprimitive\show\relax
I would expect that the primitive \show (not the macro) is
executed and shows \relax. Instead I get an error (pdfTeX 1.40.3):
! Undefined control sequence.
l.2 \pdfprimitive\show
Did I misunderstood \pdfprimitive?
Yours sincerely
Heiko
On Fri, Apr 06, 2007 at 09:10:01AM +0200, Taco Hoekwater wrote:
Thanks.
BTW, is there a way to restore a primitive without having
a previously generated backup?
Example:
\def\show{something}% (e.g. ucsenc.def)
% Can something like
\expandafter\let\expandafter\show\pdfprimitive\show
% be used for restoring the meaning of \show?
% Or is the following the only way:
\def\show{\pdfprimitive\show}
Yours sincerely
Heiko
On Tue, Apr 10, 2007 at 12:46:03PM +0200, Taco Hoekwater wrote:
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
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
Philip & Le Khanh wrote:
We had a long discussion a few years back about the names for the non-tex, non-etex primitives. The consensus was that they should all be recognizable by having a unique prefix, that is when the \pdf.... naming convention started. (personally, I don't like it, but I was outvoted) Best, Taco
On Fri, Apr 06, 2007 at 12:44:11PM +0100, Philip & Le Khanh wrote:
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:
(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
"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... what will happen to the primitive names, then? 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 will be a mess of prefixed and non-prefixed names (i personally also don't like the prefix, but since it is already used, it should be retained in both pdftex and luatex). Best, v.
Vladimir Volovich wrote:
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.
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
"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. :) Best, v.
Vladimir Volovich wrote:
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 -----------------------------------------------------------------
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. 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. ** Phil. -------- Martin Schröder wrote:
On Sat, Apr 07, 2007 at 02:12:40PM +0100, Philip & Le Khanh wrote:
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.
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
� wrote:
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; only when a macro package uses \foo there could be a problem but that's seldom the user's concern 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 07:53:52PM +0200, Hans Hagen 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. ...
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
Heiko Oberdiek wrote:
\let\mynamespacedprimitive=\primitive \let\primitive\undefined
\pdfsomething can be in use as well, you never knw what users have defined 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 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 11:10:51PM +0200, Hans Hagen wrote:
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.
And calling for unnecessary trouble and bug reports.
Yours sincerely
Heiko
participants (6)
-
Hans Hagen -
Heiko Oberdiek -
Martin Schröder -
Philip & Le Khanh -
Taco Hoekwater -
Vladimir Volovich