Bowerbird writes: > 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. Unfortunately robots not men do this hex "quoted printable" encoding at points unknown to me and maybe even to Glen. It is possible that Glen could detect this by reading header material that gets deleted before I see it. He could perhaps solve the hex problem for us -- if only he had the time. As things stand, by the time I get the digest, the encodings used are not all correctly and fully announced, so I am left to guess what the right road to straight ASCII really is. > well, the object of my code is really that > you shouldn't have to do a lot of re-working Well there *is* a lot of cleanup needed --- be it by Glen, me, you, or the digest enduser. > 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... YES this causes me much pain; I fix maybe 90%, but the remaining 10% will still gum up simple robots of the sort I/bb can easily write. PLEASE ALWAYS PROTECT QUOTED HEADERS with a distinctive line-by-line prefix. > so if you can illustrate a possible use for them > [Glen's serial numbers] > (and the "content: " separator lines is a good start...) How about my tagging telescoped (near) repeated submissions acknowledging there were several in a certain chronological order re related stuff? >> 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. If the original live message had the serial number some of us might use those numbers. I sometimes wonder if the date/time we use is the same for all of us. The serial number *would* be perfectly reliable. > i believe an f.b. app can match the speed of qued/m, > and we can write routines that rival perl in power... Maybe with lots of help from Jay and some assembler from RP. There are egrep libraries in C, and it would be a king sized exercise with Kluskens' C2FB to move that to FB. That's just square 1. > you're veering too 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. If C and unix are gobbledygook... Methinks you are showing too little respect for the subtlety of the classics of C programming. > 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. As in the Lewak-Romano bipole that gave birth to QUED/M :=) --- fame and glory could be ours --- if we're original AND seduce the fickle public favor. cheers laurent s PS. I suspect that other lists with very uniform digest entries reject all header items *except* their select few. I decided to reject automatically only header items I know, and consider irrelevent. I currently do not impose a new order; Glen has a reasonable one. PPS. Yes, since the birth of the xfb list some days have had no digest. PPPS. Check out the prelim 2002 digest revisions at ftp://topo.math.u-psud.fr/pub/lcs/fb/