Text 15091, 114 rader
Skriven 2011-05-11 12:10:54 av mark lewis (1:3634/12.0)
  Kommentar till text 15088 av Maurice Kinal (1:261/38.9)
Ärende: the proof is in the pudding
===================================
 ML> you're not supposed to because my configuration ensures that there
 ML> is not one ;)

 MK> How does your configuration ensure that there is not one

because my mail tosser has such a function built-in... it is only applied to
mail that enters the network from my node... it does not alter mail being
passed on to other nodes that connect to my system...

 MK> and if so then how do you know that it is wrong?  

how do i know what is wrong??

 MK> My configuration doesn't seem to care about whether or not yours 
 MK> has a tearline.

exactly and this was what brought up the point that tearlines are not required
and that the spec does not mandate that they exist... the original purpose of
tearlines was to tear off everything below them when the messages were imported
into a system's message areas... not all sysops had the space to store all of
those origin lines and such... every byte saved was more space for message
storage...

 MK> It is completely indifferent to it all, including PID's and TID's 
 MK> while we're at it.

 ML> the spec does not state that a tearline is mandatory so i don't
 ML> have one on my posts

 MK> Ah!  Then why the all the fuss about mine?

because you are attempting to support a different specification that
specifically states that there is to be no text on the tearline if there is a
PID/TID line... that's why...

 ML> the ^A character is represented with an '@' symbol because the ^A
 ML> character is outside of the allowed character set...

 MK> No it isn't.

yes it is... characters below 0x20 are specifically disallowed because they are
control characters and can/could cause systems to do highly unwanted things...
CRLF and a few others are allowed for line control but they are not
displayed...

 MK> Besides that is just a representation of the keys used to produce 
 MK> the 0x01 code and not really a character as such.

sure it is... it is the dark smiley face... 0s02 is the light smiley face...

 MK> The '@' character has it's own code, 0x40, which repesents the '@'
 MK> character and in no way should produce 0x01 which is required for
 MK> the kludges in question.

it is not being used for the control lines... it is being used to represent the
^A when the control lines are quoted in messages so as to not cause problems
with the tools that expect ^A to be the start of a control line...

 MK> I believe that actual character allocated for 0x01 is outside the 
 MK> allowed character set but I have seen terminal fonts that can 
 MK> successfully produce it.

while this may be true, they are using a special method to indicate that the
character is to be rendered to the screen or in a document as a textual
character instead of a control character...

 MK> In vim it just shows the key combination which represents ctrl+a.  
 MK> I don't see why that is an issue or 'not allowed'. Why use a 
 MK> character that already has a valid ascii code to represent 
 MK> anything but itself?

as already written, to avoid problems with software that expects it to start a
control line...

 MK> Shouldn't that be 0x40?

 ML> the '@' is 0x40... can i have some of what you are smokin'?

 MK> I think you might want some given that your editor seems confused
 MK> about the '@' character and 0x01 and your acceptance of that
 MK> obviously flawed behavior.  Kids these days.  :::sigh:::

there is no confusion other than that on your side of the monitor... 0x01 is
used for the control line start character... when the control line is quoted or
written as text so as to appear in a message, then 0x01 is replaced with 0x40
for display purposes... this has been being done for 20 years and is standard
practise... some tools convert 0x01 to 0x5e0x41 for visual representation but
these are fewer than those using 0x40 for the representation... 

 ML> actually, it is very much up to the standards that it is coded for

 MK> The Abandoware standards?  :::snicker:::

they are not abandonware standards... geez... they are used daily for apps that
already exist and those that are being developed... without them, fidonet would
never have gotten anywhere and would not have been one of the largest networks
in the world...

 MK> This is way too much fun.  No?

no... it is not fun at all... not when trying to explain and correct things
that someone is specifically twisting and spinning all the time... it is a bad
habit that you have and have had for a very long time... one that has lead us
to bang heads on more than one occasion... one that has caused me to not
participate in this area for some periods... honestly? it stinks... if you
don't want to play in the sandbox, then go find your own... don't throw turds
in it expecting others to clean them up or to leave because of them... if you
have what you believe are better ideas, then fine... implement them in your
software but do not set about breaking everyone else's software or attempting
to negate or run roughshod over their standards and defined methodologies...

)\/(ark

 * Origin:  (1:3634/12)