Werner LEMBERG <w...@gnu.org> 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
