Conference vaxuum::document_ft

    
    Most diagnostics for things like missing <ENDxxx> tags that occur
    at <headn> tags do try to reset the context and go on. The 
    tags that can't do this, which are of a fatal nature, are those
    in which an argument list to a tag isn't terminated. Since they
    are fatal and processing stops immediately, a <reset> wouldn't do
    any good.
    
    I would need to know what types of errors are those that once you
    correct them you get others. Are they the fatal type?
    
    patti

re: 189.1

This is an old problem with programming languages, i.e. you make a typo
which causes either something to be undefined or have changed semantics and 
later find "new" errors after correcting the earlier errors.

It is unreasonable to expect a compiler (or application like DOCUMENT which has
similar parsing issues) to catch everything and a <reset> escape doesn't buy
you much, if anything.



$SET OFF THE TRACK

Famous example of a typo:

Leaving out the comma in a FORTRAN DO, say, DO 10 I  = 1, 20,
causes it to become a simple assignment statement as DO10I = 120.
This scuttled a space shot by NASA some years ago.

$RETURN

    Yes, I guess I'm talking about the "fatal" ones.  At least, the
    tag processor seems to keep giving up on me a lot.
    
    <RESET> would, in effect, say "Pretend this is the start of the
    file if you're hopelessly confused and don't know where you are."
    It would most definitely NOT give you a file that could be processed
    to produce anything printable, but it would allow the tag processor
    to pick up the pieces and keep going, sort of.

re: 189.3

Yes, but all sorts of things would become undefined, e.g. nesting of lists,
heads, etc.

   Re: .4
    As I said in my base note (I think), you could only put in a <RESET>
    at points where nothing was nested.  It wouldn't totally solve the
    problems, but it would allow more complete error reporting than
    is available in some cases now...oh, forget it.  Nobody else seems to
    see the point, and it's not my job to solve your problems anyway.

    Plenty of people see your point, we just disagree.
    
    If you really have that much call for this kind of function, how
    about breaking up your source into several files you can compile
    separately and then include in a master file?  Or how about throwing
    comment..endcomment around the offending part and trying again?
    
    The <RESET> solution would *hide* problems of things later in the
    document that conflict with things earlier, like <FRONT_MATTER>
    ... <RESET><FRONT_MATTER>, and while it would tell you more about
    some kinds of errors, it would tell you less about others.
    
    Do you use LSE?  With it you can run the tag translator while still
    in the editor, read your error messages, and edit the source to
    fix (or disable) the offending passages.  This would give you
    interactively a kind of "reset" capability without leaving the editor.
    
    Thanks for voicing your opinions here.  You have brought forth some
    interesting points.
    
    Mark

    I agree with Mark (that's strange -- we've been of differing opinions
    lately).  I have been trying to figure out what a <reset> tag
    could do and how it would do it.  It seems that there are so
    many "things going on" or potentially so many things going on
    at any point in the processing that encountering a <reset>
    would just raise the question of WHAT to reset.  And once you
    decide to reset anything, when you encounter an "end condition"
    for the thing that was reset, you now have a new kind of
    error.  Is this truly an "extra" end condition or is it an
    end for something that was ended earlier by the <reset>?
    
    As Mark says, the error messages that you get will be different
    but they may not be any more helpful, and in fact may be misleading.
    
    It is not that we don't appreciate the problem, it is just that
    we don't think a <reset> is going to do anything useful.
    
    The nature of a markup language is that it is very structured,
    layered, hierarchical, nested, whatever.  That is also true of the
    better programming languages.  It used to be that Pascal compilers
    simply told you at the end of the source that you had too many or
    too few "end" keywords.  The VAX PASCAL compiler detects the missing
    end much sooner and generally points you at the "begin" that it
    was attempting to match with an "end" when it discovered that it
    must be missing.
    
    Much of the checking code that Patti has added in the last few
    months does exactly this same kind of thing.  It remembers where
    things start and then when the "end" appears to be missing it
    points you back at the starting tag and tells you that it was
    never ended.  The tag translator does the same thing, when it
    goes off looking for the end of an argument list.  If it hits the
    end of file it points you back at the tag whose arg list was
    never ended.
    
    There are plenty of places where this nesting goes on and we
    may not have caught all of them, so don't hesitate to point out
    situations in which we could have diagnosed errors in a better way.

    I guess I'm suggesting that <RESET> would perform the function you
    suggest I achieve by breaking the file into several pieces.  Seems
    to me it would be a lot easier to stick in (or remove) a few <RESET>
    tags than to break up, recombine, and otherwise keep track of, pieces
    of files.
    Putting comments around the error is no easier than going in and
    fixing the error; the problem is that in a discouraging number of
    cases, DOCUMENT tells me about only one or two errors at a time.
    I could put the entire chapter in a comment and get DOCUMENT to
    swallow it, I'm sure, but that wouldn't be very useful.
    
    No, I don't use LSE.  At the moment I'm doing .RNO file conversion,
    and that is just tedious selective editing.  I may be wrong, but
    my impression is that LSE is of no particular advantage in such
    situations.  Besides, I have neither the time nor the inclination
    to learn a new editor, and I do some of my editing on my office
    PDP-11, which doesn't have LSE anyway.

    Dispite all my raving, I must say that DOCUMENT's error reporting
    has gotten a LOT better since BL5 days.  I encourage you to keep
    working on it!

    Two things pointed out to me by local users:
    
    1. TAG checking within LSE is painfully slow - you're better off
    in batch!
    
    2. A <headn> tag effectively starts a new "context" - if a table
    is not ended by the time one of these tags is reached, you know
    there is a problem and where it is. Why not use such tags as
    equivalents to the <reset> requested? It would also have the advantage
    of being invisible to the user.
    
    Gavin

    Not to beat a dead horse, but I think the tag translator already
    does the kind of checking suggested in .-1.2.

    -tl