groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] nop request


From: Ralph Corderoy
Subject: Re: [Groff] nop request
Date: Mon, 18 Sep 2000 16:24:38 +0100

Hi Werner,

> > OK, I've no objection to ecs and ecr being added.  Although, it
> > seems that they are necessary only because
> >
> >     .eo and .ec are being used around definitions.  If your mind is
> >     used to the double and quadruple backslashes then it makes
> >     reading macros written in this manner most hard; your brain
> >     keeps saying `there's a mistake!'.  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.

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

> 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?

> 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.  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.

> >     The convention that \ is the escape character, at least when
> >     invoking `external' macros, is being weakened.
> 
> Not at all!  Note that suppressing the escape character is only a
> facility to make the source files more readable.  Similar to TeX, a
> lot of things break if you don't use the backslash as the escape
> character.

Good.  Now we just have to argue about the fact it is less readable.
Also, 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?

> 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.

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.


Ralph.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]