groff
[Top][All Lists]
Advanced

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

Re: [Groff] pic: No white space allowed between . and PS?


From: Steffen Nurpmeso
Subject: Re: [Groff] pic: No white space allowed between . and PS?
Date: Tue, 04 Nov 2014 13:51:36 +0100
User-agent: s-nail v14.7.8-69-gf8bdb20

Werner LEMBERG <address@hidden> wrote:
 |>|Yes.  But generally it can be expected that spaces between \
 |>|. and a macro name doesn't matter.
 |> 
 |> I agree with you here.
 |
 |Just in case it hasn't been mentioned before: At least for the `.so'
 |request, there is a big difference between
 |
 |  .so
 |
 |and
 |
 |  .    so
 |
 |The former gets preprocessed with `soelim', while the latter is only
 |recognized by `troff'.  In other words, this difference provides a
 |means to suppress file inclusion even if `soelim' is used.
 |
 |Admittedly, this mechanism doesn't make much sense with other
 |preprocessors in general, but I think it's not a bad idea to stay with
 |this scheme for orthogonality:
 |
 |  .XXX
 |
 |can be handled by a preprocessor, while
 |
 | .<whitespace>XXX
 |
 |is something only `troff' should process.

Thank you Werner for this which i haven't thought about, sofar.
But nonetheless, Carsten's response made me look into the old 3BSD
sources and there i read that Bill Joy wrote about and in soelim.c
in particular "This is a kludge".  Indeed it looks like
assembler-thought C-written to me; i mean, it was 1977 and memory
etc. was unaffordable, which may be one origin of this restricted
usability, the targeted users may be another.

(Though Mail from 1978.. or better ~1980 doesn't really care that
much for memory.  And no-no <peep>s like CRAP and other such ugly
words are all over this place -- luckily the times they are
a-Changin', ..passing the dirty old men from the universities!  Oh
my god!  Hihihi.)

So for S-roff i _will_ change this to a more normal end-user
compatible way, which i think uniformity of syntax is.  But i now
do think that the -C command line option should get an environment
counterpart, say ROFF_COMPAT_MODE, ROFF_COMPATIBLE or something
similar, and i will cover the leading whitespace issue with this.
I cannot find such an environment for GNU troff yet?  I think this
would be a useful extension?

--steffen



reply via email to

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