|  |     The <define_symbol> and <define_book_name> tags do their work
    during pass 1 of the tag translator and are pretty much ignored
    during pass 2 of the tag translator.  Both tags store away the
    symbol and the associated text in a symbol table, so that when
    a <reference> to the symbol is encountered during pass 2, the
    text can be substituted for the reference.
    
    The problem lies in what happens to the text argument BEFORE
    it is stored in the symbol table.
    
    During both passes of the tag translator, EVERY tag is replaced
    with its "definition" FOR THAT PASS.  (Every tag has two definitions,
    one for pass 1 and one for pass 2.)  Some tags use the same 
    definition (that is, they do the same thing)
    in both passes, some do nothing in pass 1, some do only context
    checking in pass 1, etc.  Since there is no output file from pass
    1, we have not been super careful about what the "result" of each
    tag's pass 1 definition is (in terms of its replacement text). 
    
    What does this mean for <define_symbol>(symname\abc <p> def)?
    
    Well, during pass 1, we encounter the tag <define_symbol> and then
    we set out to gather its two arguments.  During the process of reading
    the second argument, "abc <p> def", we encounter that <p> tag and
    we stop to REPLACE IT with its pass 1 definition.  What is the pass
    1 definition of a <p> tag?  Beats me -- probably nothing.  Let's
    suppose for the sake of this argument, that it is nothing.  Then,
    the second argument shrinks to "abc  def".  So after we  hit the
    end of the argument list, we actually store the symbol and its text
    string in the symbol table.  The symbol is SYMNAME and the text
    string is "abc  def".  You can see what happens when that  symbol
    gets referenced; it retrieves a text string that lacks the <p> tag.
    
    This is an explanation of what happens -- not an excuse, or an
    argument that it ought to be this way.
    
    We (the DOCUMENT implementors) need to fix it, so that users get
    the functionality that they want.  And we intend to do that, along
    with all the other things that are vying for top priority for v1.1.
                                                                
    In the meantime, there is a restriction on what you can put in
    the second argument of a <define_symbol> or <define_book_name> tag.
    
      (By the way, I DO promise to read all the "solutions" that
       will probably be offered in ensuing replies to this topic.
       They may prove useful in designing the actual solution.
       But please don't expect me to debate the implementation...)
      
    bill
 |