groff
[Top][All Lists]
Advanced

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

Re: [Groff] Compression support for files?


From: Steffen Nurpmeso
Subject: Re: [Groff] Compression support for files?
Date: Sat, 19 Jul 2014 16:34:16 +0200
User-agent: s-nail v14.7.4-3-g32d76ea

Hallo Ingo,

Ingo Schwarze <address@hidden> wrote:
 [.]
 |Unfortunately, your example is broken in multiple ways and can
 |hardly be amended to make it work, so it doesn't demonstrate

True.  (But what i did for testing was

  ?0[]$ groff -mdoc -Tutf8 xwhat.1 2>/dev/null 

and it works -- in fact i've chosen what.1 because it is the
smallest manual page i got my fingers at fast.  Sorry. :)  You
know, i don't want to become overly bugging, but in my humble
opinion, especially as a library designer, it must be said that
problems that are not solved at deep levels become overly
complicating and expensive, if at all possible to solve at
a higher level.  This is part of the beauty of Unix, with open(2),
but especially with *read*(2), *write*(2), select(2) and close(2).
On each side of these interfaces there is an enormous amount of
complexity, and increasing, but here we have a few "simple" system
calls and they drive the whole thing, efficiently.

So for this here.. i think Matthew Dillon had a great idea and
with some nice object oriented programming it will become possible
to add support for file decompression at the lowest possible level
regarding troff.  For this to happen only a few lines of code have
to be added to an already existing path test, if i don't count the
object-encapsulation, which is a patch by itself; and of course
not using external decompressor programs but libraries is yet
another patch on top of that, but that is something different
again.

In effect this change on the (GNU) troff(1) side, and i'm wildly
guessing that exactly this is what Matthew Dillon had in mind,
(and should i have Cc:'d him at first glance?  Ooops.) can and
will reduce the overall complexity of the toolchain that is used
for displaying manual pages.

 [.]
 |Using .so in manuals is a terrible idea in the first place.
 |The only application that sort-of works half of the time is as a
 |poor man's replacement of ln(1), like X.org deplorably uses it.

Ok.  But on the other hand, if there are filesystems which use
available storage in the file's management structure not only for
symlink-, but also for regular content then i do not actually see
the difference.  I personally would favour the `.so' request.
On the other hand people start using linker scripts instead of
simple symbolic links for dynamic libraries, which i don't like,
and which thus reveals that my opinions in this area are a bit
schizophrenic.

--steffen



reply via email to

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