A little while ago I asked whether \doifmode and friends should have an \ignorespaces at the end. Hans Hagen answered "no" and after some reasoning (probably along the same lines as his) I agree with him. Thus one uses in a quite natural way: some text\doifmode{xyz}{ conditional text} following text doing nothing else than: some text conditional text following text. With regard to this it is understandable and correct that extra space is taken in the next construct: some text \doifmode{xyz}{ conditional text} following text. But it looks different to me when using the \startmode .. \stopmode pair. ---- some text. \startmode[xyz] some conditional text. \stopmode further text. In order to avoid here the extra space one has to code an extra % ---- some text. \startmode[xyz]% some conditional text. \stopmode further text. or (not preferred imho): ---- some text.% \startmode[xyz] I think this is error prone as it is al too easy to forget the %. The situation here differs from the \doifmode-case. I tend to believe that the fact that the \startmode[] .. \stopmode construct invites one to separate the statements with newlines (whitespace thus). Therefore I would ask if this plea for an \ignorespaces effect at the end of the \startmode[xyz] should be honored. Hans van der Meer
I made an example of the effect of this on \doifmode and \startmode. The example shows that the appearance of extra space in \doifmode follows a regular pattern. The startmode case differs in that respect because \startmode[condition-true] has the extra space but \startmode[condition-false] has not. In my view that is an unwanted anomaly. A little redefinition remedies that as can be seen in the example.
Am 14.10.2011 um 10:38 schrieb Meer, H. van der:
I made an example of the effect of this on \doifmode and \startmode. The example shows that the appearance of extra space in \doifmode follows a regular pattern. The startmode case differs in that respect because \startmode[condition-true] has the extra space but \startmode[condition-false] has not. In my view that is an unwanted anomaly. A little redefinition remedies that as can be seen in the example.
I wrote you already a few times that you can use the annotation module for this. The module serves also as replacement for the fixme module where it is necessary to take care that no extra spaces are added when the text is hidden. \usemodule[annotation] \defineannotation[fulltext] [alternative=text] \defineannotation[shorttext][alternative=none] \defineannotation[modetext] [alternative=command,command=\ModeText] \define[2]\ModeText {\doifelse{\placeannotationtitle}{off}{\removeunwantedspaces}{#2}} \starttext abc \fulltext {pqr} xyz abc \shorttext{pqr} xyz abc \fulltext [alternative=none]{pqr} xyz abc \shorttext[alternative=text]{pqr} xyz \blank abc \startfulltext pqr \stopfulltext xyz abc \startshorttext pqr \stopshorttext xyz abc \startfulltext [alternative=none] pqr \stopfulltext xyz abc \startshorttext[alternative=text] pqr \stopshorttext xyz \blank abc \modetext {pqr} xyz abc \modetext {on}{pqr} xyz abc \modetext{off}{pqr} xyz \blank abc \startmodetext pqr \stopmodetext xyz abc \startmodetext{on} pqr \stopmodetext xyz abc \startmodetext{off} pqr \stopmodetext xyz \stoptext Wolfgang
On 14 okt. 2011, at 11:26, Wolfgang Schuster wrote:
Am 14.10.2011 um 10:38 schrieb Meer, H. van der:
I made an example of the effect of this on \doifmode and \startmode. The example shows that the appearance of extra space in \doifmode follows a regular pattern. The startmode case differs in that respect because \startmode[condition-true] has the extra space but \startmode[condition-false] has not. In my view that is an unwanted anomaly. A little redefinition remedies that as can be seen in the example.
I wrote you already a few times that you can use the annotation module for this. The module serves also as replacement for the fixme module where it is necessary to take care that no extra spaces are added when the text is hidden.
Wolfgang, Thanks for your reply, but I find it takes a sidetrack and does not answer the question. Please let me explain. It might well be that the annotation module does something of the sort, but that is not my point. The mode-mechanism is explicitely given as a means to do conditional typesetting. If I may cite from the wiki: "Very often, you want to generate multiple versions of the same document: one version for printing and one for viewing on the screen, one version for students and one version for the instructor, and so on. .. Or you could use modes - the ConTeXt way of doing conditional processing" Well, that is exactly what I want to do and I fail to see why another module (like annotation) should be necessary. Therefore, please do not keep pointing me to something that in my opinion is not needed in this case and is already fully provided for in ConTeXt. When I am pointing out something that I think is an anomaly in the behaviour of ConTeXt or probably not intentional, it is not meant as criticizing. To the contrary, my intention is always to make a constructive contribution. Your reply however is not an answer to the question I brought forward. It might be that there are reasons for not changing ConTeXt in the manner I proposed on this issue. I can live with that, because I have no role in the development. But I think it is legitimate to ask why that decision is made. I am certain you will understand this. Hans van der Meer
On 14-10-2011 10:38, Meer, H. van der wrote:
I made an example of the effect of this on \doifmode and \startmode. The example shows that the appearance of extra space in \doifmode follows a regular pattern. The startmode case differs in that respect because \startmode[condition-true] has the extra space but \startmode[condition-false] has not. In my view that is an unwanted anomaly. A little redefinition remedies that as can be seen in the example.
it's all a side effect of how parses: spaces after a \cs are gobbled so any macro that looks ahead has to struggle with this and compromise you can consider using \startsetups xxx \stopsetups \doifmode{whatever}{\setups{xxx} inside setups all spaces and line endings are ignores (so an explicit one has to be \space) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (4)
-
Hans Hagen -
Hans van der Meer -
Meer, H. van der -
Wolfgang Schuster