Bug with type << .. >>?

Bug with type << .. >>?

[Aditya Mahajan]

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

Re: Bug with type << .. >>?

[Aditya Mahajan]

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?

Aditya

Re: Bug with type << .. >>?

[Hans Hagen]

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
-----------------------------------------------------------------

Re: Bug with type << .. >>?

[Hans Hagen]

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
-----------------------------------------------------------------

Re: Bug with type << .. >>?

[Aditya Mahajan]

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

Re: Bug with type << .. >>?

[Hans Hagen]

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
-----------------------------------------------------------------

Re: Bug with type << .. >>?

[Aditya Mahajan]

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

Re: Bug with type << .. >>?

[Hans Hagen]

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
-----------------------------------------------------------------

Re: Bug with type << .. >>?

[Taco Hoekwater]

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

Re: Bug with type << .. >>?

[Hans Hagen]

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
-----------------------------------------------------------------

Re: Bug with type << .. >>?

[Aditya Mahajan]

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