[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxuum::document_ft

Title:DOCUMENT T1.0
Notice:**New notesfile (DOCUMENT.NOTE) now available (see note 897)**
Moderator:CLOSET::ADLER
Created:Mon Feb 09 1987
Last Modified:Thu Oct 31 1991
Last Successful Update:Fri Jun 06 1997
Number of topics:897
Total number of notes:4397

604.0. "<define>s need more power" by COOKIE::JOHNSTON () Tue Jul 07 1987 14:01

DOCUMENT is inconsistent about tags that it will and won't allow within the
context of <define_symbol> and <define_book_name>. 

This, for example, is ok, producing bold italics in the output:

<define_book_name>(<emphasis>(Charly And Her Chocolate-Macademia Nut 
Factory\bold))


But this is not legal, dropping the mu character, without warning, in final
output: 

<define_book_name>(The <mcs>(micro)Processor Of The Future)

I'm sure there are other cases.  What happens, for example, if you try a list 
within <define_symbol>?  Or <math>?  I think these are reasonable cases, where 
users want to define some standard text that requires some special treatment.

What's the expected behavior in V1?

Will there be improvements in V1 or later?


Thanx

Rose

T.RTitleUserPersonal
Name
DateLines
604.1How it works (for V1.0)VAXUUM::KOHLBRENNERThu Jul 23 1987 14:5749
    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