Conference vaxuum::document_ft

Well, I just found some other cases of slash character sensitivity.
In this case, the sensitivity was the exact opposite of what was noted 
in .0 for <table_setup>.  It occurred in the context of <table_row>, but
I'm not sure that <table_row> was at fault; it might have something to 
do with <tag>.

This gets a little confusing, so bear with me while I try to explain 
accurately what is happening.

The following code results in the error message "End of file encountered 
while searching for closing parenthesis.  See argument list of tag 
<UNDEFINE>..."

    <table_row>(<tag>(appendix) (number\title\symbol_name) )

Changing "\" to "/" solves the problem.

This is a good place to also note that <tag> does not behave as 
documented.  Supplying a single argument to a tag name results in
expected output: 

<tag>(appendix\title) ---> <APPENDIX>(title)

Supply more than one argument, and the whole thing is output like one 
long tag name:

<tag>(appendix/number/title/symbol_name) ---> <APPENDIX/TITLE/SYMBOL_NAME>

In this last case, code the slash as "\" in the context of 
<table_row> and you won't get any output for that row, though you will 
get the error "more than 3 arguments supplied". 

If that isn't bad enough, shorten the code to two arguments, and you can
again code the slash either way.  But depending on the direction of the 
slash you will get different output:

<tag>(appendix\number\title) ---> <APPENDIX>(NUMBER\TITLE)
<tag>(appendix/number/title) ---> <APPENDIX/NUMBER/TITLE)

I tested this in a variety of ways but I probably haven't found every 
possible strange case.  The test table I used follows.  I was making 
overheads for a class to show differences between BL06 and BL07.  When I 
ran into problems with it, I isolated the table into a test file, 
deleting the second column of information where the BL07 syntax would 
be.  I processed it for terminal output with GENERAL doctype.  

This is really weird.  It's even weirder I'd be here on a Sunday amusing 
myself with weird things like this.


Rose

<table>(Tags With Changed Arguments\changed_arguments_tbl)
<table_attributes>(wide)
<table_setup>(2\20)
<table_row>(<tag>(align_char\argument)\Equal sign and underscore no 
longer valid arguments (=  and  __) )
<p>
<table_row>(<tag>(appendix\number\title) )
<table_row>(<tag>(appendix/number/title) )
<table_row>(<tag>(chapter/number/title/symbol_name) )
<table_row>(<tag>(chapter\number\title\symbol_name) )
<table_row>(<tag>(chapter/number/title) )
<endtable>

