"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> Gunnar Ritter <[EMAIL PROTECTED]>:
> > Real *roff is hardly the problem since it has supported the
> > two-character requests (except .do) for more than thirty years
> > now. The issues are with scripts that convert manual pages or
> > build indexes f
Gunnar Ritter <[EMAIL PROTECTED]>:
> I have often used .in (and seen it used) in a context like
> . Looking at a few pages, it seems that
> others have used .ti similarly.
Can you send me an example?
--
http://www.catb.org/~esr/";>Eric S. Raymond
Eric S. Raymond wrote:
I would say a program that
claims to read manual pages is broken enough to be irrelevant
if it cannot at least handle
.br .fi .nf .sp .ig .in .ti
Doclifter might fail that test. It ignores .in and .ti, because
I don't know any way to extract structural informat
Larry Kollar <[EMAIL PROTECTED]>:
> Taking a brief look at the manpages on my computer, .in and .ti
> primarily appear in examples (see unzip.1) or nested lists
> (see tcpdump.1). Looking at tcpdump, I expect that it would
> give doclifter fits as well.
Nope, I handle tcpdump fine. In at least th
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> Gunnar Ritter <[EMAIL PROTECTED]>:
> > I have often used .in (and seen it used) in a context like
> > . Looking at a few pages, it seems that
> > others have used .ti similarly.
>
> Can you send me an example?
This is from mush(1), July 17, 1996:
An
Gunnar Ritter <[EMAIL PROTECTED]>:
> This is from mush(1), July 17, 1996:
>
> An example:
> .sp
> .ti +2
> goto msg: `pick \-f argv`
> .sp
> This causes the current message . . .
>
> Others are in nasm(1), v. 0.98.38; sort(1), Unix 7th edition.
> Equivalent use of .in seems much more frequent.
S
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> See my long reply to Larry Kollar. It's not clear to me that anything
> interesting can be deduced here, but I'm open to suggestions. What
> kind of semantic-level tagging could we use in this situation? Would
> be the right thing here?
Perhaps .
Gunnar Ritter <[EMAIL PROTECTED]>:
> > See my long reply to Larry Kollar. It's not clear to me that anything
> > interesting can be deduced here, but I'm open to suggestions. What
> > kind of semantic-level tagging could we use in this situation? Would
> > be the right thing here?
>
> Perhaps
> Enclosed version of groff.1 uses only standard man macros and .de;
> I've inserted .in and .br macros to make the Synopis pretty again.
Hmm. It's really bizarre that I have to use *optical* formatting for
TTY -- and your example looks fine only for a 80-character wide
terminal -- to get a dece
> Having grappled with troff markup weirdness on 13,000 pages, and
> written an interpreter for a a substantial part of troff within
> doclifter, one of the things I am well equipped by experience to do
> is describe a "safe troff" subset that we should recommend man-page
> writers adhere to.
Ver
> I don't want to go down a technical rathole of adding complexity and
> not actually solving the problem. Gunnar shows us that the real
> problem here is these special macros are too complicated for
> anything but groff to interpret. That's the issue that needs to be
> fixed, not kluged around w
Werner LEMBERG <[EMAIL PROTECTED]>:
> Hmm. It's really bizarre that I have to use *optical* formatting for
> TTY -- and your example looks fine only for a 80-character wide
> terminal -- to get a decent lifting. I can't believe that this is the
> right solution!
>
> Both the inserted `.br' and `
Werner LEMBERG <[EMAIL PROTECTED]>:
> > I don't want to go down a technical rathole of adding complexity and
> > not actually solving the problem. Gunnar shows us that the real
> > problem here is these special macros are too complicated for
> > anything but groff to interpret. That's the issue t
Werner LEMBERG <[EMAIL PROTECTED]>:
> > I think it might not be a bad idea for troff to throw warnings when
> > a man page uses a troff request outside the safe set. Note that I
> > am *not* recommending this measure for troff documents other than
> > man pages.
>
> Hmm. This is doable by rede
14 matches
Mail list logo
