From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Tue Jan 06 2009 - 12:23:22 CST
On 1/5/2009 10:00 PM, Michael answered Leo:
>
>>>> No more than any existing quotes create a "quotation mode".
>>> Yes, more. The text between the quotes is rendered the same as if
>>> the quotes were not there.
>>
>> How do the quoted lines above look in your MUA? Plain text with >
>> chars, or an indented paragraph with a vertical bar?
>> Gmail colors and indents plain text quoted with >'s, and I don't see
>> anyone complaining.
>
> And this has nothing to do with modes. It is simply a different way
> to display the nested quotes.
And fragile apparently, see James' troubles with this convention a few
posts later in this thread.
>
>>> If you have an EMOJI_LEFT_QUOTE, then
>>> you are saying the text up until the EMOJI_RIGHT_QUOTE should be
>>> used to select an emoji glyph. That is a mode.
>>
>> Compare with "if you have a > at the beginning of the line, then you
>> are saying the text up until the line that does not start with a >
>> should be displayed indented and colored". That is also a mode, so
>> what?
>
> Sure, but the text that is a different color is still the same, with
> the same meaning.
In other words, the use of ">" is an *orthographic* convention and not
markup. The fact that software is being used to recognize an
orthographic convention is similar to the use of syntax coloring in
programming - despite the use of colors in your programming editor,
there's no change of the underlying program source text, which is all
that matters in defining the program.
Emoticons (Western usage) started out as orthographic convention, what I
called "punny use of punctuation". As long as users typed them in as
punctuations and/or could visualize the punctuation sequence behind a
symbol, the sequences still represent orthography. If users
predominantly select them from pick lists and cannot visualize the
sequence when they see a symbol, then functionally, this convention has
become markup.
This is of course also the case with the > convention for marking e-mail
replies. Some user agents convert these into real markup on the fly - my
mail client uses HTML when drafting a reply, but will convert that
markup to plain text when sending to certain recipients. That conversion
is not lossless, and, for example, I lose the vertical gap between what
I am replying to and the text I insert. It's there while I edit, and
gone when I receive the message off the list.
This is yet another illustration of the practical problems that can be
caused by switching protocol types (plain text/rich text) on the fly.
A./
This archive was generated by hypermail 2.1.5 : Tue Jan 06 2009 - 12:25:11 CST