The slash ("/") character and the backslash character ("\") are certainly
 "sensitive to their directions" because they're completely different char-
  acters.  The backslash is used as an argument separator.  The slash is
   treated like any other text.  Bear that in mind and all your results
    make sense.
     <_Jym_>

    But aren't there lots of places where "/" is used as a sub-parameter
    separator (like in a title string for an overhead)?
    
    jack

    Unless you're really playing around with the innards of SDML, the "\"
    character is the only argument separator. 
    
    My documentation of the <title>(line-1\line-2\line-3) tag in the
    overhead doctype shows "\" as the delimiter.
    
    kh

RE: .2 

>>> The backslash is used as an argument separator.  The slash is
   treated like any other text.  Bear that in mind and all your results
    make sense.
     <_Jym_>


Well, I'd agree with you *except* that using "\" resulted in *no* output 
for "<tag>" in this case:

This is test.
<tag>(appendix\number\title\symbol_name)
This is the end of the test.

This may have nothing to do with the direction of the slash; it may be 
due to the fact that I supplied 4 arguments total instead of 3.  If the 
latter is true, it out to be documented somewhere or it ought to at 
least appear in some form in final output; the error message 
"more than 3 arguments supplied" doesn't imply no final output will be 
produced for the affected line.  The lack of output could be easily 
overlooked.

Wrapping all this up, it's confusing that in many cases "/" will be 
accepted and processed just fine, but now and again you'll get a 
"gotcha".  While "\" is documented in every case, I don't recall seeing 
a note anywhere that said "/" causes funny things to happen some of the 
time.  I know better now, but I would have liked knowing better earlier.

Thought food: is it desirable to allow "/" or "\" as argument 
delimiters, and simply provide a special treatment for "/"?  I see this 
as a user-friendly feature, and admittedly so because of my own 
recent experience and because I often interchange using the two.  I can 
retrain myself to use only "\"; I don't mind.



Rose

Apparently backslash is always interpreted as a delimiter, regardless of 
context?

Consider the code below, taken from a 2-column table.
Tcompare it with the output shown below it; everything after "numbered\"
is lost.  Reversing the slash fixes it, but at the expense of showing
incorrect syntax based on .2 reply to this note. 

Is there a better way to get the desired output, correct syntax and all?
Must I use <literal>, which seems cumbersome to me considering the rather 
simple output I want?


<table_row>(<tag>(ulist), <tag>(nlist), etc.\<tag>(list\argument)
  <line> alphabetic/[attributes]
  <line> callout
  <line> numbered\[attributes]
  <line> roman
  <line> simple
  <line> stacked
  <line> unnumbered\[attributes] )



           <ULIST>, <NLIST>, etc.           <LIST>(ARGUMENT)
                                           alphabetic/[attributes]
                                           callout
                                           numbered

    
    A slash is always treated as a character in the input file. 
    
    A backslash is given special treatment inside arguments to tags,
    where it is always used as the argument separator.
    
    In <table_row>(some stuff\some more stuff
              line\[attributes]
              more stuff)
    
    everything after the second backslash is ignored in a two-column
    table because the tag translator is treating everything following
    it as an argument, and a 2-column table only uses arguments 1 and
    2. 
    
    The only thing that is inconsistent here is that the <table_row>
    tag doesn't check whether the number of arguments matches the 
    number specified in <table_setup>. I thought this was a convenience,
    so that extra table rows could be 'hidden' in some contexts and
    revealed simply by changing the <table_setup> tag.
    
    patti
    

    The GTMAXARGS and LTMINARGS messages are warning level
    messages, but we "dump" the tag if we issue them.
    Looks like we should either continue to process the tag,
    or we should make these messages be "Error" level messages.
    
    We are inconsistent, since other Warning level messages
    do not stop the processing on the tag that causes the message
    to be issued.
    
    I will change these message to "Error" severity level.
    
    bill

> [I]s it desirable to allow "/" or "\" as argument delimiters[?]

The "\" is used very rarely in normal text.  The "/" is found here and/or there.
 Most text processors try to use characters that one wouldn't find in normal
  text.  DSR/RUNOFF uses a dot in the first column.  SCRIBE uses @ signs.  TeX
   uses backslashes ("\") and curly braces ("{}").  DOCUMENT uses backslashes
    and angle-brackets ("<>").

(DOCUMENT also uses parentheses ("()"), which poses a slight problem for people
 who like to use parentheses a lot (they know who they are (but I'm not naming
  names (defun foo))), but these people somehow manage anyhow.)
   <_Jym_>

Thanx for bearing with me on this note.  In the big picture, learning to handle
slash and backslash are a matter of good toilet training; remembering
to use <backslash> if I want it literal.  The DOCUMENT inconsistencies are not
as unnerving to me as the inconsistency of results for coding 
inconsistently.  That's a mouthful, but I think you get my drift.


Thanx again.  You're all doing a great job.  


Rose

Do you really want to make those errors of E severity?  I'd prefer them
to remain as W errors so I can get through more of the document and
see what else I want to fix.  Please only change them to E if the tag
translator can't be convinced to not dump the tag.

-tl

    E level errors don't stop processing within the tag translator.
    It will continue to the end of the pass in which the E error
    shows up (Pass 1 in this case.)  Then it quits, because E errors
    generally mean that we can't guarantee that we can produce a
    .TEX file that will make TeX behave.
    
    Many of the tag definitions depend on the fact that the tag
    translator is "screening" the tag for a proper number of args.
    If the tag translator sees the wrong number of arguments and then
    tries to "fake it" by supplying null arguments (if too low) or
    discarding excess arguments (if too high), we'll probably end
    up issuing other, more obscure error messages.