laurent said: > You're scoring some direct hits bb. you work with some text enough, you become familiar with it. > Normally I clean this up, partly by hand, partly by macro. ok, step number 1, let's eliminate this problem at the source. whatever people are doing to cause the =hex shit, cut it out! :+) laurent, when you spot this happening, give people some advice, right at the time, instead of cleaning up after them in silence. > The beginning of a message is reliably signalled by > material that I normally condense into a line like > Content: futurebasic_31236.ezm hmm. it's entirely possible i complicated things unnecessarily, and missed this as the obvious indicator, i'll check it out again, because, at first glance, it certainly seems to be what i need. > And occasional exceptions are my slipups! > Please report them! well, the object of my code is really that you shouldn't have to do a lot of re-working, all the way to the end that you have to do none. that's what we're shooting for here, laurent... (and a message-separator line is the most obvious choice, since the listserve program could insert it automatically, as it's easily comprehensible both to my program and users.) > On the other hand, for the reasons bb mentions, it's next to > impossible to detect the end of the message header material. actually, it's not that difficult... > So it would be helpful if Glen would insert > something that signals that; his robots know how. ...but yes, this would be helpful as well. i seem to remember the more difficult determination was when one digest ended and the headers on the next one started. but even that is easy to detect, by searching for lines that start with > Subject: futurebasic Digest however, the _one_ stickiness i dislike most of all is the "---- original message ----" one, where (some or all of) the headers from the original post are reproduced, as it's very difficult to discriminate this as a copy, and not the next post... so if your e-mail client does this (probably based on something that _you_ do, and can thus choose not to), please take notice... > Header structure comes to a large extent from > the mailer of the message author, whence the variability. but some listserves have digests which are _not_ subject to this mailer-variability. why is that? > It seems to me that the one bad thing you are doing bb is to delete > Glen's message serial number that is potentially very useful. i didn't see a lot of use for those message numbers. but i'm not throwing them away entirely, as they are still included on the list at the start of each digest... so if you can illustrate a possible use for them... (and the "content: " separator lines is a good start...) > Instead I would suggest that Glen put that serial number line > on even the first message-by-message list distribution! not sure what you mean here... if that message-number can be used for some purpose, such as for instance, to retrieve the specific message from the archives, or for any other useful functionality, i will exploit that benefit. some of you may know that it's possible to query majordomo to pull messages -- and even threads -- from the archives. an extension of my program will be to process such retrievals. > QUED/M (sorry not QED/M) wins for speed; and 'perl' > (the pERVERSELY eCLECTIC rUBBISH lISTER) wins for power. > So far... i believe an f.b. app can match the speed of qued/m, and we can write routines that rival perl in power... > For message selection the preferred custom tool seems to be > "procmail" (see yahoo & google). That plus a CGI script might let > bb and collaborators autoextract an archive subset for any > user-specified subject on some future FB web page. you're veering to close to gobbledygook for me here. who needs things like "procmail" and "c.g.i." for this? give me an f.b. app, that i can program however i want. maybe we should proceed in the opposite direction, with me giving you some of my ideas for auto-indexing, and seeing if they stimulate any return-thought from you. > Have you a code scrap or digest ref to prove that > <<futurebasic can print2pict as well, though. > just print to a window, and turn it into a pict.>> of course. don't you? and, with john walkers print2pdf, .pdf creation is also quite trivial... but why put text into these concrete boots when it can run freely as text in our f.b. apps? -bowerbird p.s. next up, the _code_ that does the transparent formatting -- the automagical subroutines you've all been waiting for! -- taking digest as input and creating nice-and-uniform messages. talk about ugly spaghetti hacks, this is the exact type of code that alain once saw that led him to give me my well-deserved reputation as an extraordinary spaghetti programmer. but my word, it works! it does the job! i'll be interested to see if/how all the text-processing brains here can improve on my ugly old-fashioned line-input code... :+)