Isn't \type<<..>> be supposed to be equivalent to \type{..} ? \title{some \type{thing} } works perfectly but \title{some \type<<thing>>} gives ! Missing } inserted. <inserted text> } <to be read again> \endgroup <argument> ...head \endgraf \fi \dostopattributes \dostopattributes \@@ko::normal ...box {\localheadsetup \noindent #2 }\fi \doplaceheadtext ...attributes \dostopattributes } }\fi \endheadplacement {#1... \dodododoconstructhead ...arking [#1\v!number ]{}} \writesection {#1}{-}{#4}\... l.3 \title{some \type<<thing>>} Is this a bug? Aditya
Aditya Mahajan wrote:
On Fri, 28 Jul 2006, Aditya Mahajan wrote:
Isn't \type<<..>> be supposed to be equivalent to \type{..} ?
\title{some \type{thing} }
works perfectly but
Actually this does not work as expected. The font does not change to monotype. Is that delebrate?
no, a bug 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 -----------------------------------------------------------------
Aditya Mahajan wrote:
On Fri, 28 Jul 2006, Aditya Mahajan wrote:
Isn't \type<<..>> be supposed to be equivalent to \type{..} ?
\title{some \type{thing} }
works perfectly but
Actually this does not work as expected. The font does not change to monotype. Is that delebrate?
rather nasty ... in setupcommonverbatim you will see: %\def\verbatimfont{\typingparameter\c!style\normalnoligatures\font}% being replaced by \def\verbatimfont{\dosetfontattribute{\currenttypingclass\currenttyping}\c!style\normalnoligatures\font}% now, font attributed are ignored in titles and such so we need \def\verbatimfont{\redoconvertfont\dosetfontattribute{\currenttypingclass\currenttyping}\c!style\normalnoligatures\font}% 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 Fri, 28 Jul 2006, Hans Hagen wrote:
Aditya Mahajan wrote:
On Fri, 28 Jul 2006, Aditya Mahajan wrote:
Isn't \type<<..>> be supposed to be equivalent to \type{..} ?
\title{some \type{thing} }
works perfectly but
Actually this does not work as expected. The font does not change to monotype. Is that delebrate?
rather nasty ...
in setupcommonverbatim you will see:
%\def\verbatimfont{\typingparameter\c!style\normalnoligatures\font}%
being replaced by
\def\verbatimfont{\dosetfontattribute{\currenttypingclass\currenttyping}\c!style\normalnoligatures\font}%
now, font attributed are ignored in titles and such so we need
\def\verbatimfont{\redoconvertfont\dosetfontattribute{\currenttypingclass\currenttyping}\c!style\normalnoligatures\font}%
Thanks. This works correctly. Aditya
Aditya Mahajan wrote:
Isn't \type<<..>> be supposed to be equivalent to \type{..} ?
\title{some \type{thing} }
works perfectly but
\title{some \type<<thing>>}
<< >> will not work in commands that get an argument because it is related to catcode changes we could use \scantokens if there was not this space-creeps-in-after \cs problem) 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 Fri, 28 Jul 2006, Hans Hagen wrote:
Aditya Mahajan wrote:
Isn't \type<<..>> be supposed to be equivalent to \type{..} ?
\title{some \type{thing} }
works perfectly but
\title{some \type<<thing>>}
<< >> will not work in commands that get an argument because it is related to catcode changes
Ah. Makes sense.
we could use \scantokens if there was not this space-creeps-in-after \cs problem)
Well, found a workaround. Not sure if this one is a bug or a feature (is a feature to me) \title{some \type{\thing\{and\}}} However, things get real weird. \title{\type{$\Pr\{A\}$}} gives me ! Extra }, or forgotten $. <recently read> } <argument> ...tofoneargument {\type {$\Pr \{A\}$}} \endstrut }\xdef \localhe... \@@ko::normal ...box {\localheadsetup \noindent #2 }\fi \doplaceheadtext ...attributes \dostopattributes } }\fi \endheadplacement {#1... \dodododoconstructhead ...arking [#1\v!number ]{}} \writesection {#1}{-}{#4}\... l.69 \title{\type{$\Pr\{A\}$}} which I think is the currect behaviour. There is really no need to change anything. I am happy with "Do not use \type inside argument. The unexpected can happen." Aditya
Aditya Mahajan wrote:
On Fri, 28 Jul 2006, Hans Hagen wrote:
Aditya Mahajan wrote:
Isn't \type<<..>> be supposed to be equivalent to \type{..} ?
\title{some \type{thing} }
works perfectly but
\title{some \type<<thing>>}
<< >> will not work in commands that get an argument because it is related to catcode changes
Ah. Makes sense.
we could use \scantokens if there was not this space-creeps-in-after \cs problem)
Well, found a workaround. Not sure if this one is a bug or a feature (is a feature to me)
\title{some \type{\thing\{and\}}}
However, things get real weird.
\title{\type{$\Pr\{A\}$}}
gives me
you can try: \title{\retype{$\Pr\{A\}$}} watch the space after \Pr Question for taco: can we make such spaces optionally disappear in future tex's? 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 -----------------------------------------------------------------
Hans Hagen wrote:
Question for taco: can we make such spaces optionally disappear in future tex's?
In most cases, yes. (but not always, because something like the internal form of "\aacute a" can not reliably be represented by adding extra tokens like in "\aacute{}a", for example) Taco
Taco Hoekwater wrote:
Hans Hagen wrote:
Question for taco: can we make such spaces optionally disappear in future tex's?
In most cases, yes.
(but not always, because something like the internal form of "\aacute a" can not reliably be represented by adding extra tokens like in "\aacute{}a", for example)
indeed, but it would already help if non-letters (i.e. the chars with catcodes not making up a \cs) would be taken care of \abc def -> not handled \abc{def} -> space omitted 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, 29 Jul 2006, Hans Hagen wrote:
Aditya Mahajan wrote:
On Fri, 28 Jul 2006, Hans Hagen wrote:
Aditya Mahajan wrote:
Isn't \type<<..>> be supposed to be equivalent to \type{..} ?
\title{some \type{thing} }
works perfectly but
\title{some \type<<thing>>}
<< >> will not work in commands that get an argument because it is related to catcode changes
Ah. Makes sense.
we could use \scantokens if there was not this space-creeps-in-after \cs problem)
Well, found a workaround. Not sure if this one is a bug or a feature (is a feature to me)
\title{some \type{\thing\{and\}}}
However, things get real weird.
\title{\type{$\Pr\{A\}$}}
gives me
you can try:
\title{\retype{$\Pr\{A\}$}}
watch the space after \Pr
Thanks for the hint. I also found out \startbuffer $\Pr\{A\}$ \stopbuffer \title{\typebuffer} which seems pretty robust. Aditya
participants (3)
-
Aditya Mahajan -
Hans Hagen -
Taco Hoekwater