Re: Emoji: emoticons vs. literacy

From: Asmus Freytag (
Date: Tue Jan 06 2009 - 12:23:22 CST

  • Next message: James Kass: "Re: Emoji: emoticons vs. literacy"

    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.


    This archive was generated by hypermail 2.1.5 : Tue Jan 06 2009 - 12:25:11 CST