DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download
Index: ┃ R T

⟦e1d4bd570⟧ TextFile

    Length: 1743 (0x6cf)
    Types: TextFile
    Names: »README«

Derivation

└─⟦a0efdde77⟧ Bits:30001252 EUUGD11 Tape, 1987 Spring Conference Helsinki
    └─ ⟦this⟧ »EUUGD11/euug-87hel/sec1/news/misc/undig/README« 

TextFile

This is a program to ease reading digests.  It was designed to be used
from 'rn' when reading digestified newsgroups such as mod.computers.mac,
but could be applied to any message in digest format.

Functionality is a subset of 'more' (or paging mode in 'rn'), with one
important extension: commands are provided to save individual messages
to a file, pipe them to a command, or reply to them by mail.  Forward
and backward movements are also geared towards the individual message as
a basic unit.

Generally, the program should be much more parametrizable -- it has too
much knowledge built in, like the set of 'uninteresting' mail/news
headers, how to recognize a new message in the digest.  But then, I
don't want to rewrite 'rn', do I?

The user interface issues could be a bit improved, but not much -- the
prompt string could be more informative.

Performance shouldn't be a big issue, but the program certainly isn't
built for paging *huge* files -- althoug 1000-line digests should be
handled easily.  The basic problem is that the text of all messages is
read in memory and never discarded, which makes for fast jumping around
and simpler program logic, but could be a performance penalty for really
big digests.  Adaptation should be fairly easy, since the program has
some data structures that are prepared for throwing away the bulk data,
and the seek address of each paragraph is already saved.  I doubt if
it's worth the trouble, though.

Real bugs: there is no check on exceeding of certain limits like the
list of blocks in mainloop, and maybe some string buffers.  Not all
system calls are checked for errors; for example, write errors and ioctl
calls are unchecked (the latter may be a feature!).  Searching is a
gross hack.