Explanations with an EQN User Guide

[Damian McGuckin]

I am resurrecting my re-write of the EQN User Guide which was itself an 
elaboration of Ted Harding's User Guide. I have used many examples from 
BrianK's and LorindaC's original 2nd Edition EQN document because I wanted 
backwards continuity in the examples. Ted also addresses MM which I have 
also done.

I still need to chase up Nokia to sort out any copyright issues.

I also need to find Ted to get his permission because I like many of his 
explanations and examples.

In a section (which Ted did not address) entitled

        Adding Spaces to the Input

where I use 'eqn' (emboldened) to refer to the program and 'EQN' to refer 
to the language, and before which I have defined EQN delimiters, I say (to 
use my own words with the sloppy words removed):

        Luckily, eqn discards any spaces and newlines seen within an
        expression encapsulated within EQN delimiters. This means that
        any EQN mathematics can (and should) freely contain spaces and
        newlines to make that mathematics both easy to read and easy to
        edit.

        ... replicate example from Section 3 of the EQN document ...

        Rule: Very long lines in the input to eqn are to be avoided. They
        are a bad idea. They always reduce readability and can annoyingly
        hide hard-to-fix bugs.

Is that as tight as the original words by BrianK and LorindaC?

Hopefully those words are not considered copyright violations.

Now, what about tabs. The original 'eqn' documentation seemed to imply 
that tabs interacted with troff's tabs. I thought I used tabs as white 
space with impunity during the 80s but my memory might be bad.

The last time (2020) I tried to used tabs was when I was embedding them in 
EQN input that contains matrices. They caused total havoc to 'eqn' - I 
think it was release 1.22.3. Not sure. I stopped using them and problems 
went away.

Anyway, I now avoid tabs like the plague.

What should I say about them?

Thanks - Damian