LMTX problem with doifmode in \setuplayout
Hello all, Odd issue with LMTX (works fine with --luatex). \doifelsemode causes a failure if it is used to set a simple value such as on, off, yes, no, ..., but works with a dimension. Perhaps better illustrated by an example: \definemode [aaa] [keep] \setuplayout [ marking=\doifmodeelse{aaa}{off}{on}, % marking=on, grid=\doifmodeelse{aaa}{yes}{no}, % grid=yes, bottom=\doifmodeelse{aaa}{10mm}{20mm}, ] \starttext This is only a test. \stoptext The problem occurs whether or not the mode is enabled. In the example, it fails with the mode test in the either the marking= or grid= keys, but has no problem with it in the bottom= key. The error message says: The control sequence marked <to be read again> should not appear between \csname and \endcsname. pointing to the enabled \doifmodeelse line. The same issue occurs with the following, using \doifmode: \definemode [aaa] [keep] \setuplayout [ marking=on, marking=\doifmode{aaa}{off}, ] \starttext This is only a test. \stoptext This did work without complaint a few months ago. -- Rik Kabel
Rik Kabel schrieb am 08.06.2021 um 18:14:
Hello all,
Odd issue with LMTX (works fine with --luatex). \doifelsemode causes a failure if it is used to set a simple value such as on, off, yes, no, ..., but works with a dimension. Perhaps better illustrated by an example:
\definemode [aaa] [keep] \setuplayout [ marking=\doifmodeelse{aaa}{off}{on}, % marking=on, grid=\doifmodeelse{aaa}{yes}{no}, % grid=yes, bottom=\doifmodeelse{aaa}{10mm}{20mm}, ] \starttext This is only a test. \stoptext
The problem occurs whether or not the mode is enabled. In the example, it fails with the mode test in the either the marking= or grid= keys, but has no problem with it in the bottom= key.
The error message says:
The control sequence marked <to be read again> should not appear between \csname and \endcsname.
pointing to the enabled \doifmodeelse line.
The same issue occurs with the following, using \doifmode:
\definemode [aaa] [keep] \setuplayout [ marking=on, marking=\doifmode{aaa}{off}, ] \starttext This is only a test. \stoptext
This did work without complaint a few months ago.
You can never be sure if these combinations (\doifXXX within \setupXXX) work without problems. The only reliable method in this case is: % default setup \setuplayout [marking=on] % mode dependent setup \startmode[aaa] \setuplayout [marking=off] \stopmode Wolfgang
On 6/8/2021 10:11 PM, Wolfgang Schuster wrote:
Rik Kabel schrieb am 08.06.2021 um 18:14:
Hello all,
Odd issue with LMTX (works fine with --luatex). \doifelsemode causes a failure if it is used to set a simple value such as on, off, yes, no, ..., but works with a dimension. Perhaps better illustrated by an example:
\definemode [aaa] [keep] \setuplayout [ marking=\doifmodeelse{aaa}{off}{on}, % marking=on, grid=\doifmodeelse{aaa}{yes}{no}, % grid=yes, bottom=\doifmodeelse{aaa}{10mm}{20mm}, ] \starttext This is only a test. \stoptext
The problem occurs whether or not the mode is enabled. In the example, it fails with the mode test in the either the marking= or grid= keys, but has no problem with it in the bottom= key.
The error message says:
The control sequence marked <to be read again> should not appear between \csname and \endcsname.
pointing to the enabled \doifmodeelse line.
The same issue occurs with the following, using \doifmode:
\definemode [aaa] [keep] \setuplayout [ marking=on, marking=\doifmode{aaa}{off}, ] \starttext This is only a test. \stoptext
This did work without complaint a few months ago.
You can never be sure if these combinations (\doifXXX within \setupXXX) work without problems. The only reliable method in this case is:
% default setup
\setuplayout [marking=on]
% mode dependent setup
\startmode[aaa]
\setuplayout [marking=off]
\stopmode Indeed. I'll make the test more robust (not come up with an error) but as Wolfgang says, it won't work anyway because \doifmode is a protected macro.
There is actually a trick: \expand\doifmode{aaa}{on} will ignore the protection .. compare \edef\foo{\doifmode{aaa}{on}} [[\meaningless\foo]] \edef\foo{\expand\doifmode{aaa}{on}} [[\meaningless\foo]] only in luametatex/lmtx Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/8/2021 16:11, Wolfgang Schuster wrote:
Rik Kabel schrieb am 08.06.2021 um 18:14:
Hello all,
Odd issue with LMTX (works fine with --luatex). \doifelsemode causes a failure if it is used to set a simple value such as on, off, yes, no, ..., but works with a dimension. Perhaps better illustrated by an example:
\definemode [aaa] [keep] \setuplayout [ marking=\doifmodeelse{aaa}{off}{on}, % marking=on, grid=\doifmodeelse{aaa}{yes}{no}, % grid=yes, bottom=\doifmodeelse{aaa}{10mm}{20mm}, ] \starttext This is only a test. \stoptext
The problem occurs whether or not the mode is enabled. In the example, it fails with the mode test in the either the marking= or grid= keys, but has no problem with it in the bottom= key.
The error message says:
The control sequence marked <to be read again> should not appear between \csname and \endcsname.
pointing to the enabled \doifmodeelse line.
The same issue occurs with the following, using \doifmode:
\definemode [aaa] [keep] \setuplayout [ marking=on, marking=\doifmode{aaa}{off}, ] \starttext This is only a test. \stoptext
This did work without complaint a few months ago.
You can never be sure if these combinations (\doifXXX within \setupXXX) work without problems. The only reliable method in this case is:
% default setup
\setuplayout [marking=on]
% mode dependent setup
\startmode[aaa]
\setuplayout [marking=off]
\stopmode
Wolfgang
Yes, that works. Of course, to say that you can never be sure if such combinations will work is not a welcome statement about the state of ConTeXt. More recent LMTX releases also now break older documents that worked (with LMTX and MkIV) before. If there is an error in what was previously written that is only noticed because of tighter enforcement, that is one thing, but an undocumented change to supported behaviour is less to be desired. And that it works with dimensions but not on/off/yes/no is very strange and suggests some other problem may be lurking. -- Rik
Rik Kabel schrieb am 08.06.2021 um 23:01:
Yes, that works. Of course, to say that you can never be sure if such combinations will work is not a welcome statement about the state of ConTeXt.
More recent LMTX releases also now break older documents that worked (with LMTX and MkIV) before. If there is an error in what was previously written that is only noticed because of tighter enforcement, that is one thing, but an undocumented change to supported behaviour is less to be desired. And that it works with dimensions but not on/off/yes/no is very strange and suggests some other problem may be lurking.
Just because it did work doesn't mean it was intended to be used in this case. The different behavior between keywords and dimensions is a result of the different ways how the are implemented and the way TeX (the engine) works when it reads arguments. Wolfgang
On 6/8/2021 11:44 PM, Wolfgang Schuster wrote:
Rik Kabel schrieb am 08.06.2021 um 23:01:
Yes, that works. Of course, to say that you can never be sure if such combinations will work is not a welcome statement about the state of ConTeXt.
More recent LMTX releases also now break older documents that worked (with LMTX and MkIV) before. If there is an error in what was previously written that is only noticed because of tighter enforcement, that is one thing, but an undocumented change to supported behaviour is less to be desired. And that it works with dimensions but not on/off/yes/no is very strange and suggests some other problem may be lurking.
Just because it did work doesn't mean it was intended to be used in this case. The different behavior between keywords and dimensions is a result of the different ways how the are implemented and the way TeX (the engine) works when it reads arguments. and, also in mkiv \dofmode is unexpandable so cannot act as keyword (it might not crash but also doesn't work)
that's why wolfgangs suggested \startmode solution is the way to go (also in the past) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen schrieb am 09.06.2021 um 00:08:
On 6/8/2021 11:44 PM, Wolfgang Schuster wrote:
Rik Kabel schrieb am 08.06.2021 um 23:01:
Yes, that works. Of course, to say that you can never be sure if such combinations will work is not a welcome statement about the state of ConTeXt.
More recent LMTX releases also now break older documents that worked (with LMTX and MkIV) before. If there is an error in what was previously written that is only noticed because of tighter enforcement, that is one thing, but an undocumented change to supported behaviour is less to be desired. And that it works with dimensions but not on/off/yes/no is very strange and suggests some other problem may be lurking.
Just because it did work doesn't mean it was intended to be used in this case. The different behavior between keywords and dimensions is a result of the different ways how the are implemented and the way TeX (the engine) works when it reads arguments. and, also in mkiv \dofmode is unexpandable so cannot act as keyword (it might not crash but also doesn't work)
Here is a short example which demonstrates the differences between LuaTeX (eTeX, pdfTeX etc.) and LuaMetaTeX. \starttext \def\one{first} \def\two{second} \def\foo{one} \protected\def\bar{two} \csname\foo\endcsname \csname\bar\endcsname \stoptext Wolfgang
participants (3)
-
Hans Hagen -
Rik Kabel -
Wolfgang Schuster