laurent said:
>   As for march digests 2058 and 2059, 
>   it seems to me they are not included twice 
>   in the current posting of March digests (!?)

that's correct.
but they are also included at the end of the february digests.


>   My policy concerning iterated postings that are identical
>   -- except maybe for correction of some gaffe -- is to 
>   post the last with the header tags for all the postings.
>   It's a simple matter of noise abatement -- 
>   without loss of real content.

that's cool.
but you should also delete the _reference_ to that deleted post
on the "topics" summary at the top of the daily digest it was in.

(i automatically delete lines like these:
>   Content: futurebasic_30893.ezm
>   Content: futurebasic_30905.ezm
so they are not what i'm referring to.
i'm referring to the "by" line for the post on the headers page.)


>   Any other digest corrections while we're at it?

just one, which i forgot earlier.
one post had the dreaded "=hex" charset ugliness,
number 29681 from jay with "droplist" as the header.
it's probably best for one person to take the time to
clean that up right, so everyone doesn't have to do it.

not exactly "errors", but there are probably some things
that glenn could change that would make the automatic
transparent formatting go much easier and be more clear.

for example, some list digests have a "separator line"
that clearly delineates the break between the messages.
without such separators, this task becomes very difficult,
especially since the header-lines are often jumbled (e.g., 
sometimes the date comes first, sometimes something else).

i'm not sure of the reasons for it, but there doesn't seem 
to be a lot of consistency in the structure of these digests.


>   Obviously I wouldn't maintain the digests if I didn't
>   use them myself.  Personally I use a grep search 
>   over all the digests to locate relevant information.  
>   I use QED/M for that; any equally powerful tools to suggest?

well, there's a find capacity within b-mw.
you might or might not find it capable enough.

i could adapt the current "give" find functionality,
which allows you to search for 10 items at once.

the slowness is mostly because it's
searching up to 2700 ztxt resources.
if someone could show me how to
merge them into one handle to search
(and, actually, just the text part of the ztxt resource,
not the styl data that is appended to the end of it),
that would probably make the search routine go very fast.


>   The one feature i miss is the ability to go off on a tangent 
>   and then return to an earlier search pattern
>   without having to restart at square one.  Suggestions?

in "give", you can inactivate any of the 10 search terms,
and then reactivate them later.  so that might help you.

i also want to work up some routines to write search results
out to a file, and then reload them.  that might also help you.


>   I have never done a cumulative index, but with your
>   orientation bb, that might be the way to go.  Good luck.

i'm looking to build some auto-indexing tools.
give me some ideas and i'll try and run with 'em.


>   PPPS. Have just run across "Privacy & Encryption" 
>   a text nicely formatted using B.Raoult's 
>   Print2PICT extension "PostCard" of 1992. 

yes, "postcard" was a neat little tool.
futurebasic can print2pict as well, though.
just print to a window, and turn it into a pict.


>   I guess that is one of the few autonomous readers 
>   that are vanishingly small and not limited to 32Ko (?)  
>   Cannot extract text but may be I could learn...

it depends on how the text was put into the pict.
edoc turns text into picts, and can then search them.
but why put the text into picts in the first place?

and once again, as i've been saying for years,
thanks for taking on the task of curating these archives...

-bowerbird