Odd formatting (was: proposal to make null string handling more emacs-y)

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Steve Yegge <steve.yegge@gmail.com> writes:

> I agree with you. Fortunately that's not what I'm arguing. I'm arguing
> that
> for a very specific corner of the type system, we merge two separate
> meanings of nil. I'm arguing that the empty string as it is used today
> is,
> for all intents, just another nil. So it should not signal an error if
> they are
> treated the same.

Totally off topic, I was looking at how strange your messages are
rendering and wondering whether the mail reader was interpreting your
messages incorrectly or something.  But here's the (sort of) raw source
of that text:

<div>I agree with you. Fortunately that&#39;s not what I&#39;m arguing. I&#39;m arguing that</div><div>for a very specific corner of the type system, we merge two separate</div>
<div>meanings of nil. I&#39;m arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div>

(This is the text/html part of the multipart message you send.)

So your mail reader is wrapping (apparently) random parts of the text in
<div> section, and <div> section are rendered by shr.el as a block-level
elements (which is quite normal, I think).

You're posting through Gmail, so I expect to see a lot more of this kind
of stuff in the future.

Does anybody know why Gmail is doing this, and what shr should be doing
to this, er, stuff to render it properly?  I can't see any hints in the
source of the message that these <div>s are supposed to be
non-block-level elements, but perhaps I'm missing something...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/