Re: [Groff] nop request

[Werner LEMBERG]

> > >     Troff code looking like traditional troff code is an
> > >     important consideration if others are to easily read and
> > >     comprehend it.
> > 
> > Do you really believe what you've just written? :-) Nobody is
> > forced to use it.
> 
> I absolutely believe it.  I agree nobody is forced to use it.  But
> if you use it then I am forced to grok it to comprehend your code.
> It's like the bad old days of everyone having their own set of
> macros to make their assembler more comfortable.  Picking up someone
> else's code meant learning a new way of reading code all over again.

This is similar to the situation writing K&R C code vs. ANSI C...

> If you decide to use .eo and .ec in this way you're forcing me to
> struggle to read this abnormal code.

Abnormal?  I don't think so.  Using two slashes if you can do it with
one is abnormal for me.  Have you ever read the ChangeLog files in
Emacs, coping with incorrect regexp patterns (something like
\\\\\\\\\\\\\\\\\\\*\\\\\\\\\\\\\\\+\\\\\\\\\\\\\\\\-, to exaggerate a
bit)?

> > BTW, I'll soon commit a new version of tmac.doc which is *readable*
> > for normal people :-)
> 
> Do you mean normal people that are used to reading troff?  If
> they're not used to reading troff at all then isn't it better that
> they learn the normal way and can then choose to deviate once they
> have a good understanding?

Well, I'm going to maintain the new code, so I want to write it the
way it is best for me.  Maybe this is egoistic, but it is easy to
remove the three .ec and .eo commands and double all backslashes
(except four only!) to get a `conventional' appearance.  I invite you
to provide a small sed script to do the conversion.

tmac.doc is a large package (my rewritten code is about 110kByte with
4800 lines).  Some statistics about occurrence of some patterns: `\n':
1230 times, `\$': 564 times, `\*': 504 times.  Not doubling saves more
than 2kByte of code.  It also makes reading the code faster into groff
(well, it is not significant).

> > Compare this
> > 
> > .de bU
> > .nr oM \\n(oM+1
> > .ds b1 \&\\*(sY\&\(bu\fP
> > .uL
> > ..
> > 
> > to this:
> > 
> > .eo
> > .
> > .de doc-bullet-list
> > .  nr doc-nesting-level +1
> > .  ds doc-out-string \&\*[doc-Sy-font]\&\[bu]\f[P]
> > .  doc-do-list
> > ..
> > .
> > .ec
> 
> That's completely unfair.

:-)  A very British attitude...

> Re-write the `after' making use of just the .eo feature lessening
> the number of backslashes.  Don't make use of all those other things
> to make it more readable.

I've given the example of how the new code will look like.  It wasn't
meant to emphasize the avoidance of double-backslashes.

> ..., if you think backslash is the de facto escape character then
> why worry so much about tmac.trace having to cope with another one?
> Is it really worth extending the language just for that small use?
> Does it not seem like feeping creaturism?

My highest ideal is to be generic.  I prefer TeX to almost everything
else because it is available on virtually any platform.  The same is
true for groff.  Using `\' is just a convention.  I can imagine that
people don't want to use groff in a traditional way for some specific
purpose.  Why shall we disallow this?  Additionally, my greatest
concern is not using another escape character but to disable the
escape mechanism to write code in a fashion which I believe is easier
to understand.

> > For TeX, I use a comparable trick to avoid the error-prone `%' at the
> > end of a line to suppress the insertion of whitespace:
> 
> If this is a widely held convention then it isn't a problem.  (I've
> read _The TeX Book_ and _TeX: The Program_ but have otherwise
> managed to avoid it.)  If it isn't then other readers of your code
> have to bear in mind the \endlinechar that occurred a while earlier.

The LaTeX team use it consistently for the forthcoming LaTeX 3, as
Frank Mittelbach told me.

> Sorry to have a go, but when you are writing code that gets released
> and isn't just for you to read I think you have to bear in mind the
> conventions that other readers of that code will be expecting.

I always thought that I'm a conservative person, but you are
apparently even more conservative.  Note that the interface of mdoc
won't be touched (except removing some annoying limitations like the
9-argument barrier, and other minor fixes).


    Werner