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: Wed, 20 Sep 2000 15:40:12 +0100

Hi,

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

Not at all.  Both K&R and ANSI styles of C are widely known and widely
used in their respective times.  What do you think of my style?

    int main(int argc, char **argv[])
    {
        printf("hello world!\\n");
    }

I much prefer `**' instead of a single `*' for dereferencing versus
multiplication.  And a single backslash just doesn't stand out, hence
`\\n' for the escape.

Of course, it jars a bit when others come to read it because it looks
like C but isn't quite and any edits they make are often wrong
initially.  But I've got used to it and like it.

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

    $ dict abnormal
      Abnormal \Ab*nor"mal\, a. [For earlier anormal.F. anormal, LL.
         anormalus for anomalus, Gr. ?. Confused with L. abnormis. See
         {Anomalous}, {Abnormous}, {Anormal}.]
         Not conformed to rule or system; deviating from the type;
         anomalous; irregular. ``That deviating from the type;
         anomalous; irregular. '' --Froude.

Yes, abnormal.

> Using two slashes if you can do it with one is abnormal for me.

No, the norm is definitely two.  You'd prefer one.

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

Neither is the saving 2KB of code since it isn't really code, just the
expected, normal, punctuation that everyone expects and is used in
comprehending the code.

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

Then it isn't really pertinent.

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

I'm not proposing disallowing it.  I'm saying that people that know
enough to do this can probably cope with tmac.trace assuming it is
still backslash.

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

Do you not think that convention is also a strong aid in comprehending
others code?

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

Good.  So the LaTeX team have all agreed that it is a good method and
its use may become even more widespread as a result.

Where does that leave your abnormal troff style and my abnormal C?

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

Perhaps I've just been around longer and am wary of features being
added for possibly weak reasons.  The interface of mdoc isn't at issue;
when the documentation is insufficient a lot of troff people will look
at the macro code for the answer.  What can be a hard task will be made
more difficult by having to follow your abnormal style.

Of course, you're quite right.  If you give up maintaining it others
could choose to convert it back to the normal style.


Ralph.


reply via email to

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