PE>> Is that "--- comment out the above line" etc a tearline
PE>> (in which case I want to hide it, for the same reason I want
PE>> SEENBY

ml>> AAAHHHHHHHHHHHHHHHHHH!!!!! so =THAT'S= the problem... you want
ml>> to HIDE a tearline... i say don't worry about the damned things...
ml>> support the PID proposal fully and they (tearlines) will eventually
ml>> go by the wayside... until then, what's the beef?  you've fussed
ml>> about me not flying any tearline but it supports what you want,
ml>> no tearline in the message when displayed to the reader... now,
ml>> make up your mind, man...

 PE> I want to delete a tearline.

:-) same diff, isn't it? to not display it when reading the message or
exporting the message is the desired goal?

 PE> I don't want to delete an SQL comment which you may post in your
 PE> message.  There is no way I can tell the difference.

correct... the only method i know of is to use intelligence of some kind...
we humans can do this because we can look at the text and decide whether it
is a tearline or not. the only way i can see to do this the way you want is
to implement some kind of "AI" that "sees" and
"thinks" like we do...

PE>> lines hidden), or is it part of the SQL program?  What algorithm
PE>> do you have that gets it right for your program, and also gets
PE>> it right for a message from me, and 99.99% of the rest of
PE>> fidonet?  It is TECHNICALLY IMPOSSIBLE.

ml>> BS... see above...

my "algorithm" is to "ignore" them and let the user do
whatever =minor= editing is necessary to get source code, your example, in
a compilable format.

 PE> You tell me how I can distinguish between an SQL program comment
 PE> and a tearline?  YOU CAN'T.  IT IS TECHNICALLY IMPOSSIBLE.  BTW, I
 PE> do support the PID proposal fully.

-=B-)

PE>> it's the most fundamental REQUIREMENT of a mail system. Just
PE>> typical of fidonet ot make a complete dogs-breakfast out of it.

ml>> no... you made dogs breakfast out of something that is so minor
ml>> that it's not worth even crying about...

 PE> Eh?  Not prefixing all kludge lines by x'01' is the original dog's

ahhh... ok, that i can understand but it's still not anything to go nuts
over... we seem to be handling it fine so far for the most part... i think
that developing new formats to handle these things is fine but we should
NOT cause these new formats to force things upon us that our current style
does not force on us. tearlines being one...

 PE> breakfast.  Just whacking text control lines into user-text with no
 PE> way to distinguish the two is the dog's breakfast.  Do you
 PE> seriously think that was an OK thing to do?

no, not really but then comes that inevitable discussion of what, exactly,
is a control line. who creates them or decides that "this" is a
new control line? i personally cannot view tearlines are control lines. if
they were, there'd be "rules" against altering them. as it is
now, with the retearing capabilities that the old "quickbbs, i'm not
registered and don't want my messages telling everyone" stuff gave us,
tearlines, in strict reality cannot be considered anything other than
"user" entered text... sysops configure their systems to retear
or remove them and users offline mail packages put in whatever they want...
both are in a position to be considered "users"...

ml>> face it, users will put things in their messages because they want
ml>> to... authors will add some kind of identifiers to their programs
ml>> so they can track them for some reason. in some cases, these two
ml>> things may be close in appearance... so what? it's not anything
ml>> worth crying over...

 PE> I generate a tearline to comply to FTS-4.  I write SQL comments to
 PE> make my SQL look nice.  I expect the other end to be able to
 PE> distinguish between the two without any ambiguity.  That is the
 PE> fundamental requirement of a message system.

human differentiation is not enough? yes, i think it'd be a nice feature
for mail reading programs to remove all the extraneous stuff from source
code messages and others like them but is it really worth forcing everyone
to do something that not strictly required? look how long my messages have
been flowing in fidonet without a tearline! they, in themselves, are proof
enough that tearlines are not required by the major movers or their
software. isn't that how we set standards in fidonet? to have an
implementation in widespread use? isn't this implementation of no required
tearlines in widespread use? -=B-)

)\/(ark