From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: Odd formatting Date: Mon, 30 Apr 2012 14:27:20 +0100 Message-ID: <87vckhxscn.fsf@spindle.srvr.nix> References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> <83zk9xheam.fsf@gnu.org> <877gwxzfv1.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1335792465 13631 80.91.229.3 (30 Apr 2012 13:27:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 30 Apr 2012 13:27:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 30 15:27:41 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SOqdg-0007yb-HF for ged-emacs-devel@m.gmane.org; Mon, 30 Apr 2012 15:27:40 +0200 Original-Received: from localhost ([::1]:54890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SOqdf-0001ue-TD for ged-emacs-devel@m.gmane.org; Mon, 30 Apr 2012 09:27:39 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SOqdZ-0001uV-3O for emacs-devel@gnu.org; Mon, 30 Apr 2012 09:27:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SOqdU-0005rw-9a for emacs-devel@gnu.org; Mon, 30 Apr 2012 09:27:32 -0400 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:33580 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SOqdT-0005rA-Vg for emacs-devel@gnu.org; Mon, 30 Apr 2012 09:27:28 -0400 Original-Received: from esperi.org.uk (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.5/8.14.5) with ESMTP id q3UDRKeZ006858 for ; Mon, 30 Apr 2012 14:27:20 +0100 Original-Received: (from nix@localhost) by esperi.org.uk (8.14.5/8.14.5/Submit) id q3UDRKXu020700; Mon, 30 Apr 2012 14:27:20 +0100 Emacs: the answer to the world surplus of CPU cycles. In-Reply-To: <877gwxzfv1.fsf@gmail.com> (Antoine Levitt's message of "Mon, 30 Apr 2012 12:14:10 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) X-DCC-URT-Metrics: spindle 1060; Body=1 Fuz1=1 Fuz2=1 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 81.187.191.129 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150158 Archived-At: On 30 Apr 2012, Antoine Levitt uttered the following: > 30/04/12 09:48, Steinar Bang >>>>>>> Lars Magne Ingebrigtsen : >> >>> 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: >> >>>
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.
>> >>> (This is the text/html part of the multipart message you send.) >> >> Note that the text/plain version of the message is foramatted exactly >> like the bit you quoted. > > Looks like he's writing his email in emacs, with emacs wrapping, and > then pasting it into gmail, which then adds further (and different) > wrapping. Not much gnus can do, I think. Yeah. I suspect the Emacs wrapping is considered hard returns, and gmail is adding further soft returns on top of that, and then expressing each hard return as a
. Solution, "don't do that then", since I doubt there is a way to turn off wrapping in gmail or to get it to stop treating each explicitly-entered RET as a
. -- NULL && (void)