Re: Colliding identifiers in MP.W

luigi scarso <[email protected]> Tue, 3 Feb 2026 17:12:01 +0100
Newsgroups gmane.comp.tex.metapost
Message-ID <CAG5iGsAkfmkfcnahoOs46bmpe3g77W5SWCNt5uw7HbA9G7bGig@mail.gmail.com>
--===============8062570109634406113==
Content-Type: multipart/alternative; boundary="000000000000c85d760649edb392"

--000000000000c85d760649edb392
Content-Type: text/plain; charset="UTF-8"

On Tue, 3 Feb 2026 at 16:53, Andreas Scherer <[email protected]> wrote:

> Am 10.05.24 um 17:12 schrieb Andreas Scherer:
> > CWEB source file MP.W _exports_ 'enum mp_color_model' to MPLIB.H in
> > section [205], but _uses_ macro '@d mp_color_model' from section [462]
> > internally. [Section numbers corrected for MetaPost 3.0a.]
> While C doesn't have a problem with this situation (the functional macro
> never overwrites the enum type), CWEB can't cope with the two competing
> identifiers. The 'enum mp_color_model' always is typeset in bold and its
> 'ilk' can not be reset, so the macro '#define mp_color_model(A)...' also
> is typeset in bold instead of in italics.
>
> By applying a CWEB coding trick (aka 'kludge'), we can hide the 'enum'
> from the CWEAVE parser, so the secondary 'macro' gets treated correctly.
> With some additional CWEB formatting and an extra index entry, the two
> separate items appear side by side in the index. Only the macro is used
> in multiple sections, the 'enum' is never used per se.
>
> Attached is a small patch that I apply in the larger 'mp.ch' in
> https://github.com/ascherer/mplibdir and later in the 'knuth-pdf' package.
>
> Case closed,
> Andreas--
> http://tug.org/metapost/



 I'm not sure if I can apply the patch for TL 2026, and if it doesn't,
please remind me after TeXLive is released, because I will definitely apply
it (and maybe others too from your github repo).

--
luigi

--000000000000c85d760649edb392
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 3 Feb 2=
026 at 16:53, Andreas Scherer &lt;<a href=3D"mailto:[email protected]"=
>[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">Am 10.05.24 um 17:12 schrieb Andreas Scherer:<br>
&gt; CWEB source file MP.W _exports_ &#39;enum mp_color_model&#39; to MPLIB=
.H in <br>
&gt; section [205], but _uses_ macro &#39;@d mp_color_model&#39; from secti=
on [462] <br>
&gt; internally. [Section numbers corrected for MetaPost 3.0a.]<br>
While C doesn&#39;t have a problem with this situation (the functional macr=
o <br>
never overwrites the enum type), CWEB can&#39;t cope with the two competing=
 <br>
identifiers. The &#39;enum mp_color_model&#39; always is typeset in bold an=
d its <br>
&#39;ilk&#39; can not be reset, so the macro &#39;#define mp_color_model(A)=
...&#39; also <br>
is typeset in bold instead of in italics.<br>
<br>
By applying a CWEB coding trick (aka &#39;kludge&#39;), we can hide the &#3=
9;enum&#39; <br>
from the CWEAVE parser, so the secondary &#39;macro&#39; gets treated corre=
ctly. <br>
With some additional CWEB formatting and an extra index entry, the two <br>
separate items appear side by side in the index. Only the macro is used <br=
>
in multiple sections, the &#39;enum&#39; is never used per se.<br>
<br>
Attached is a small patch that I apply in the larger &#39;<a href=3D"http:/=
/mp.ch" rel=3D"noreferrer" target=3D"_blank">mp.ch</a>&#39; in <br>
<a href=3D"https://github.com/ascherer/mplibdir" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/ascherer/mplibdir</a> and later in the &#39;=
knuth-pdf&#39; package.<br>
<br>
Case closed,<br>
Andreas--<br>
<a href=3D"http://tug.org/metapost/" rel=3D"noreferrer" target=3D"_blank">h=
ttp://tug.org/metapost/</a></blockquote><div><br></div><div><br></div><div>=
=C2=A0I&#39;m not sure if I can apply the patch for TL 2026, and if it does=
n&#39;t,=C2=A0</div><div>please remind me after TeXLive is released, becaus=
e I will definitely apply it (and maybe others too from your github repo).<=
/div><div><br></div><div>--</div><div>luigi</div></div></div>

--000000000000c85d760649edb392--

--===============8062570109634406113==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
http://tug.org/metapost/

--===============8062570109634406113==--